diff options
Diffstat (limited to 'Documentation')
1270 files changed, 30860 insertions, 9172 deletions
diff --git a/Documentation/ABI/obsolete/sysfs-selinux-checkreqprot b/Documentation/ABI/removed/sysfs-selinux-checkreqprot index ed6b52ca210f..f599a0a87e8b 100644 --- a/Documentation/ABI/obsolete/sysfs-selinux-checkreqprot +++ b/Documentation/ABI/removed/sysfs-selinux-checkreqprot @@ -4,6 +4,9 @@ KernelVersion: 2.6.12-rc2 (predates git) Contact: selinux@vger.kernel.org Description: + REMOVAL UPDATE: The SELinux checkreqprot functionality was removed in + March 2023, the original deprecation notice is shown below. + The selinuxfs "checkreqprot" node allows SELinux to be configured to check the protection requested by userspace for mmap/mprotect calls instead of the actual protection applied by the kernel. diff --git a/Documentation/ABI/obsolete/sysfs-selinux-disable b/Documentation/ABI/removed/sysfs-selinux-disable index c340278e3cf8..cb783c64cab3 100644 --- a/Documentation/ABI/obsolete/sysfs-selinux-disable +++ b/Documentation/ABI/removed/sysfs-selinux-disable @@ -4,6 +4,9 @@ KernelVersion: 2.6.12-rc2 (predates git) Contact: selinux@vger.kernel.org Description: + REMOVAL UPDATE: The SELinux runtime disable functionality was removed + in March 2023, the original deprecation notice is shown below. + The selinuxfs "disable" node allows SELinux to be disabled at runtime prior to a policy being loaded into the kernel. If disabled via this mechanism, SELinux will remain disabled until the system is rebooted. diff --git a/Documentation/ABI/stable/sysfs-acpi-pmprofile b/Documentation/ABI/stable/sysfs-acpi-pmprofile index 2d6314f0e4e4..cd55e421d921 100644 --- a/Documentation/ABI/stable/sysfs-acpi-pmprofile +++ b/Documentation/ABI/stable/sysfs-acpi-pmprofile @@ -2,16 +2,17 @@ What: /sys/firmware/acpi/pm_profile Date: 03-Nov-2011 KernelVersion: v3.2 Contact: linux-acpi@vger.kernel.org -Description: The ACPI pm_profile sysfs interface exports the platform - power management (and performance) requirement expectations - as provided by BIOS. The integer value is directly passed as - retrieved from the FADT ACPI table. +Description: The ACPI pm_profile sysfs interface exposes the preferred + power management (and performance) profile of the platform + as provided in the ACPI FADT Preferred_PM_Profile field. -Values: For possible values see ACPI specification: - 5.2.9 Fixed ACPI Description Table (FADT) - Field: Preferred_PM_Profile + The integer value is directly passed as retrieved from the FADT. - Currently these values are defined by spec: +Values: For the possible values refer to the Preferred_PM_Profile field + definition in Table 5.9 "FADT Format", Section 5.2.9 "Fixed ACPI + Description Table (FADT)" of the ACPI specification. + + As of ACPI 6.5, the following values are defined: == ================= 0 Unspecified @@ -22,5 +23,6 @@ Values: For possible values see ACPI specification: 5 SOHO Server 6 Appliance PC 7 Performance Server - >7 Reserved + 8 Tablet + >8 Reserved == ================= diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block index ac1e519272aa..c57e5b7cb532 100644 --- a/Documentation/ABI/stable/sysfs-block +++ b/Documentation/ABI/stable/sysfs-block @@ -336,18 +336,11 @@ What: /sys/block/<disk>/queue/io_poll_delay Date: November 2016 Contact: linux-block@vger.kernel.org Description: - [RW] If polling is enabled, this controls what kind of polling - will be performed. It defaults to -1, which is classic polling. + [RW] This was used to control what kind of polling will be + performed. It is now fixed to -1, which is classic polling. In this mode, the CPU will repeatedly ask for completions - without giving up any time. If set to 0, a hybrid polling mode - is used, where the kernel will attempt to make an educated guess - at when the IO will complete. Based on this guess, the kernel - will put the process issuing IO to sleep for an amount of time, - before entering a classic poll loop. This mode might be a little - slower than pure classic polling, but it will be more efficient. - If set to a value larger than 0, the kernel will put the process - issuing IO to sleep for this amount of microseconds before - entering classic polling. + without giving up any time. + <deprecated> What: /sys/block/<disk>/queue/io_timeout @@ -705,6 +698,15 @@ Description: zoned will report "none". +What: /sys/block/<disk>/hidden +Date: March 2023 +Contact: linux-block@vger.kernel.org +Description: + [RO] the block device is hidden. it doesn’t produce events, and + can’t be opened from userspace or using blkdev_get*. + Used for the underlying components of multipath devices. + + What: /sys/block/<disk>/stat Date: February 2008 Contact: Jerome Marchand <jmarchan@redhat.com> diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc index 80b98a4a4d0f..4feb692c4c1d 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc @@ -76,7 +76,7 @@ Date: Dec 2014 KernelVersion: 4.0 Description: Default camera terminal descriptors - All attributes read only: + All attributes read only except bmControls, which is read/write: ======================== ==================================== bmControls bitmap specifying which controls are @@ -101,7 +101,7 @@ Date: Dec 2014 KernelVersion: 4.0 Description: Default processing unit descriptors - All attributes read only: + All attributes read only except bmControls, which is read/write: =============== ======================================== iProcessing index of string descriptor diff --git a/Documentation/ABI/testing/debugfs-cxl b/Documentation/ABI/testing/debugfs-cxl new file mode 100644 index 000000000000..fe61d372e3fa --- /dev/null +++ b/Documentation/ABI/testing/debugfs-cxl @@ -0,0 +1,35 @@ +What: /sys/kernel/debug/cxl/memX/inject_poison +Date: April, 2023 +KernelVersion: v6.4 +Contact: linux-cxl@vger.kernel.org +Description: + (WO) When a Device Physical Address (DPA) is written to this + attribute, the memdev driver sends an inject poison command to + the device for the specified address. The DPA must be 64-byte + aligned and the length of the injected poison is 64-bytes. If + successful, the device returns poison when the address is + accessed through the CXL.mem bus. Injecting poison adds the + address to the device's Poison List and the error source is set + to Injected. In addition, the device adds a poison creation + event to its internal Informational Event log, updates the + Event Status register, and if configured, interrupts the host. + It is not an error to inject poison into an address that + already has poison present and no error is returned. The + inject_poison attribute is only visible for devices supporting + the capability. + + +What: /sys/kernel/debug/memX/clear_poison +Date: April, 2023 +KernelVersion: v6.4 +Contact: linux-cxl@vger.kernel.org +Description: + (WO) When a Device Physical Address (DPA) is written to this + attribute, the memdev driver sends a clear poison command to + the device for the specified address. Clearing poison removes + the address from the device's Poison List and writes 0 (zero) + for 64 bytes starting at address. It is not an error to clear + poison from an address that does not have poison set. If the + device cannot clear poison from the address, -ENXIO is returned. + The clear_poison attribute is only visible for devices + supporting the capability. diff --git a/Documentation/ABI/testing/sysfs-bus-cdx b/Documentation/ABI/testing/sysfs-bus-cdx new file mode 100644 index 000000000000..7af477f49998 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-cdx @@ -0,0 +1,56 @@ +What: /sys/bus/cdx/rescan +Date: March 2023 +Contact: nipun.gupta@amd.com +Description: + Writing y/1/on to this file will cause rescan of the bus + and devices on the CDX bus. Any new devices are scanned and + added to the list of Linux devices and any devices removed are + also deleted from Linux. + + For example:: + + # echo 1 > /sys/bus/cdx/rescan + +What: /sys/bus/cdx/devices/.../vendor +Date: March 2023 +Contact: nipun.gupta@amd.com +Description: + Vendor ID for this CDX device, in hexadecimal. Vendor ID is + 16 bit identifier which is specific to the device manufacturer. + Combination of Vendor ID and Device ID identifies a device. + +What: /sys/bus/cdx/devices/.../device +Date: March 2023 +Contact: nipun.gupta@amd.com +Description: + Device ID for this CDX device, in hexadecimal. Device ID is + 16 bit identifier to identify a device type within the range + of a device manufacturer. + Combination of Vendor ID and Device ID identifies a device. + +What: /sys/bus/cdx/devices/.../reset +Date: March 2023 +Contact: nipun.gupta@amd.com +Description: + Writing y/1/on to this file resets the CDX device. + On resetting the device, the corresponding driver is notified + twice, once before the device is being reset, and again after + the reset has been complete. + + For example:: + + # echo 1 > /sys/bus/cdx/.../reset + +What: /sys/bus/cdx/devices/.../remove +Date: March 2023 +Contact: tarak.reddy@amd.com +Description: + Writing y/1/on to this file removes the corresponding + device from the CDX bus. If the device is to be reconfigured + reconfigured in the Hardware, the device can be removed, so + that the device driver does not access the device while it is + being reconfigured. + + For example:: + + # echo 1 > /sys/bus/cdx/devices/.../remove diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 3acf2f17a73f..48ac0d911801 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -415,3 +415,17 @@ Description: 1), and checks that the hardware accepts the commit request. Reading this value indicates whether the region is committed or not. + + +What: /sys/bus/cxl/devices/memX/trigger_poison_list +Date: April, 2023 +KernelVersion: v6.4 +Contact: linux-cxl@vger.kernel.org +Description: + (WO) When a boolean 'true' is written to this attribute the + memdev driver retrieves the poison list from the device. The + list consists of addresses that are poisoned, or would result + in poison if accessed, and the source of the poison. This + attribute is only visible for devices supporting the + capability. The retrieved errors are logged as kernel + events when cxl_poison event tracing is enabled. diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6ba34c0d9789..7140e8e7313f 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -1807,8 +1807,8 @@ What: /sys/bus/iio/devices/iio:deviceX/out_resistanceX_raw KernelVersion: 4.3 Contact: linux-iio@vger.kernel.org Description: - Raw (unscaled no offset etc.) resistance reading that can be processed - into an ohm value. + Raw (unscaled no offset etc.) resistance reading. + Units after application of scale and offset are ohms. What: /sys/bus/iio/devices/iio:deviceX/heater_enable KernelVersion: 4.1.0 @@ -1894,8 +1894,9 @@ What: /sys/bus/iio/devices/iio:deviceX/in_electricalconductivity_raw KernelVersion: 4.8 Contact: linux-iio@vger.kernel.org Description: - Raw (unscaled no offset etc.) electric conductivity reading that - can be processed to siemens per meter. + Raw (unscaled no offset etc.) electric conductivity reading. + Units after application of scale and offset are siemens per + meter. What: /sys/bus/iio/devices/iio:deviceX/in_countY_raw KernelVersion: 4.10 @@ -1951,8 +1952,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw KernelVersion: 4.18 Contact: linux-iio@vger.kernel.org Description: - Raw (unscaled) phase difference reading from channel Y - that can be processed to radians. + Raw (unscaled) phase difference reading from channel Y. + Units after application of scale and offset are radians. What: /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm1_input What: /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm1_input diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd index 0088aba4caa8..5a775b8f6543 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd +++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd @@ -23,3 +23,55 @@ Description: Reading this attribute gives the state of the DbC. It can be one of the following states: disabled, enabled, initialized, connected, configured and stalled. + +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idVendor +Date: March 2023 +Contact: Mathias Nyman <mathias.nyman@linux.intel.com> +Description: + This dbc_idVendor attribute lets us change the idVendor field + presented in the USB device descriptor by this xhci debug + device. + Value can only be changed while debug capability (DbC) is in + disabled state to prevent USB device descriptor change while + connected to a USB host. + The default value is 0x1d6b (Linux Foundation). + It can be any 16-bit integer. + +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idProduct +Date: March 2023 +Contact: Mathias Nyman <mathias.nyman@linux.intel.com> +Description: + This dbc_idProduct attribute lets us change the idProduct field + presented in the USB device descriptor by this xhci debug + device. + Value can only be changed while debug capability (DbC) is in + disabled state to prevent USB device descriptor change while + connected to a USB host. + The default value is 0x0010. It can be any 16-bit integer. + +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_bcdDevice +Date: March 2023 +Contact: Mathias Nyman <mathias.nyman@linux.intel.com> +Description: + This dbc_bcdDevice attribute lets us change the bcdDevice field + presented in the USB device descriptor by this xhci debug + device. + Value can only be changed while debug capability (DbC) is in + disabled state to prevent USB device descriptor change while + connected to a USB host. + The default value is 0x0010. (device rev 0.10) + It can be any 16-bit integer. + +What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_bInterfaceProtocol +Date: March 2023 +Contact: Mathias Nyman <mathias.nyman@linux.intel.com> +Description: + This attribute lets us change the bInterfaceProtocol field + presented in the USB Interface descriptor by the xhci debug + device. + Value can only be changed while debug capability (DbC) is in + disabled state to prevent USB descriptor change while + connected to a USB host. + The default value is 1 (GNU Remote Debug command). + Other permissible value is 0 which is for vendor defined debug + target. diff --git a/Documentation/ABI/testing/sysfs-bus-platform-devices-ampere-smpro b/Documentation/ABI/testing/sysfs-bus-platform-devices-ampere-smpro index ca93c215ef99..fead760dcf77 100644 --- a/Documentation/ABI/testing/sysfs-bus-platform-devices-ampere-smpro +++ b/Documentation/ABI/testing/sysfs-bus-platform-devices-ampere-smpro @@ -234,8 +234,8 @@ Description: For details, see section `5.10 RAS Internal Error Register Definitions, Altra Family Soc BMC Interface Specification`. -What: /sys/bus/platform/devices/smpro-errmon.*/event_[vrd_warn_fault|vrd_hot|dimm_hot] -KernelVersion: 6.1 +What: /sys/bus/platform/devices/smpro-errmon.*/event_[vrd_warn_fault|vrd_hot|dimm_hot|dimm_2x_refresh] +KernelVersion: 6.1 (event_[vrd_warn_fault|vrd_hot|dimm_hot]), 6.4 (event_dimm_2x_refresh) Contact: Quan Nguyen <quan@os.amperecomputing.com> Description: (RO) Contains the detail information in case of VRD/DIMM warning/hot events @@ -258,8 +258,21 @@ Description: +---------------+---------------------------------------------------------------+---------------------+ | DIMM HOT | /sys/bus/platform/devices/smpro-errmon.*/event_dimm_hot | DIMM Hot | +---------------+---------------------------------------------------------------+---------------------+ + | DIMM 2X | /sys/bus/platform/devices/smpro-errmon.*/event_dimm_2x_refresh| DIMM 2x refresh rate| + | REFRESH RATE | | event in high temp | + +---------------+---------------------------------------------------------------+---------------------+ + + For more details, see section `5.7 GPI Status Registers and 5.9 Memory Error Register Definitions, + Altra Family Soc BMC Interface Specification`. + +What: /sys/bus/platform/devices/smpro-errmon.*/event_dimm[0-15]_syndrome +KernelVersion: 6.4 +Contact: Quan Nguyen <quan@os.amperecomputing.com> +Description: + (RO) The sysfs returns the 2-byte DIMM failure syndrome data for slot + 0-15 if it failed to initialize. - For more details, see section `5.7 GPI Status Registers, + For more details, see section `5.11 Boot Stage Register Definitions, Altra Family Soc BMC Interface Specification`. What: /sys/bus/platform/devices/smpro-misc.*/boot_progress diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 545c2dd97ed0..cb172db41b34 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -166,6 +166,23 @@ Description: The file will be present for all speeds of USB devices, and will always read "no" for USB 1.1 and USB 2.0 devices. +What: /sys/bus/usb/devices/<INTERFACE>/wireless_status +Date: February 2023 +Contact: Bastien Nocera <hadess@hadess.net> +Description: + Some USB devices use a USB receiver dongle to communicate + wirelessly with their device using proprietary protocols. This + attribute allows user-space to know whether the device is + connected to its receiver dongle, and, for example, consider + the device to be absent when choosing whether to show the + device's battery, show a headset in a list of outputs, or show + an on-screen keyboard if the only wireless keyboard is + turned off. + This attribute is not to be used to replace protocol specific + statuses available in WWAN, WLAN/Wi-Fi, Bluetooth, etc. + If the device does not use a receiver dongle with a wireless + device, then this attribute will not exist. + What: /sys/bus/usb/devices/.../<hub_interface>/port<X> Date: August 2012 Contact: Lan Tianyu <tianyu.lan@intel.com> diff --git a/Documentation/ABI/testing/sysfs-devices-state_synced b/Documentation/ABI/testing/sysfs-devices-state_synced index 0c922d7d02fc..c64636ddac41 100644 --- a/Documentation/ABI/testing/sysfs-devices-state_synced +++ b/Documentation/ABI/testing/sysfs-devices-state_synced @@ -21,4 +21,9 @@ Description: at the time the kernel starts are not affected or limited in any way by sync_state() callbacks. + Writing "1" to this file will force a call to the device's + sync_state() function if it hasn't been called already. The + sync_state() call happens independent of the state of the + consumer devices. + diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon index 2d6a472eef88..8d7d8f05f6cd 100644 --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon @@ -14,7 +14,9 @@ Description: RW. Card reactive sustained (PL1/Tau) power limit in microwatts. The power controller will throttle the operating frequency if the power averaged over a window (typically seconds) - exceeds this limit. + exceeds this limit. A read value of 0 means that the PL1 + power limit is disabled, writing 0 disables the + limit. Writing values > 0 will enable the power limit. Only supported for particular Intel i915 graphics platforms. diff --git a/Documentation/ABI/testing/sysfs-driver-zynqmp-fpga b/Documentation/ABI/testing/sysfs-driver-zynqmp-fpga new file mode 100644 index 000000000000..8f93d27b6d91 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-zynqmp-fpga @@ -0,0 +1,73 @@ +What: /sys/bus/platform/drivers/zynqmp_fpga_manager/firmware:zynqmp-firmware:pcap/status +Date: February 2023 +KernelVersion: 6.4 +Contact: Nava kishore Manne <nava.kishore.manne@amd.com> +Description: (RO) Read fpga status. + Read returns a hexadecimal value that tells the current status + of the FPGA device. Each bit position in the status value is + described Below(see ug570 chapter 9). + https://docs.xilinx.com/v/u/en-US/ug570-ultrascale-configuration + + ====================== ============================================== + BIT(0) 0: No CRC error + 1: CRC error + + BIT(1) 0: Decryptor security not set + 1: Decryptor security set + + BIT(2) 0: MMCMs/PLLs are not locked + 1: MMCMs/PLLs are locked + + BIT(3) 0: DCI not matched + 1: DCI matched + + BIT(4) 0: Start-up sequence has not finished + 1: Start-up sequence has finished + + BIT(5) 0: All I/Os are placed in High-Z state + 1: All I/Os behave as configured + + BIT(6) 0: Flip-flops and block RAM are write disabled + 1: Flip-flops and block RAM are write enabled + + BIT(7) 0: GHIGH_B_STATUS asserted + 1: GHIGH_B_STATUS deasserted + + BIT(8) to BIT(10) Status of the mode pins + + BIT(11) 0: Initialization has not finished + 1: Initialization finished + + BIT(12) Value on INIT_B_PIN pin + + BIT(13) 0: Signal not released + 1: Signal released + + BIT(14) Value on DONE_PIN pin. + + BIT(15) 0: No IDCODE_ERROR + 1: IDCODE_ERROR + + BIT(16) 0: No SECURITY_ERROR + 1: SECURITY_ERROR + + BIT(17) System Monitor over-temperature if set + + BIT(18) to BIT(20) Start-up state machine (0 to 7) + Phase 0 = 000 + Phase 1 = 001 + Phase 2 = 011 + Phase 3 = 010 + Phase 4 = 110 + Phase 5 = 111 + Phase 6 = 101 + Phase 7 = 100 + + BIT(25) to BIT(26) Indicates the detected bus width + 00 = x1 + 01 = x8 + 10 = x16 + 11 = x32 + ====================== ============================================== + + The other bits are reserved. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 94132745ecbe..8140fc98f5ae 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -190,12 +190,6 @@ Description: Controls the memory footprint used by free nids and cached nat entries. By default, 1 is set, which indicates 10 MB / 1 GB RAM. -What: /sys/fs/f2fs/<disk>/batched_trim_sections -Date: February 2015 -Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> -Description: Controls the trimming rate in batch mode. - <deprecated> - What: /sys/fs/f2fs/<disk>/cp_interval Date: October 2015 Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> @@ -729,3 +723,20 @@ What: /sys/fs/f2fs/<disk>/last_age_weight Date: January 2023 Contact: "Ping Xiong" <xiongping1@xiaomi.com> Description: When DATA SEPARATION is on, it controls the weight of last data block age. + +What: /sys/fs/f2fs/<disk>/compress_watermark +Date: February 2023 +Contact: "Yangtao Li" <frank.li@vivo.com> +Description: When compress cache is on, it controls free memory watermark + in order to limit caching compress page. If free memory is lower + than watermark, then deny caching compress page. The value should be in + range of (0, 100], by default it was initialized as 20(%). + +What: /sys/fs/f2fs/<disk>/compress_percent +Date: February 2023 +Contact: "Yangtao Li" <frank.li@vivo.com> +Description: When compress cache is on, it controls cached page + percent(compress pages / free_ram) in order to limit caching compress page. + If cached page percent exceed threshold, then deny caching compress page. + The value should be in range of (0, 100], by default it was initialized + as 20(%). diff --git a/Documentation/ABI/testing/sysfs-kernel-iommu_groups b/Documentation/ABI/testing/sysfs-kernel-iommu_groups index b15af6a5bc08..a42d4383d999 100644 --- a/Documentation/ABI/testing/sysfs-kernel-iommu_groups +++ b/Documentation/ABI/testing/sysfs-kernel-iommu_groups @@ -53,7 +53,6 @@ Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default The default domain type of a group may be modified only when - - The group has only one device. - The device in the group is not bound to any device driver. So, the users must unbind the appropriate driver before changing the default domain type. diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-ksm b/Documentation/ABI/testing/sysfs-kernel-mm-ksm index d244674a9480..6041a025b65a 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-ksm +++ b/Documentation/ABI/testing/sysfs-kernel-mm-ksm @@ -51,3 +51,11 @@ Description: Control merging pages across different NUMA nodes. When it is set to 0 only pages from the same node are merged, otherwise pages from all nodes can be merged together (default). + +What: /sys/kernel/mm/ksm/general_profit +Date: April 2023 +KernelVersion: 6.4 +Contact: Linux memory management mailing list <linux-mm@kvack.org> +Description: Measure how effective KSM is. + general_profit: how effective is KSM. The formula for the + calculation is in Documentation/admin-guide/mm/ksm.rst. diff --git a/Documentation/ABI/testing/sysfs-platform-intel-ifs b/Documentation/ABI/testing/sysfs-platform-intel-ifs index 55991983d0d0..41b4d5b1e21c 100644 --- a/Documentation/ABI/testing/sysfs-platform-intel-ifs +++ b/Documentation/ABI/testing/sysfs-platform-intel-ifs @@ -1,3 +1,7 @@ +Device instance to test mapping +intel_ifs_0 -> Scan Test +intel_ifs_1 -> Array BIST test + What: /sys/devices/virtual/misc/intel_ifs_<N>/run_test Date: Nov 16 2022 KernelVersion: 6.2 @@ -8,6 +12,7 @@ Description: Write <cpu#> to trigger IFS test for one online core. completes the test for the core containing that thread. Example: to test the core containing cpu5: echo 5 > /sys/devices/virtual/misc/intel_ifs_<N>/run_test +Devices: all What: /sys/devices/virtual/misc/intel_ifs_<N>/status Date: Nov 16 2022 @@ -15,21 +20,25 @@ KernelVersion: 6.2 Contact: "Jithu Joseph" <jithu.joseph@intel.com> Description: The status of the last test. It can be one of "pass", "fail" or "untested". +Devices: all What: /sys/devices/virtual/misc/intel_ifs_<N>/details Date: Nov 16 2022 KernelVersion: 6.2 Contact: "Jithu Joseph" <jithu.joseph@intel.com> Description: Additional information regarding the last test. The details file reports - the hex value of the SCAN_STATUS MSR. Note that the error_code field + the hex value of the STATUS MSR for this test. Note that the error_code field may contain driver defined software code not defined in the Intel SDM. +Devices: all What: /sys/devices/virtual/misc/intel_ifs_<N>/image_version Date: Nov 16 2022 KernelVersion: 6.2 Contact: "Jithu Joseph" <jithu.joseph@intel.com> -Description: Version (hexadecimal) of loaded IFS binary image. If no scan image - is loaded reports "none". +Description: Version (hexadecimal) of loaded IFS test image. If no test image + is loaded reports "none". Only present for device instances where a test image + is applicable. +Devices: intel_ifs_0 What: /sys/devices/virtual/misc/intel_ifs_<N>/current_batch Date: Nov 16 2022 @@ -39,3 +48,5 @@ Description: Write a number less than or equal to 0xff to load an IFS test image The number written treated as the 2 digit suffix in the following file name: /lib/firmware/intel/ifs_<N>/ff-mm-ss-02x.scan Reading the file will provide the suffix of the currently loaded IFS test image. + This file is present only for device instances where a test image is applicable. +Devices: intel_ifs_0 diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl index e79ca22e2f45..9b99a81babb1 100644 --- a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl @@ -68,3 +68,10 @@ Description: Wasted burnt and invalid Invalid not burnt but marked as valid (error state). ======= =============================================== + +What: /sys/bus/platform/devices/MLNXBF04:00/bootfifo +Date: Apr 2023 +KernelVersion: 6.4 +Contact: "Liming Sun <limings@nvidia.com>" +Description: + The file used to access the BlueField boot fifo. diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index f99d433ff311..a3942b1036e2 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -413,6 +413,35 @@ Description: The /sys/power/suspend_stats/last_failed_step file contains the last failed step in the suspend/resume path. +What: /sys/power/suspend_stats/last_hw_sleep +Date: June 2023 +Contact: Mario Limonciello <mario.limonciello@amd.com> +Description: + The /sys/power/suspend_stats/last_hw_sleep file + contains the duration of time spent in a hardware sleep + state in the most recent system suspend-resume cycle. + This number is measured in microseconds. + +What: /sys/power/suspend_stats/total_hw_sleep +Date: June 2023 +Contact: Mario Limonciello <mario.limonciello@amd.com> +Description: + The /sys/power/suspend_stats/total_hw_sleep file + contains the aggregate of time spent in a hardware sleep + state since the kernel was booted. This number + is measured in microseconds. + +What: /sys/power/suspend_stats/max_hw_sleep +Date: June 2023 +Contact: Mario Limonciello <mario.limonciello@amd.com> +Description: + The /sys/power/suspend_stats/max_hw_sleep file + contains the maximum amount of time that the hardware can + report for time spent in a hardware sleep state. When sleep + cycles are longer than this time, the values for + 'total_hw_sleep' and 'last_hw_sleep' may not be accurate. + This number is measured in microseconds. + What: /sys/power/sync_on_suspend Date: October 2019 Contact: Jonas Meurer <jonas@freesources.org> diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst index bdafeb4b66dc..9981d330da8f 100644 --- a/Documentation/PCI/pci-error-recovery.rst +++ b/Documentation/PCI/pci-error-recovery.rst @@ -418,7 +418,6 @@ That is, the recovery API only requires that: - drivers/next/e100.c - drivers/net/e1000 - drivers/net/e1000e - - drivers/net/ixgb - drivers/net/ixgbe - drivers/net/cxgb3 - drivers/net/s2io.c diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst index c9c957c85bac..93d899d53258 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst @@ -277,7 +277,7 @@ the following access functions: Again, only one request in a given batch need actually carry out a grace-period operation, which means there must be an efficient way to -identify which of many concurrent reqeusts will initiate the grace +identify which of many concurrent requests will initiate the grace period, and that there be an efficient way for the remaining requests to wait for that grace period to complete. However, that is the topic of the next section. @@ -405,7 +405,7 @@ Use of Workqueues In earlier implementations, the task requesting the expedited grace period also drove it to completion. This straightforward approach had the disadvantage of needing to account for POSIX signals sent to user -tasks, so more recent implemementations use the Linux kernel's +tasks, so more recent implementations use the Linux kernel's workqueues (see Documentation/core-api/workqueue.rst). The requesting task still does counter snapshotting and funnel-lock @@ -465,7 +465,7 @@ corresponding disadvantage that workqueues cannot be used until they are initialized, which does not happen until some time after the scheduler spawns the first task. Given that there are parts of the kernel that really do want to execute grace periods during this mid-boot “dead -zoneâ€, expedited grace periods must do something else during thie time. +zoneâ€, expedited grace periods must do something else during this time. What they do is to fall back to the old practice of requiring that the requesting task drive the expedited grace period, as was the case before diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index 7fdf151a8680..5750f125361b 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -168,7 +168,7 @@ an ``atomic_add_return()`` of zero) to detect idle CPUs. +-----------------------------------------------------------------------+ The approach must be extended to handle one final case, that of waking a -task blocked in ``synchronize_rcu()``. This task might be affinitied to +task blocked in ``synchronize_rcu()``. This task might be affined to a CPU that is not yet aware that the grace period has ended, and thus might not yet be subject to the grace period's memory ordering. Therefore, there is an ``smp_mb()`` after the return from diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index 588d97366a46..db8f16b392aa 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt @@ -201,7 +201,7 @@ work looked at debugging uses of RCU [Seyster:2011:RFA:2075416.2075425]. In 2012, Josh Triplett received his Ph.D. with his dissertation covering RCU-protected resizable hash tables and the relationship between memory barriers and read-side traversal order: If the updater -is making changes in the opposite direction from the read-side traveral +is making changes in the opposite direction from the read-side traversal order, the updater need only execute a memory-barrier instruction, but if in the same direction, the updater needs to wait for a grace period between the individual updates [JoshTriplettPhD]. Also in 2012, @@ -1245,7 +1245,7 @@ Oregon Health and Sciences University" [Viewed September 5, 2005]" ,annotation={ First posting showing how RCU can be safely adapted for - preemptable RCU read side critical sections. + preemptible RCU read side critical sections. } } @@ -1888,7 +1888,7 @@ Revised: \url{https://lore.kernel.org/r/20070910183004.GA3299@linux.vnet.ibm.com} [Viewed October 25, 2007]" ,annotation={ - Final patch for preemptable RCU to -rt. (Later patches were + Final patch for preemptible RCU to -rt. (Later patches were to mainline, eventually incorporated.) } } @@ -2275,7 +2275,7 @@ lot of {Linux} into your technology!!!" \url{https://lore.kernel.org/r/20090724001429.GA17374@linux.vnet.ibm.com} [Viewed August 15, 2009]" ,annotation={ - First posting of simple and fast preemptable RCU. + First posting of simple and fast preemptible RCU. } } @@ -2639,7 +2639,7 @@ lot of {Linux} into your technology!!!" RCU-protected hash tables, barriers vs. read-side traversal order. . If the updater is making changes in the opposite direction from - the read-side traveral order, the updater need only execute a + the read-side traversal order, the updater need only execute a memory-barrier instruction, but if in the same direction, the updater needs to wait for a grace period between the individual updates. diff --git a/Documentation/RCU/UP.rst b/Documentation/RCU/UP.rst index 8b20fd45f255..4060d7a2f62a 100644 --- a/Documentation/RCU/UP.rst +++ b/Documentation/RCU/UP.rst @@ -107,7 +107,7 @@ UP systems, including PREEMPT SMP builds running on UP systems. Quick Quiz #3: Why can't synchronize_rcu() return immediately on UP systems running - preemptable RCU? + preemptible RCU? .. _answer_quick_quiz_up: @@ -143,7 +143,7 @@ Answer to Quick Quiz #2: Answer to Quick Quiz #3: Why can't synchronize_rcu() return immediately on UP systems - running preemptable RCU? + running preemptible RCU? Because some other task might have been preempted in the middle of an RCU read-side critical section. If synchronize_rcu() diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index cc361fb01ed4..bd3c58c44bef 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -70,7 +70,7 @@ over a rather long period of time, but improvements are always welcome! can serve as rcu_read_lock_sched(), but is less readable and prevents lockdep from detecting locking issues. - Please not that you *cannot* rely on code known to be built + Please note that you *cannot* rely on code known to be built only in non-preemptible kernels. Such code can and will break, especially in kernels built with CONFIG_PREEMPT_COUNT=y. diff --git a/Documentation/RCU/lockdep.rst b/Documentation/RCU/lockdep.rst index 2749f43ec1b0..69e73a39bd11 100644 --- a/Documentation/RCU/lockdep.rst +++ b/Documentation/RCU/lockdep.rst @@ -65,7 +65,7 @@ checking of rcu_dereference() primitives: rcu_access_pointer(p): Return the value of the pointer and omit all barriers, but retain the compiler constraints that prevent duplicating - or coalescsing. This is useful when testing the + or coalescing. This is useful when testing the value of the pointer itself, for example, against NULL. The rcu_dereference_check() check expression can be any boolean diff --git a/Documentation/RCU/torture.rst b/Documentation/RCU/torture.rst index 0316ba0c6922..b3b6dfa85248 100644 --- a/Documentation/RCU/torture.rst +++ b/Documentation/RCU/torture.rst @@ -216,7 +216,7 @@ Kernel boot arguments can also be supplied, for example, to control rcutorture's module parameters. For example, to test a change to RCU's CPU stall-warning code, use "--bootargs 'rcutorture.stall_cpu=30'". This will of course result in the scripting reporting a failure, namely -the resuling RCU CPU stall warning. As noted above, reducing memory may +the resulting RCU CPU stall warning. As noted above, reducing memory may require disabling rcutorture's callback-flooding tests:: kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \ @@ -370,5 +370,5 @@ You can also re-run a previous remote run in a manner similar to kvm.sh: tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28-remote \ --duration 24h -In this case, most of the kvm-again.sh parmeters may be supplied following +In this case, most of the kvm-again.sh parameters may be supplied following the pathname of the old run-results directory. diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index 2c5563a91998..8eddef28d3a1 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -597,10 +597,10 @@ to avoid having to write your own callback:: If the occasional sleep is permitted, the single-argument form may be used, omitting the rcu_head structure from struct foo. - kfree_rcu(old_fp); + kfree_rcu_mightsleep(old_fp); -This variant of kfree_rcu() almost never blocks, but might do so by -invoking synchronize_rcu() in response to memory-allocation failure. +This variant almost never blocks, but might do so by invoking +synchronize_rcu() in response to memory-allocation failure. Again, see checklist.rst for additional rules governing the use of RCU. diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst index 2b43c9a7f67b..e94a0160b6a0 100644 --- a/Documentation/accel/index.rst +++ b/Documentation/accel/index.rst @@ -8,6 +8,7 @@ Compute Accelerators :maxdepth: 1 introduction + qaic/index .. only:: subproject and html diff --git a/Documentation/accel/qaic/aic100.rst b/Documentation/accel/qaic/aic100.rst new file mode 100644 index 000000000000..c80d0f1307db --- /dev/null +++ b/Documentation/accel/qaic/aic100.rst @@ -0,0 +1,510 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +=============================== + Qualcomm Cloud AI 100 (AIC100) +=============================== + +Overview +======== + +The Qualcomm Cloud AI 100/AIC100 family of products (including SA9000P - part of +Snapdragon Ride) are PCIe adapter cards which contain a dedicated SoC ASIC for +the purpose of efficiently running Artificial Intelligence (AI) Deep Learning +inference workloads. They are AI accelerators. + +The PCIe interface of AIC100 is capable of PCIe Gen4 speeds over eight lanes +(x8). An individual SoC on a card can have up to 16 NSPs for running workloads. +Each SoC has an A53 management CPU. On card, there can be up to 32 GB of DDR. + +Multiple AIC100 cards can be hosted in a single system to scale overall +performance. AIC100 cards are multi-user capable and able to execute workloads +from multiple users in a concurrent manner. + +Hardware Description +==================== + +An AIC100 card consists of an AIC100 SoC, on-card DDR, and a set of misc +peripherals (PMICs, etc). + +An AIC100 card can either be a PCIe HHHL form factor (a traditional PCIe card), +or a Dual M.2 card. Both use PCIe to connect to the host system. + +As a PCIe endpoint/adapter, AIC100 uses the standard VendorID(VID)/ +DeviceID(DID) combination to uniquely identify itself to the host. AIC100 +uses the standard Qualcomm VID (0x17cb). All AIC100 SKUs use the same +AIC100 DID (0xa100). + +AIC100 does not implement FLR (function level reset). + +AIC100 implements MSI but does not implement MSI-X. AIC100 requires 17 MSIs to +operate (1 for MHI, 16 for the DMA Bridge). + +As a PCIe device, AIC100 utilizes BARs to provide host interfaces to the device +hardware. AIC100 provides 3, 64-bit BARs. + +* The first BAR is 4K in size, and exposes the MHI interface to the host. + +* The second BAR is 2M in size, and exposes the DMA Bridge interface to the + host. + +* The third BAR is variable in size based on an individual AIC100's + configuration, but defaults to 64K. This BAR currently has no purpose. + +From the host perspective, AIC100 has several key hardware components - + +* MHI (Modem Host Interface) +* QSM (QAIC Service Manager) +* NSPs (Neural Signal Processor) +* DMA Bridge +* DDR + +MHI +--- + +AIC100 has one MHI interface over PCIe. MHI itself is documented at +Documentation/mhi/index.rst MHI is the mechanism the host uses to communicate +with the QSM. Except for workload data via the DMA Bridge, all interaction with +the device occurs via MHI. + +QSM +--- + +QAIC Service Manager. This is an ARM A53 CPU that runs the primary +firmware of the card and performs on-card management tasks. It also +communicates with the host via MHI. Each AIC100 has one of +these. + +NSP +--- + +Neural Signal Processor. Each AIC100 has up to 16 of these. These are +the processors that run the workloads on AIC100. Each NSP is a Qualcomm Hexagon +(Q6) DSP with HVX and HMX. Each NSP can only run one workload at a time, but +multiple NSPs may be assigned to a single workload. Since each NSP can only run +one workload, AIC100 is limited to 16 concurrent workloads. Workload +"scheduling" is under the purview of the host. AIC100 does not automatically +timeslice. + +DMA Bridge +---------- + +The DMA Bridge is custom DMA engine that manages the flow of data +in and out of workloads. AIC100 has one of these. The DMA Bridge has 16 +channels, each consisting of a set of request/response FIFOs. Each active +workload is assigned a single DMA Bridge channel. The DMA Bridge exposes +hardware registers to manage the FIFOs (head/tail pointers), but requires host +memory to store the FIFOs. + +DDR +--- + +AIC100 has on-card DDR. In total, an AIC100 can have up to 32 GB of DDR. +This DDR is used to store workloads, data for the workloads, and is used by the +QSM for managing the device. NSPs are granted access to sections of the DDR by +the QSM. The host does not have direct access to the DDR, and must make +requests to the QSM to transfer data to the DDR. + +High-level Use Flow +=================== + +AIC100 is a multi-user, programmable accelerator typically used for running +neural networks in inferencing mode to efficiently perform AI operations. +AIC100 is not intended for training neural networks. AIC100 can be utilized +for generic compute workloads. + +Assuming a user wants to utilize AIC100, they would follow these steps: + +1. Compile the workload into an ELF targeting the NSP(s) +2. Make requests to the QSM to load the workload and related artifacts into the + device DDR +3. Make a request to the QSM to activate the workload onto a set of idle NSPs +4. Make requests to the DMA Bridge to send input data to the workload to be + processed, and other requests to receive processed output data from the + workload. +5. Once the workload is no longer required, make a request to the QSM to + deactivate the workload, thus putting the NSPs back into an idle state. +6. Once the workload and related artifacts are no longer needed for future + sessions, make requests to the QSM to unload the data from DDR. This frees + the DDR to be used by other users. + + +Boot Flow +========= + +AIC100 uses a flashless boot flow, derived from Qualcomm MSMs. + +When AIC100 is first powered on, it begins executing PBL (Primary Bootloader) +from ROM. PBL enumerates the PCIe link, and initializes the BHI (Boot Host +Interface) component of MHI. + +Using BHI, the host points PBL to the location of the SBL (Secondary Bootloader) +image. The PBL pulls the image from the host, validates it, and begins +execution of SBL. + +SBL initializes MHI, and uses MHI to notify the host that the device has entered +the SBL stage. SBL performs a number of operations: + +* SBL initializes the majority of hardware (anything PBL left uninitialized), + including DDR. +* SBL offloads the bootlog to the host. +* SBL synchronizes timestamps with the host for future logging. +* SBL uses the Sahara protocol to obtain the runtime firmware images from the + host. + +Once SBL has obtained and validated the runtime firmware, it brings the NSPs out +of reset, and jumps into the QSM. + +The QSM uses MHI to notify the host that the device has entered the QSM stage +(AMSS in MHI terms). At this point, the AIC100 device is fully functional, and +ready to process workloads. + +Userspace components +==================== + +Compiler +-------- + +An open compiler for AIC100 based on upstream LLVM can be found at: +https://github.com/quic/software-kit-for-qualcomm-cloud-ai-100-cc + +Usermode Driver (UMD) +--------------------- + +An open UMD that interfaces with the qaic kernel driver can be found at: +https://github.com/quic/software-kit-for-qualcomm-cloud-ai-100 + +Sahara loader +------------- + +An open implementation of the Sahara protocol called kickstart can be found at: +https://github.com/andersson/qdl + +MHI Channels +============ + +AIC100 defines a number of MHI channels for different purposes. This is a list +of the defined channels, and their uses. + ++----------------+---------+----------+----------------------------------------+ +| Channel name | IDs | EEs | Purpose | ++================+=========+==========+========================================+ +| QAIC_LOOPBACK | 0 & 1 | AMSS | Any data sent to the device on this | +| | | | channel is sent back to the host. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_SAHARA | 2 & 3 | SBL | Used by SBL to obtain the runtime | +| | | | firmware from the host. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_DIAG | 4 & 5 | AMSS | Used to communicate with QSM via the | +| | | | DIAG protocol. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_SSR | 6 & 7 | AMSS | Used to notify the host of subsystem | +| | | | restart events, and to offload SSR | +| | | | crashdumps. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_QDSS | 8 & 9 | AMSS | Used for the Qualcomm Debug Subsystem. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_CONTROL | 10 & 11 | AMSS | Used for the Neural Network Control | +| | | | (NNC) protocol. This is the primary | +| | | | channel between host and QSM for | +| | | | managing workloads. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_LOGGING | 12 & 13 | SBL | Used by the SBL to send the bootlog to | +| | | | the host. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_STATUS | 14 & 15 | AMSS | Used to notify the host of Reliability,| +| | | | Accessibility, Serviceability (RAS) | +| | | | events. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_TELEMETRY | 16 & 17 | AMSS | Used to get/set power/thermal/etc | +| | | | attributes. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_DEBUG | 18 & 19 | AMSS | Not used. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_TIMESYNC | 20 & 21 | SBL/AMSS | Used to synchronize timestamps in the | +| | | | device side logs with the host time | +| | | | source. | ++----------------+---------+----------+----------------------------------------+ + +DMA Bridge +========== + +Overview +-------- + +The DMA Bridge is one of the main interfaces to the host from the device +(the other being MHI). As part of activating a workload to run on NSPs, the QSM +assigns that network a DMA Bridge channel. A workload's DMA Bridge channel +(DBC for short) is solely for the use of that workload and is not shared with +other workloads. + +Each DBC is a pair of FIFOs that manage data in and out of the workload. One +FIFO is the request FIFO. The other FIFO is the response FIFO. + +Each DBC contains 4 registers in hardware: + +* Request FIFO head pointer (offset 0x0). Read only by the host. Indicates the + latest item in the FIFO the device has consumed. +* Request FIFO tail pointer (offset 0x4). Read/write by the host. Host + increments this register to add new items to the FIFO. +* Response FIFO head pointer (offset 0x8). Read/write by the host. Indicates + the latest item in the FIFO the host has consumed. +* Response FIFO tail pointer (offset 0xc). Read only by the host. Device + increments this register to add new items to the FIFO. + +The values in each register are indexes in the FIFO. To get the location of the +FIFO element pointed to by the register: FIFO base address + register * element +size. + +DBC registers are exposed to the host via the second BAR. Each DBC consumes +4KB of space in the BAR. + +The actual FIFOs are backed by host memory. When sending a request to the QSM +to activate a network, the host must donate memory to be used for the FIFOs. +Due to internal mapping limitations of the device, a single contiguous chunk of +memory must be provided per DBC, which hosts both FIFOs. The request FIFO will +consume the beginning of the memory chunk, and the response FIFO will consume +the end of the memory chunk. + +Request FIFO +------------ + +A request FIFO element has the following structure: + +.. code-block:: c + + struct request_elem { + u16 req_id; + u8 seq_id; + u8 pcie_dma_cmd; + u32 reserved; + u64 pcie_dma_source_addr; + u64 pcie_dma_dest_addr; + u32 pcie_dma_len; + u32 reserved; + u64 doorbell_addr; + u8 doorbell_attr; + u8 reserved; + u16 reserved; + u32 doorbell_data; + u32 sem_cmd0; + u32 sem_cmd1; + u32 sem_cmd2; + u32 sem_cmd3; + }; + +Request field descriptions: + +req_id + request ID. A request FIFO element and a response FIFO element with + the same request ID refer to the same command. + +seq_id + sequence ID within a request. Ignored by the DMA Bridge. + +pcie_dma_cmd + describes the DMA element of this request. + + * Bit(7) is the force msi flag, which overrides the DMA Bridge MSI logic + and generates a MSI when this request is complete, and QSM + configures the DMA Bridge to look at this bit. + * Bits(6:5) are reserved. + * Bit(4) is the completion code flag, and indicates that the DMA Bridge + shall generate a response FIFO element when this request is + complete. + * Bit(3) indicates if this request is a linked list transfer(0) or a bulk + transfer(1). + * Bit(2) is reserved. + * Bits(1:0) indicate the type of transfer. No transfer(0), to device(1), + from device(2). Value 3 is illegal. + +pcie_dma_source_addr + source address for a bulk transfer, or the address of the linked list. + +pcie_dma_dest_addr + destination address for a bulk transfer. + +pcie_dma_len + length of the bulk transfer. Note that the size of this field + limits transfers to 4G in size. + +doorbell_addr + address of the doorbell to ring when this request is complete. + +doorbell_attr + doorbell attributes. + + * Bit(7) indicates if a write to a doorbell is to occur. + * Bits(6:2) are reserved. + * Bits(1:0) contain the encoding of the doorbell length. 0 is 32-bit, + 1 is 16-bit, 2 is 8-bit, 3 is reserved. The doorbell address + must be naturally aligned to the specified length. + +doorbell_data + data to write to the doorbell. Only the bits corresponding to + the doorbell length are valid. + +sem_cmdN + semaphore command. + + * Bit(31) indicates this semaphore command is enabled. + * Bit(30) is the to-device DMA fence. Block this request until all + to-device DMA transfers are complete. + * Bit(29) is the from-device DMA fence. Block this request until all + from-device DMA transfers are complete. + * Bits(28:27) are reserved. + * Bits(26:24) are the semaphore command. 0 is NOP. 1 is init with the + specified value. 2 is increment. 3 is decrement. 4 is wait + until the semaphore is equal to the specified value. 5 is wait + until the semaphore is greater or equal to the specified value. + 6 is "P", wait until semaphore is greater than 0, then + decrement by 1. 7 is reserved. + * Bit(23) is reserved. + * Bit(22) is the semaphore sync. 0 is post sync, which means that the + semaphore operation is done after the DMA transfer. 1 is + presync, which gates the DMA transfer. Only one presync is + allowed per request. + * Bit(21) is reserved. + * Bits(20:16) is the index of the semaphore to operate on. + * Bits(15:12) are reserved. + * Bits(11:0) are the semaphore value to use in operations. + +Overall, a request is processed in 4 steps: + +1. If specified, the presync semaphore condition must be true +2. If enabled, the DMA transfer occurs +3. If specified, the postsync semaphore conditions must be true +4. If enabled, the doorbell is written + +By using the semaphores in conjunction with the workload running on the NSPs, +the data pipeline can be synchronized such that the host can queue multiple +requests of data for the workload to process, but the DMA Bridge will only copy +the data into the memory of the workload when the workload is ready to process +the next input. + +Response FIFO +------------- + +Once a request is fully processed, a response FIFO element is generated if +specified in pcie_dma_cmd. The structure of a response FIFO element: + +.. code-block:: c + + struct response_elem { + u16 req_id; + u16 completion_code; + }; + +req_id + matches the req_id of the request that generated this element. + +completion_code + status of this request. 0 is success. Non-zero is an error. + +The DMA Bridge will generate a MSI to the host as a reaction to activity in the +response FIFO of a DBC. The DMA Bridge hardware has an IRQ storm mitigation +algorithm, where it will only generate a MSI when the response FIFO transitions +from empty to non-empty (unless force MSI is enabled and triggered). In +response to this MSI, the host is expected to drain the response FIFO, and must +take care to handle any race conditions between draining the FIFO, and the +device inserting elements into the FIFO. + +Neural Network Control (NNC) Protocol +===================================== + +The NNC protocol is how the host makes requests to the QSM to manage workloads. +It uses the QAIC_CONTROL MHI channel. + +Each NNC request is packaged into a message. Each message is a series of +transactions. A passthrough type transaction can contain elements known as +commands. + +QSM requires NNC messages be little endian encoded and the fields be naturally +aligned. Since there are 64-bit elements in some NNC messages, 64-bit alignment +must be maintained. + +A message contains a header and then a series of transactions. A message may be +at most 4K in size from QSM to the host. From the host to the QSM, a message +can be at most 64K (maximum size of a single MHI packet), but there is a +continuation feature where message N+1 can be marked as a continuation of +message N. This is used for exceedingly large DMA xfer transactions. + +Transaction descriptions +------------------------ + +passthrough + Allows userspace to send an opaque payload directly to the QSM. + This is used for NNC commands. Userspace is responsible for managing + the QSM message requirements in the payload. + +dma_xfer + DMA transfer. Describes an object that the QSM should DMA into the + device via address and size tuples. + +activate + Activate a workload onto NSPs. The host must provide memory to be + used by the DBC. + +deactivate + Deactivate an active workload and return the NSPs to idle. + +status + Query the QSM about it's NNC implementation. Returns the NNC version, + and if CRC is used. + +terminate + Release a user's resources. + +dma_xfer_cont + Continuation of a previous DMA transfer. If a DMA transfer + cannot be specified in a single message (highly fragmented), this + transaction can be used to specify more ranges. + +validate_partition + Query to QSM to determine if a partition identifier is valid. + +Each message is tagged with a user id, and a partition id. The user id allows +QSM to track resources, and release them when the user goes away (eg the process +crashes). A partition id identifies the resource partition that QSM manages, +which this message applies to. + +Messages may have CRCs. Messages should have CRCs applied until the QSM +reports via the status transaction that CRCs are not needed. The QSM on the +SA9000P requires CRCs for black channel safing. + +Subsystem Restart (SSR) +======================= + +SSR is the concept of limiting the impact of an error. An AIC100 device may +have multiple users, each with their own workload running. If the workload of +one user crashes, the fallout of that should be limited to that workload and not +impact other workloads. SSR accomplishes this. + +If a particular workload crashes, QSM notifies the host via the QAIC_SSR MHI +channel. This notification identifies the workload by it's assigned DBC. A +multi-stage recovery process is then used to cleanup both sides, and get the +DBC/NSPs into a working state. + +When SSR occurs, any state in the workload is lost. Any inputs that were in +process, or queued by not yet serviced, are lost. The loaded artifacts will +remain in on-card DDR, but the host will need to re-activate the workload if +it desires to recover the workload. + +Reliability, Accessibility, Serviceability (RAS) +================================================ + +AIC100 is expected to be deployed in server systems where RAS ideology is +applied. Simply put, RAS is the concept of detecting, classifying, and +reporting errors. While PCIe has AER (Advanced Error Reporting) which factors +into RAS, AER does not allow for a device to report details about internal +errors. Therefore, AIC100 implements a custom RAS mechanism. When a RAS event +occurs, QSM will report the event with appropriate details via the QAIC_STATUS +MHI channel. A sysadmin may determine that a particular device needs +additional service based on RAS reports. + +Telemetry +========= + +QSM has the ability to report various physical attributes of the device, and in +some cases, to allow the host to control them. Examples include thermal limits, +thermal readings, and power readings. These items are communicated via the +QAIC_TELEMETRY MHI channel. diff --git a/Documentation/accel/qaic/index.rst b/Documentation/accel/qaic/index.rst new file mode 100644 index 000000000000..ad19b88d1a66 --- /dev/null +++ b/Documentation/accel/qaic/index.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +===================================== + accel/qaic Qualcomm Cloud AI driver +===================================== + +The accel/qaic driver supports the Qualcomm Cloud AI machine learning +accelerator cards. + +.. toctree:: + + qaic + aic100 diff --git a/Documentation/accel/qaic/qaic.rst b/Documentation/accel/qaic/qaic.rst new file mode 100644 index 000000000000..72a70ab6e3a8 --- /dev/null +++ b/Documentation/accel/qaic/qaic.rst @@ -0,0 +1,170 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +============= + QAIC driver +============= + +The QAIC driver is the Kernel Mode Driver (KMD) for the AIC100 family of AI +accelerator products. + +Interrupts +========== + +While the AIC100 DMA Bridge hardware implements an IRQ storm mitigation +mechanism, it is still possible for an IRQ storm to occur. A storm can happen +if the workload is particularly quick, and the host is responsive. If the host +can drain the response FIFO as quickly as the device can insert elements into +it, then the device will frequently transition the response FIFO from empty to +non-empty and generate MSIs at a rate equivalent to the speed of the +workload's ability to process inputs. The lprnet (license plate reader network) +workload is known to trigger this condition, and can generate in excess of 100k +MSIs per second. It has been observed that most systems cannot tolerate this +for long, and will crash due to some form of watchdog due to the overhead of +the interrupt controller interrupting the host CPU. + +To mitigate this issue, the QAIC driver implements specific IRQ handling. When +QAIC receives an IRQ, it disables that line. This prevents the interrupt +controller from interrupting the CPU. Then AIC drains the FIFO. Once the FIFO +is drained, QAIC implements a "last chance" polling algorithm where QAIC will +sleep for a time to see if the workload will generate more activity. The IRQ +line remains disabled during this time. If no activity is detected, QAIC exits +polling mode and reenables the IRQ line. + +This mitigation in QAIC is very effective. The same lprnet usecase that +generates 100k IRQs per second (per /proc/interrupts) is reduced to roughly 64 +IRQs over 5 minutes while keeping the host system stable, and having the same +workload throughput performance (within run to run noise variation). + + +Neural Network Control (NNC) Protocol +===================================== + +The implementation of NNC is split between the KMD (QAIC) and UMD. In general +QAIC understands how to encode/decode NNC wire protocol, and elements of the +protocol which require kernel space knowledge to process (for example, mapping +host memory to device IOVAs). QAIC understands the structure of a message, and +all of the transactions. QAIC does not understand commands (the payload of a +passthrough transaction). + +QAIC handles and enforces the required little endianness and 64-bit alignment, +to the degree that it can. Since QAIC does not know the contents of a +passthrough transaction, it relies on the UMD to satisfy the requirements. + +The terminate transaction is of particular use to QAIC. QAIC is not aware of +the resources that are loaded onto a device since the majority of that activity +occurs within NNC commands. As a result, QAIC does not have the means to +roll back userspace activity. To ensure that a userspace client's resources +are fully released in the case of a process crash, or a bug, QAIC uses the +terminate command to let QSM know when a user has gone away, and the resources +can be released. + +QSM can report a version number of the NNC protocol it supports. This is in the +form of a Major number and a Minor number. + +Major number updates indicate changes to the NNC protocol which impact the +message format, or transactions (impacts QAIC). + +Minor number updates indicate changes to the NNC protocol which impact the +commands (does not impact QAIC). + +uAPI +==== + +QAIC defines a number of driver specific IOCTLs as part of the userspace API. +This section describes those APIs. + +DRM_IOCTL_QAIC_MANAGE + This IOCTL allows userspace to send a NNC request to the QSM. The call will + block until a response is received, or the request has timed out. + +DRM_IOCTL_QAIC_CREATE_BO + This IOCTL allows userspace to allocate a buffer object (BO) which can send + or receive data from a workload. The call will return a GEM handle that + represents the allocated buffer. The BO is not usable until it has been + sliced (see DRM_IOCTL_QAIC_ATTACH_SLICE_BO). + +DRM_IOCTL_QAIC_MMAP_BO + This IOCTL allows userspace to prepare an allocated BO to be mmap'd into the + userspace process. + +DRM_IOCTL_QAIC_ATTACH_SLICE_BO + This IOCTL allows userspace to slice a BO in preparation for sending the BO + to the device. Slicing is the operation of describing what portions of a BO + get sent where to a workload. This requires a set of DMA transfers for the + DMA Bridge, and as such, locks the BO to a specific DBC. + +DRM_IOCTL_QAIC_EXECUTE_BO + This IOCTL allows userspace to submit a set of sliced BOs to the device. The + call is non-blocking. Success only indicates that the BOs have been queued + to the device, but does not guarantee they have been executed. + +DRM_IOCTL_QAIC_PARTIAL_EXECUTE_BO + This IOCTL operates like DRM_IOCTL_QAIC_EXECUTE_BO, but it allows userspace + to shrink the BOs sent to the device for this specific call. If a BO + typically has N inputs, but only a subset of those is available, this IOCTL + allows userspace to indicate that only the first M bytes of the BO should be + sent to the device to minimize data transfer overhead. This IOCTL dynamically + recomputes the slicing, and therefore has some processing overhead before the + BOs can be queued to the device. + +DRM_IOCTL_QAIC_WAIT_BO + This IOCTL allows userspace to determine when a particular BO has been + processed by the device. The call will block until either the BO has been + processed and can be re-queued to the device, or a timeout occurs. + +DRM_IOCTL_QAIC_PERF_STATS_BO + This IOCTL allows userspace to collect performance statistics on the most + recent execution of a BO. This allows userspace to construct an end to end + timeline of the BO processing for a performance analysis. + +DRM_IOCTL_QAIC_PART_DEV + This IOCTL allows userspace to request a duplicate "shadow device". This extra + accelN device is associated with a specific partition of resources on the + AIC100 device and can be used for limiting a process to some subset of + resources. + +Userspace Client Isolation +========================== + +AIC100 supports multiple clients. Multiple DBCs can be consumed by a single +client, and multiple clients can each consume one or more DBCs. Workloads +may contain sensitive information therefore only the client that owns the +workload should be allowed to interface with the DBC. + +Clients are identified by the instance associated with their open(). A client +may only use memory they allocate, and DBCs that are assigned to their +workloads. Attempts to access resources assigned to other clients will be +rejected. + +Module parameters +================= + +QAIC supports the following module parameters: + +**datapath_polling (bool)** + +Configures QAIC to use a polling thread for datapath events instead of relying +on the device interrupts. Useful for platforms with broken multiMSI. Must be +set at QAIC driver initialization. Default is 0 (off). + +**mhi_timeout_ms (unsigned int)** + +Sets the timeout value for MHI operations in milliseconds (ms). Must be set +at the time the driver detects a device. Default is 2000 (2 seconds). + +**control_resp_timeout_s (unsigned int)** + +Sets the timeout value for QSM responses to NNC messages in seconds (s). Must +be set at the time the driver is sending a request to QSM. Default is 60 (one +minute). + +**wait_exec_default_timeout_ms (unsigned int)** + +Sets the default timeout for the wait_exec ioctl in milliseconds (ms). Must be +set prior to the waic_exec ioctl call. A value specified in the ioctl call +overrides this for that call. Default is 5000 (5 seconds). + +**datapath_poll_interval_us (unsigned int)** + +Sets the polling interval in microseconds (us) when datapath polling is active. +Takes effect at the next polling interval. Default is 100 (100 us). diff --git a/Documentation/accounting/delay-accounting.rst b/Documentation/accounting/delay-accounting.rst index 7103b62ba6d7..f61c01fc376e 100644 --- a/Documentation/accounting/delay-accounting.rst +++ b/Documentation/accounting/delay-accounting.rst @@ -16,6 +16,7 @@ d) memory reclaim e) thrashing f) direct compact g) write-protect copy +h) IRQ/SOFTIRQ and makes these statistics available to userspace through the taskstats interface. @@ -49,7 +50,7 @@ this structure. See for a description of the fields pertaining to delay accounting. It will generally be in the form of counters returning the cumulative delay seen for cpu, sync block I/O, swapin, memory reclaim, thrash page -cache, direct compact, write-protect copy etc. +cache, direct compact, write-protect copy, IRQ/SOFTIRQ etc. Taking the difference of two successive readings of a given counter (say cpu_delay_total) for a task will give the delay @@ -109,17 +110,19 @@ Get sum of delays, since system boot, for all pids with tgid 5:: CPU count real total virtual total delay total delay average 8 7000000 6872122 3382277 0.423ms IO count delay total delay average - 0 0 0ms + 0 0 0.000ms SWAP count delay total delay average - 0 0 0ms + 0 0 0.000ms RECLAIM count delay total delay average - 0 0 0ms + 0 0 0.000ms THRASHING count delay total delay average - 0 0 0ms + 0 0 0.000ms COMPACT count delay total delay average - 0 0 0ms - WPCOPY count delay total delay average - 0 0 0ms + 0 0 0.000ms + WPCOPY count delay total delay average + 0 0 0.000ms + IRQ count delay total delay average + 0 0 0.000ms Get IO accounting for pid 1, it works only with -p:: diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst index 5e40b3f437f9..df6062eb3abb 100644 --- a/Documentation/accounting/psi.rst +++ b/Documentation/accounting/psi.rst @@ -105,6 +105,10 @@ prevent overly frequent polling. Max limit is chosen as a high enough number after which monitors are most likely not needed and psi averages can be used instead. +Unprivileged users can also create monitors, with the only limitation that the +window size must be a multiple of 2s, in order to prevent excessive resource +usage. + When activated, psi monitor stays active for at least the duration of one tracking window to avoid repeated activations/deactivations when system is bouncing in and out of the stall state. diff --git a/Documentation/admin-guide/cgroup-v1/cpusets.rst b/Documentation/admin-guide/cgroup-v1/cpusets.rst index 5d844ed4df69..ae646d621a8a 100644 --- a/Documentation/admin-guide/cgroup-v1/cpusets.rst +++ b/Documentation/admin-guide/cgroup-v1/cpusets.rst @@ -719,7 +719,7 @@ There are ways to query or modify cpusets: cat, rmdir commands from the shell, or their equivalent from C. - via the C library libcpuset. - via the C library libcgroup. - (http://sourceforge.net/projects/libcg/) + (https://github.com/libcgroup/libcgroup/) - via the python application cset. (http://code.google.com/p/cpuset/) diff --git a/Documentation/admin-guide/device-mapper/dm-flakey.rst b/Documentation/admin-guide/device-mapper/dm-flakey.rst index 86138735879d..f7104c01b0f7 100644 --- a/Documentation/admin-guide/device-mapper/dm-flakey.rst +++ b/Documentation/admin-guide/device-mapper/dm-flakey.rst @@ -39,6 +39,10 @@ Optional feature parameters: If no feature parameters are present, during the periods of unreliability, all I/O returns errors. + error_reads: + All read I/O is failed with an error signalled. + Write I/O is handled correctly. + drop_writes: All write I/O is silently ignored. Read I/O is handled correctly. diff --git a/Documentation/admin-guide/ext4.rst b/Documentation/admin-guide/ext4.rst index 4c559e08d11e..5740d85439ff 100644 --- a/Documentation/admin-guide/ext4.rst +++ b/Documentation/admin-guide/ext4.rst @@ -489,9 +489,6 @@ Files in /sys/fs/ext4/<devname>: multiple of this tuning parameter if the stripe size is not set in the ext4 superblock - mb_max_inode_prealloc - The maximum length of per-inode ext4_prealloc_space list. - mb_max_to_scan The maximum number of extents the multiblock allocator will search to find the best extent. diff --git a/Documentation/admin-guide/gpio/sysfs.rst b/Documentation/admin-guide/gpio/sysfs.rst index ec09ffd983e7..35171d15f78d 100644 --- a/Documentation/admin-guide/gpio/sysfs.rst +++ b/Documentation/admin-guide/gpio/sysfs.rst @@ -145,7 +145,7 @@ requested using gpio_request():: /* export the GPIO to userspace */ int gpiod_export(struct gpio_desc *desc, bool direction_may_change); - /* reverse gpio_export() */ + /* reverse gpiod_export() */ void gpiod_unexport(struct gpio_desc *desc); /* create a sysfs link to an exported GPIO node */ diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst index f491de74ea79..48ca0bd85604 100644 --- a/Documentation/admin-guide/hw-vuln/mds.rst +++ b/Documentation/admin-guide/hw-vuln/mds.rst @@ -58,7 +58,7 @@ Because the buffers are potentially shared between Hyper-Threads cross Hyper-Thread attacks are possible. Deeper technical information is available in the MDS specific x86 -architecture section: :ref:`Documentation/x86/mds.rst <mds>`. +architecture section: :ref:`Documentation/arch/x86/mds.rst <mds>`. Attack scenarios diff --git a/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst b/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst index 76673affd917..014167ef8dd1 100644 --- a/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst +++ b/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst @@ -63,7 +63,7 @@ attacker needs to begin a TSX transaction and raise an asynchronous abort which in turn potentially leaks data stored in the buffers. More detailed technical information is available in the TAA specific x86 -architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`. +architecture section: :ref:`Documentation/arch/x86/tsx_async_abort.rst <tsx_async_abort>`. Attack scenarios diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 0ad7e7ec0d27..43ea35613dfc 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -36,7 +36,7 @@ problems and bugs in particular. reporting-issues reporting-regressions - security-bugs + quickly-build-trimmed-linux bug-hunting bug-bisect tainted-kernels diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 86fd88492870..c18d94fa6470 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -172,7 +172,7 @@ variables. Offset of the free_list's member. This value is used to compute the number of free pages. -Each zone has a free_area structure array called free_area[MAX_ORDER]. +Each zone has a free_area structure array called free_area[MAX_ORDER + 1]. The free_list represents a linked list of free page blocks. (list_head, next|prev) @@ -189,8 +189,8 @@ Offsets of the vmap_area's members. They carry vmalloc-specific information. Makedumpfile gets the start address of the vmalloc region from this. -(zone.free_area, MAX_ORDER) ---------------------------- +(zone.free_area, MAX_ORDER + 1) +------------------------------- Free areas descriptor. User-space tools use this value to iterate the free_area ranges. MAX_ORDER is used by the zone buddy allocator. diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 19600c50277b..1ba8f2a44aac 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -128,10 +128,11 @@ parameter is applicable:: KVM Kernel Virtual Machine support is enabled. LIBATA Libata driver is enabled LP Printer support is enabled. + LOONGARCH LoongArch architecture is enabled. LOOP Loopback device support is enabled. M68k M68k architecture is enabled. These options have more detailed description inside of - Documentation/m68k/kernel-options.rst. + Documentation/arch/m68k/kernel-options.rst. MDA MDA console support is enabled. MIPS MIPS architecture is enabled. MOUSE Appropriate mouse support is enabled. @@ -177,7 +178,7 @@ parameter is applicable:: X86-32 X86-32, aka i386 architecture is enabled. X86-64 X86-64 architecture is enabled. More X86-64 boot options can be found in - Documentation/x86/x86_64/boot-options.rst. + Documentation/arch/x86/x86_64/boot-options.rst. X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64) X86_UV SGI UV support is enabled. XEN Xen support is enabled @@ -192,10 +193,10 @@ In addition, the following text indicates that the option:: Parameters denoted with BOOT are actually interpreted by the boot loader, and have no meaning to the kernel directly. Do not modify the syntax of boot loader parameters without extreme -need or coordination with <Documentation/x86/boot.rst>. +need or coordination with <Documentation/arch/x86/boot.rst>. There are also arch-specific kernel-parameters not documented here. -See for example <Documentation/x86/x86_64/boot-options.rst>. +See for example <Documentation/arch/x86/x86_64/boot-options.rst>. Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 6221a1d057dd..9e5bab29685f 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -339,6 +339,29 @@ This mode requires kvm-amd.avic=1. (Default when IOMMU HW support is present.) + amd_pstate= [X86] + disable + Do not enable amd_pstate as the default + scaling driver for the supported processors + passive + Use amd_pstate with passive mode as a scaling driver. + In this mode autonomous selection is disabled. + Driver requests a desired performance level and platform + tries to match the same performance level if it is + satisfied by guaranteed performance level. + active + Use amd_pstate_epp driver instance as the scaling driver, + driver provides a hint to the hardware if software wants + to bias toward performance (0x0) or energy efficiency (0xff) + to the CPPC firmware. then CPPC power algorithm will + calculate the runtime workload and adjust the realtime cores + frequency. + guided + Activate guided autonomous mode. Driver requests minimum and + maximum performance level and the platform autonomously + selects a performance level in this range and appropriate + to the current workload. + amijoy.map= [HW,JOY] Amiga joystick support Map of devices attached to JOY0DAT and JOY1DAT Format: <a>,<b> @@ -889,15 +912,14 @@ cs89x0_media= [HW,NET] Format: { rj45 | aui | bnc } - csdlock_debug= [KNL] Enable debug add-ons of cross-CPU function call - handling. When switched on, additional debug data is - printed to the console in case a hanging CPU is - detected, and that CPU is pinged again in order to try - to resolve the hang situation. - 0: disable csdlock debugging (default) - 1: enable basic csdlock debugging (minor impact) - ext: enable extended csdlock debugging (more impact, - but more data) + csdlock_debug= [KNL] Enable or disable debug add-ons of cross-CPU + function call handling. When switched on, + additional debug data is printed to the console + in case a hanging CPU is detected, and that + CPU is pinged again in order to try to resolve + the hang situation. The default value of this + option depends on the CSD_LOCK_WAIT_DEBUG_DEFAULT + Kconfig option. dasd= [HW,NET] See header of drivers/s390/block/dasd_devmap.c. @@ -929,9 +951,6 @@ debug_objects [KNL] Enable object debugging - no_debug_objects - [KNL] Disable object debugging - debug_guardpage_minorder= [KNL] When CONFIG_DEBUG_PAGEALLOC is set, this parameter allows control of the order of pages that will @@ -1582,6 +1601,20 @@ dependencies. This only applies for fw_devlink=on|rpm. Format: <bool> + fw_devlink.sync_state = + [KNL] When all devices that could probe have finished + probing, this parameter controls what to do with + devices that haven't yet received their sync_state() + calls. + Format: { strict | timeout } + strict -- Default. Continue waiting on consumers to + probe successfully. + timeout -- Give up waiting on consumers and call + sync_state() on any devices that haven't yet + received their sync_state() calls after + deferred_probe_timeout has expired or by + late_initcall() if !CONFIG_MODULES. + gamecon.map[2|3]= [HW,JOY] Multisystem joystick and NES/SNES/PSX pad support via parallel port (up to 5 devices per port) @@ -2976,7 +3009,7 @@ mce [X86-32] Machine Check Exception - mce=option [X86-64] See Documentation/x86/x86_64/boot-options.rst + mce=option [X86-64] See Documentation/arch/x86/x86_64/boot-options.rst md= [HW] RAID subsystems devices and level See Documentation/admin-guide/md.rst. @@ -3184,9 +3217,6 @@ deep - Suspend-To-RAM or equivalent (if supported) See Documentation/admin-guide/pm/sleep-states.rst. - meye.*= [HW] Set MotionEye Camera parameters - See Documentation/admin-guide/media/meye.rst. - mfgpt_irq= [IA-32] Specify the IRQ to use for the Multi-Function General Purpose Timers on AMD Geode platforms. @@ -3332,6 +3362,12 @@ specified, <module>.async_probe takes precedence for the specific module. + module.enable_dups_trace + [KNL] When CONFIG_MODULE_DEBUG_AUTOLOAD_DUPS is set, + this means that duplicate request_module() calls will + trigger a WARN_ON() instead of a pr_warn(). Note that + if MODULE_DEBUG_AUTOLOAD_DUPS_TRACE is set, WARN_ON()s + will always be issued and this option does nothing. module.sig_enforce [KNL] When CONFIG_MODULE_SIG is set, this means that modules without (valid) signatures will fail to load. @@ -3428,14 +3464,13 @@ 1 to enable accounting Default value is 0. - nfsaddrs= [NFS] Deprecated. Use ip= instead. - See Documentation/admin-guide/nfs/nfsroot.rst. - - nfsroot= [NFS] nfs root filesystem for disk-less boxes. - See Documentation/admin-guide/nfs/nfsroot.rst. + nfs.cache_getent= + [NFS] sets the pathname to the program which is used + to update the NFS client cache entries. - nfsrootdebug [NFS] enable nfsroot debugging messages. - See Documentation/admin-guide/nfs/nfsroot.rst. + nfs.cache_getent_timeout= + [NFS] sets the timeout after which an attempt to + update a cache entry is deemed to have failed. nfs.callback_nr_threads= [NFSv4] set the total number of threads that the @@ -3446,18 +3481,6 @@ [NFS] set the TCP port on which the NFSv4 callback channel should listen. - nfs.cache_getent= - [NFS] sets the pathname to the program which is used - to update the NFS client cache entries. - - nfs.cache_getent_timeout= - [NFS] sets the timeout after which an attempt to - update a cache entry is deemed to have failed. - - nfs.idmap_cache_timeout= - [NFS] set the maximum lifetime for idmapper cache - entries. - nfs.enable_ino64= [NFS] enable 64-bit inode numbers. If zero, the NFS client will fake up a 32-bit inode @@ -3465,6 +3488,10 @@ of returning the full 64-bit number. The default is to return 64-bit inode numbers. + nfs.idmap_cache_timeout= + [NFS] set the maximum lifetime for idmapper cache + entries. + nfs.max_session_cb_slots= [NFSv4.1] Sets the maximum number of session slots the client will assign to the callback @@ -3492,21 +3519,14 @@ will be autodetected by the client, and it will fall back to using the idmapper. To turn off this behaviour, set the value to '0'. + nfs.nfs4_unique_id= [NFS4] Specify an additional fixed unique ident- ification string that NFSv4 clients can insert into their nfs_client_id4 string. This is typically a UUID that is generated at system install time. - nfs.send_implementation_id = - [NFSv4.1] Send client implementation identification - information in exchange_id requests. - If zero, no implementation identification information - will be sent. - The default is to send the implementation identification - information. - - nfs.recover_lost_locks = + nfs.recover_lost_locks= [NFSv4] Attempt to recover locks that were lost due to a lease timeout on the server. Please note that doing this risks data corruption, since there are @@ -3518,7 +3538,15 @@ The default parameter value of '0' causes the kernel not to attempt recovery of lost locks. - nfs4.layoutstats_timer = + nfs.send_implementation_id= + [NFSv4.1] Send client implementation identification + information in exchange_id requests. + If zero, no implementation identification information + will be sent. + The default is to send the implementation identification + information. + + nfs4.layoutstats_timer= [NFSv4.2] Change the rate at which the kernel sends layoutstats to the pNFS metadata server. @@ -3527,12 +3555,19 @@ driver. A non-zero value sets the minimum interval in seconds between layoutstats transmissions. - nfsd.inter_copy_offload_enable = + nfsd.inter_copy_offload_enable= [NFSv4.2] When set to 1, the server will support server-to-server copies for which this server is the destination of the copy. - nfsd.nfsd4_ssc_umount_timeout = + nfsd.nfs4_disable_idmapping= + [NFSv4] When set to the default of '1', the NFSv4 + server will return only numeric uids and gids to + clients using auth_sys, and will accept numeric uids + and gids from such clients. This is intended to ease + migration from NFSv2/v3. + + nfsd.nfsd4_ssc_umount_timeout= [NFSv4.2] When used as the destination of a server-to-server copy, knfsd temporarily mounts the source server. It caches the mount in case @@ -3540,13 +3575,14 @@ used for the number of milliseconds specified by this parameter. - nfsd.nfs4_disable_idmapping= - [NFSv4] When set to the default of '1', the NFSv4 - server will return only numeric uids and gids to - clients using auth_sys, and will accept numeric uids - and gids from such clients. This is intended to ease - migration from NFSv2/v3. + nfsaddrs= [NFS] Deprecated. Use ip= instead. + See Documentation/admin-guide/nfs/nfsroot.rst. + nfsroot= [NFS] nfs root filesystem for disk-less boxes. + See Documentation/admin-guide/nfs/nfsroot.rst. + + nfsrootdebug [NFS] enable nfsroot debugging messages. + See Documentation/admin-guide/nfs/nfsroot.rst. nmi_backtrace.backtrace_idle [KNL] Dump stacks even of idle CPUs in response to an @@ -3576,10 +3612,27 @@ emulation library even if a 387 maths coprocessor is present. - no5lvl [X86-64] Disable 5-level paging mode. Forces + no4lvl [RISCV] Disable 4-level and 5-level paging modes. Forces + kernel to use 3-level paging instead. + + no5lvl [X86-64,RISCV] Disable 5-level paging mode. Forces kernel to use 4-level paging instead. - nofsgsbase [X86] Disables FSGSBASE instructions. + noaliencache [MM, NUMA, SLAB] Disables the allocation of alien + caches in the slab allocator. Saves per-node memory, + but will impact performance. + + noalign [KNL,ARM] + + noaltinstr [S390] Disables alternative instructions patching + (CPU alternatives feature). + + noapic [SMP,APIC] Tells the kernel to not make use of any + IOAPICs that may be present in the system. + + noautogroup Disable scheduler automatic task group creation. + + nocache [ARM] no_console_suspend [HW] Never suspend the console @@ -3596,32 +3649,8 @@ /sys/module/printk/parameters/console_suspend) to turn on/off it dynamically. - novmcoredd [KNL,KDUMP] - Disable device dump. Device dump allows drivers to - append dump data to vmcore so you can collect driver - specified debug info. Drivers can append the data - without any limit and this data is stored in memory, - so this may cause significant memory stress. Disabling - device dump can help save memory but the driver debug - data will be no longer available. This parameter - is only available when CONFIG_PROC_VMCORE_DEVICE_DUMP - is set. - - noaliencache [MM, NUMA, SLAB] Disables the allocation of alien - caches in the slab allocator. Saves per-node memory, - but will impact performance. - - noalign [KNL,ARM] - - noaltinstr [S390] Disables alternative instructions patching - (CPU alternatives feature). - - noapic [SMP,APIC] Tells the kernel to not make use of any - IOAPICs that may be present in the system. - - noautogroup Disable scheduler automatic task group creation. - - nocache [ARM] + no_debug_objects + [KNL] Disable object debugging nodsp [SH] Disable hardware DSP at boot time. @@ -3631,14 +3660,6 @@ noexec [IA-64] - nosmap [PPC] - Disable SMAP (Supervisor Mode Access Prevention) - even if it is supported by processor. - - nosmep [PPC64s] - Disable SMEP (Supervisor Mode Execution Prevention) - even if it is supported by processor. - noexec32 [X86-64] This affects only 32-bit executables. noexec32=on: enable non-executable mappings (default) @@ -3646,74 +3667,18 @@ noexec32=off: disable non-executable mappings read implies executable mappings + no_file_caps Tells the kernel not to honor file capabilities. The + only way then for a file to be executed with privilege + is to be setuid root or executed by root. + nofpu [MIPS,SH] Disable hardware FPU at boot time. + nofsgsbase [X86] Disables FSGSBASE instructions. + nofxsr [BUGS=X86-32] Disables x86 floating point extended register save and restore. The kernel will only save legacy floating-point registers on task switch. - nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings. - - nohugevmalloc [KNL,X86,PPC,ARM64] Disable kernel huge vmalloc mappings. - - nosmt [KNL,S390] Disable symmetric multithreading (SMT). - Equivalent to smt=1. - - [KNL,X86] Disable symmetric multithreading (SMT). - nosmt=force: Force disable SMT, cannot be undone - via the sysfs control file. - - nospectre_v1 [X86,PPC] Disable mitigations for Spectre Variant 1 - (bounds check bypass). With this option data leaks are - possible in the system. - - nospectre_v2 [X86,PPC_E500,ARM64] Disable all mitigations for - the Spectre variant 2 (indirect branch prediction) - vulnerability. System may allow data leaks with this - option. - - nospectre_bhb [ARM64] Disable all mitigations for Spectre-BHB (branch - history injection) vulnerability. System may allow data leaks - with this option. - - nospec_store_bypass_disable - [HW] Disable all mitigations for the Speculative Store Bypass vulnerability - - no_uaccess_flush - [PPC] Don't flush the L1-D cache after accessing user data. - - noxsave [BUGS=X86] Disables x86 extended register state save - and restore using xsave. The kernel will fallback to - enabling legacy floating-point and sse state. - - noxsaveopt [X86] Disables xsaveopt used in saving x86 extended - register states. The kernel will fall back to use - xsave to save the states. By using this parameter, - performance of saving the states is degraded because - xsave doesn't support modified optimization while - xsaveopt supports it on xsaveopt enabled systems. - - noxsaves [X86] Disables xsaves and xrstors used in saving and - restoring x86 extended register state in compacted - form of xsave area. The kernel will fall back to use - xsaveopt and xrstor to save and restore the states - in standard form of xsave area. By using this - parameter, xsave area per process might occupy more - memory on xsaves enabled systems. - - nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait - in do_idle() and not use the arch_cpu_idle() - implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP - to be effective. This is useful on platforms where the - sleep(SH) or wfi(ARM,ARM64) instructions do not work - correctly or when doing power measurements to evaluate - the impact of the sleep instructions. This is also - useful when using JTAG debugger. - - no_file_caps Tells the kernel not to honor file capabilities. The - only way then for a file to be executed with privilege - is to be setuid root or executed by root. - nohalt [IA-64] Tells the kernel not to use the power saving function PAL_HALT_LIGHT when idle. This increases power-consumption. On the positive side, it reduces @@ -3737,6 +3702,19 @@ nohibernate [HIBERNATION] Disable hibernation and resume. + nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait + in do_idle() and not use the arch_cpu_idle() + implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP + to be effective. This is useful on platforms where the + sleep(SH) or wfi(ARM,ARM64) instructions do not work + correctly or when doing power measurements to evaluate + the impact of the sleep instructions. This is also + useful when using JTAG debugger. + + nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings. + + nohugevmalloc [KNL,X86,PPC,ARM64] Disable kernel huge vmalloc mappings. + nohz= [KNL] Boottime enable/disable dynamic ticks Valid arguments: on, off Default: on @@ -3754,16 +3732,6 @@ Note that this argument takes precedence over the CONFIG_RCU_NOCB_CPU_DEFAULT_ALL option. - noiotrap [SH] Disables trapped I/O port accesses. - - noirqdebug [X86-32] Disables the code which attempts to detect and - disable unhandled interrupt sources. - - no_timer_check [X86,APIC] Disables the code which tests for - broken timer IRQ sources. - - noisapnp [ISAPNP] Disables ISA PnP code. - noinitrd [RAM] Tells the kernel not to load any configured initial RAM disk. @@ -3775,6 +3743,13 @@ noinvpcid [X86] Disable the INVPCID cpu feature. + noiotrap [SH] Disables trapped I/O port accesses. + + noirqdebug [X86-32] Disables the code which attempts to detect and + disable unhandled interrupt sources. + + noisapnp [ISAPNP] Disables ISA PnP code. + nojitter [IA-64] Disables jitter checking for ITC timers. nokaslr [KNL] @@ -3782,18 +3757,10 @@ kernel and module base offset ASLR (Address Space Layout Randomization). - no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver - no-kvmapf [X86,KVM] Disable paravirtualized asynchronous page fault handling. - no-vmw-sched-clock - [X86,PV_OPS] Disable paravirtualized VMware scheduler - clock and use the default one. - - no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES] Disable paravirtualized - steal time accounting. steal time is computed, but - won't influence scheduler behaviour + no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver nolapic [X86-32,APIC] Do not enable or use the local APIC. @@ -3806,10 +3773,6 @@ nomfgpt [X86-32] Disable Multi-Function General Purpose Timer usage (for AMD Geode machines). - nonmi_ipi [X86] Disable using NMI IPIs during panic/reboot to - shutdown the other cpus. Instead use the REBOOT_VECTOR - irq. - nomodeset Disable kernel modesetting. Most systems' firmware sets up a display mode and provides framebuffer memory for output. With nomodeset, DRM and fbdev drivers will @@ -3822,6 +3785,10 @@ nomodule Disable module load + nonmi_ipi [X86] Disable using NMI IPIs during panic/reboot to + shutdown the other cpus. Instead use the REBOOT_VECTOR + irq. + nopat [X86] Disable PAT (page attribute table extension of pagetables) support. @@ -3830,6 +3797,9 @@ nopku [X86] Disable Memory Protection Keys CPU feature found in some Intel CPUs. + nopti [X86-64] + Equivalent to pti=off + nopv= [X86,XEN,KVM,HYPER_V,VMWARE] Disables the PV optimizations forcing the guest to run as generic guest with no PV drivers. Currently support @@ -3849,21 +3819,77 @@ noresume [SWSUSP] Disables resume and restores original swap space. + nosbagart [IA-64] + no-scroll [VGA] Disables scrollback. This is required for the Braillex ib80-piezo Braille reader made by F.H. Papenmeier (Germany). - nosbagart [IA-64] - nosgx [X86-64,SGX] Disables Intel SGX kernel support. + nosmap [PPC] + Disable SMAP (Supervisor Mode Access Prevention) + even if it is supported by processor. + + nosmep [PPC64s] + Disable SMEP (Supervisor Mode Execution Prevention) + even if it is supported by processor. + nosmp [SMP] Tells an SMP kernel to act as a UP kernel, and disable the IO APIC. legacy for "maxcpus=0". + nosmt [KNL,S390] Disable symmetric multithreading (SMT). + Equivalent to smt=1. + + [KNL,X86] Disable symmetric multithreading (SMT). + nosmt=force: Force disable SMT, cannot be undone + via the sysfs control file. + nosoftlockup [KNL] Disable the soft-lockup detector. + nospec_store_bypass_disable + [HW] Disable all mitigations for the Speculative Store Bypass vulnerability + + nospectre_bhb [ARM64] Disable all mitigations for Spectre-BHB (branch + history injection) vulnerability. System may allow data leaks + with this option. + + nospectre_v1 [X86,PPC] Disable mitigations for Spectre Variant 1 + (bounds check bypass). With this option data leaks are + possible in the system. + + nospectre_v2 [X86,PPC_E500,ARM64] Disable all mitigations for + the Spectre variant 2 (indirect branch prediction) + vulnerability. System may allow data leaks with this + option. + + no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES] Disable paravirtualized + steal time accounting. steal time is computed, but + won't influence scheduler behaviour + nosync [HW,M68K] Disables sync negotiation for all devices. + no_timer_check [X86,APIC] Disables the code which tests for + broken timer IRQ sources. + + no_uaccess_flush + [PPC] Don't flush the L1-D cache after accessing user data. + + novmcoredd [KNL,KDUMP] + Disable device dump. Device dump allows drivers to + append dump data to vmcore so you can collect driver + specified debug info. Drivers can append the data + without any limit and this data is stored in memory, + so this may cause significant memory stress. Disabling + device dump can help save memory but the driver debug + data will be no longer available. This parameter + is only available when CONFIG_PROC_VMCORE_DEVICE_DUMP + is set. + + no-vmw-sched-clock + [X86,PV_OPS] Disable paravirtualized VMware scheduler + clock and use the default one. + nowatchdog [KNL] Disable both lockup detectors, i.e. soft-lockup and NMI watchdog (hard-lockup). @@ -3875,6 +3901,25 @@ LEGACY_XAPIC_DISABLED bit set in the IA32_XAPIC_DISABLE_STATUS MSR. + noxsave [BUGS=X86] Disables x86 extended register state save + and restore using xsave. The kernel will fallback to + enabling legacy floating-point and sse state. + + noxsaveopt [X86] Disables xsaveopt used in saving x86 extended + register states. The kernel will fall back to use + xsave to save the states. By using this parameter, + performance of saving the states is degraded because + xsave doesn't support modified optimization while + xsaveopt supports it on xsaveopt enabled systems. + + noxsaves [X86] Disables xsaves and xrstors used in saving and + restoring x86 extended register state in compacted + form of xsave area. The kernel will fall back to use + xsaveopt and xrstor to save and restore the states + in standard form of xsave area. By using this + parameter, xsave area per process might occupy more + memory on xsaves enabled systems. + nps_mtm_hs_ctr= [KNL,ARC] This parameter sets the maximum duration, in cycles, each HW thread of the CTOP can run @@ -3969,7 +4014,7 @@ [KNL] Minimal page reporting order Format: <integer> Adjust the minimal page reporting order. The page - reporting is disabled when it exceeds (MAX_ORDER-1). + reporting is disabled when it exceeds MAX_ORDER. panic= [KNL] Kernel behaviour on panic: delay <timeout> timeout > 0: seconds before rebooting @@ -4410,7 +4455,7 @@ and performance comparison. pirq= [SMP,APIC] Manual mp-table setup - See Documentation/x86/i386/IO-APIC.rst. + See Documentation/arch/x86/i386/IO-APIC.rst. plip= [PPT,NET] Parallel port network link Format: { parport<nr> | timid | 0 } @@ -4582,9 +4627,6 @@ Not specifying this option is equivalent to pti=auto. - nopti [X86-64] - Equivalent to pti=off - pty.legacy_count= [KNL] Number of legacy pty's. Overwrites compiled-in default number. @@ -5591,7 +5633,7 @@ serialnumber [BUGS=X86-32] - sev=option[,option...] [X86-64] See Documentation/x86/x86_64/boot-options.rst + sev=option[,option...] [X86-64] See Documentation/arch/x86/x86_64/boot-options.rst shapers= [NET] Maximal number of shapers. @@ -6130,15 +6172,6 @@ later by a loaded module cannot be set this way. Example: sysctl.vm.swappiness=40 - sysfs.deprecated=0|1 [KNL] - Enable/disable old style sysfs layout for old udev - on older distributions. When this option is enabled - very new udev will not work anymore. When this option - is disabled (or CONFIG_SYSFS_DEPRECATED not compiled) - in older udev will not work anymore. - Default depends on CONFIG_SYSFS_DEPRECATED_V2 set in - the kernel configuration. - sysrq_always_enabled [KNL] Ignore sysrq setting - this boot parameter will @@ -6770,7 +6803,7 @@ Can be used multiple times for multiple devices. vga= [BOOT,X86-32] Select a particular video mode - See Documentation/x86/boot.rst and + See Documentation/arch/x86/boot.rst and Documentation/admin-guide/svga.rst. Use vga=ask for menu. This is actually a boot loader parameter; the value is @@ -6933,6 +6966,12 @@ When enabled, memory and cache locality will be impacted. + writecombine= [LOONGARCH] Control the MAT (Memory Access Type) of + ioremap_wc(). + + on - Enable writecombine, use WUC for ioremap_wc() + off - Disable writecombine, use SUC for ioremap_wc() + x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of default x2apic cluster mode on platforms supporting x2apic. @@ -7059,20 +7098,3 @@ xmon commands. off xmon is disabled. - amd_pstate= [X86] - disable - Do not enable amd_pstate as the default - scaling driver for the supported processors - passive - Use amd_pstate as a scaling driver, driver requests a - desired performance on this abstract scale and the power - management firmware translates the requests into actual - hardware states (core frequency, data fabric and memory - clocks etc.) - active - Use amd_pstate_epp driver instance as the scaling driver, - driver provides a hint to the hardware if software wants - to bias toward performance (0x0) or energy efficiency (0xff) - to the CPPC firmware. then CPPC power algorithm will - calculate the runtime workload and adjust the realtime cores - frequency. diff --git a/Documentation/admin-guide/media/cec.rst b/Documentation/admin-guide/media/cec.rst index 14ec3ff317c2..6b30e355cf23 100644 --- a/Documentation/admin-guide/media/cec.rst +++ b/Documentation/admin-guide/media/cec.rst @@ -55,6 +55,15 @@ Miscellaneous: you can control the CEC line through this driver. This supports error injection as well. +- cec-gpio and Allwinner A10 (or any other driver that uses the CEC pin + framework to drive the CEC pin directly): the CEC pin framework uses + high-resolution timers. These timers are affected by NTP daemons that + speed up or slow down the clock to sync with the official time. The + chronyd server will by default increase or decrease the clock by + 1/12th. This will cause the CEC timings to go out of spec. To fix this, + add a 'maxslewrate 40000' line to chronyd.conf. This limits the clock + frequency change to 1/25th, which keeps the CEC timings within spec. + Utilities ========= @@ -296,69 +305,71 @@ broadcast messages twice to reduce the chance of them being lost. Specifically Making a CEC debugger ===================== -By using a Raspberry Pi 2B/3/4 and some cheap components you can make +By using a Raspberry Pi 4B and some cheap components you can make your own low-level CEC debugger. -Here is a picture of my setup: - -https://hverkuil.home.xs4all.nl/rpi3-cec.jpg - -It's a Raspberry Pi 3 together with a breadboard and some breadboard wires: - -http://www.dx.com/p/diy-40p-male-to-female-male-to-male-female-to-female-dupont-line-wire-3pcs-356089#.WYLOOXWGN7I - -Finally on of these HDMI female-female passthrough connectors (full soldering type 1): +The critical component is one of these HDMI female-female passthrough connectors +(full soldering type 1): https://elabbay.myshopify.com/collections/camera/products/hdmi-af-af-v1a-hdmi-type-a-female-to-hdmi-type-a-female-pass-through-adapter-breakout-board?variant=45533926147 -We've tested this and it works up to 4kp30 (297 MHz). The quality is not high -enough to pass-through 4kp60 (594 MHz). - -I also added an RTC and a breakout shield: - -https://www.amazon.com/Makerfire%C2%AE-Raspberry-Module-DS1307-Battery/dp/B00ZOXWHK4 +The video quality is variable and certainly not enough to pass-through 4kp60 +(594 MHz) video. You might be able to support 4kp30, but more likely you will +be limited to 1080p60 (148.5 MHz). But for CEC testing that is fine. -https://www.dx.com/p/raspberry-pi-gpio-expansion-board-breadboard-easy-multiplexing-board-one-to-three-with-screw-for-raspberry-pi-2-3-b-b-2729992.html#.YGRCG0MzZ7I +You need a breadboard and some breadboard wires: -These two are not needed but they make life a bit easier. +http://www.dx.com/p/diy-40p-male-to-female-male-to-male-female-to-female-dupont-line-wire-3pcs-356089#.WYLOOXWGN7I -If you want to monitor the HPD line as well, then you need one of these -level shifters: +If you want to monitor the HPD and/or 5V lines as well, then you need one of +these 5V to 3.3V level shifters: https://www.adafruit.com/product/757 (This is just where I got these components, there are many other places you can get similar things). +The ground pin of the HDMI connector needs to be connected to a ground +pin of the Raspberry Pi, of course. + The CEC pin of the HDMI connector needs to be connected to these pins: -CE0/IO8 and CE1/IO7 (pull-up GPIOs). The (optional) HPD pin of the HDMI -connector should be connected (via a level shifter to convert the 5V -to 3.3V) to these pins: IO17 and IO27. The (optional) 5V pin of the HDMI -connector should be connected (via a level shifter) to these pins: IO22 -and IO24. Monitoring the HPD an 5V lines is not necessary, but it is helpful. +GPIO 6 and GPIO 7. The optional HPD pin of the HDMI connector should +be connected via the level shifter to these pins: GPIO 23 and GPIO 12. +The optional 5V pin of the HDMI connector should be connected via the +level shifter to these pins: GPIO 25 and GPIO 22. Monitoring the HPD and +5V lines is not necessary, but it is helpful. -This kernel patch will hook up the cec-gpio driver correctly to -e.g. ``arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts``:: +This device tree addition in ``arch/arm/boot/dts/bcm2711-rpi-4-b.dts`` +will hook up the cec-gpio driver correctly:: + + cec@6 { + compatible = "cec-gpio"; + cec-gpios = <&gpio 6 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; + hpd-gpios = <&gpio 23 GPIO_ACTIVE_HIGH>; + v5-gpios = <&gpio 25 GPIO_ACTIVE_HIGH>; + }; cec@7 { compatible = "cec-gpio"; cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; - hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>; + hpd-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; v5-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>; }; - cec@8 { - compatible = "cec-gpio"; - cec-gpios = <&gpio 8 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; - hpd-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>; - v5-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>; - }; +If you haven't hooked up the HPD and/or 5V lines, then just delete those +lines. This dts change will enable two cec GPIO devices: I typically use one to send/receive CEC commands and the other to monitor. If you monitor using an unconfigured CEC adapter then it will use GPIO interrupts which makes monitoring very accurate. +If you just want to monitor traffic, then a single instance is sufficient. +The minimum configuration is one HDMI female-female passthrough connector +and two female-female breadboard wires: one for connecting the HDMI ground +pin to a ground pin on the Raspberry Pi, and the other to connect the HDMI +CEC pin to GPIO 6 on the Raspberry Pi. + The documentation on how to use the error injection is here: :ref:`cec_pin_error_inj`. ``cec-ctl --monitor-pin`` will do low-level CEC bus sniffing and analysis. diff --git a/Documentation/admin-guide/media/i2c-cardlist.rst b/Documentation/admin-guide/media/i2c-cardlist.rst index ef3b5fff3b01..1825a0bb47bd 100644 --- a/Documentation/admin-guide/media/i2c-cardlist.rst +++ b/Documentation/admin-guide/media/i2c-cardlist.rst @@ -72,17 +72,13 @@ imx319 Sony IMX319 sensor imx334 Sony IMX334 sensor imx355 Sony IMX355 sensor imx412 Sony IMX412 sensor -m5mols Fujitsu M-5MOLS 8MP sensor mt9m001 mt9m001 -mt9m032 MT9M032 camera sensor mt9m111 mt9m111, mt9m112 and mt9m131 mt9p031 Aptina MT9P031 -mt9t001 Aptina MT9T001 mt9t112 Aptina MT9T111/MT9T112 mt9v011 Micron mt9v011 sensor mt9v032 Micron MT9V032 sensor mt9v111 Aptina MT9V111 sensor -noon010pc30 Siliconfile NOON010PC30 sensor ov13858 OmniVision OV13858 sensor ov13b10 OmniVision OV13B10 sensor ov2640 OmniVision OV2640 sensor @@ -109,9 +105,6 @@ s5c73m3 Samsung S5C73M3 sensor s5k4ecgx Samsung S5K4ECGX sensor s5k5baf Samsung S5K5BAF sensor s5k6a3 Samsung S5K6A3 sensor -s5k6aa Samsung S5K6AAFX sensor -sr030pc30 Siliconfile SR030PC30 sensor -vs6624 ST VS6624 sensor ============ ========================================================== Flash devices @@ -222,7 +215,6 @@ Video encoders ============ ========================================================== Driver Name ============ ========================================================== -ad9389b Analog Devices AD9389B encoder adv7170 Analog Devices ADV7170 video encoder adv7175 Analog Devices ADV7175 video encoder adv7343 ADV7343 video encoder diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst index eed51a910c94..551083a396fb 100644 --- a/Documentation/admin-guide/mm/ksm.rst +++ b/Documentation/admin-guide/mm/ksm.rst @@ -157,6 +157,8 @@ stable_node_chains_prune_millisecs The effectiveness of KSM and MADV_MERGEABLE is shown in ``/sys/kernel/mm/ksm/``: +general_profit + how effective is KSM. The calculation is explained below. pages_shared how many shared pages are being used pages_sharing @@ -207,7 +209,8 @@ several times, which are unprofitable memory consumed. ksm_rmap_items * sizeof(rmap_item). where ksm_merging_pages is shown under the directory ``/proc/<pid>/``, - and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``. + and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``. The process profit + is also shown in ``/proc/<pid>/ksm_stat`` as ksm_process_profit. From the perspective of application, a high ratio of ``ksm_rmap_items`` to ``ksm_merging_pages`` means a bad madvise-applied policy, so developers or diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index b5f970dc91e7..c8f380271cad 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -91,9 +91,9 @@ Short descriptions to the page flags The page is being locked for exclusive access, e.g. by undergoing read/write IO. 7 - SLAB - The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator. - When compound page is used, SLUB/SLQB will only set this flag on the head - page; SLOB will not flag it at all. + The page is managed by the SLAB/SLUB kernel memory allocator. + When compound page is used, either will only set this flag on the head + page. 10 - BUDDY A free memory block managed by the buddy system allocator. The buddy system organizes free memory in blocks of various orders. diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst index 7dc823b56ca4..7c304e432205 100644 --- a/Documentation/admin-guide/mm/userfaultfd.rst +++ b/Documentation/admin-guide/mm/userfaultfd.rst @@ -219,6 +219,31 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was used. +Userfaultfd write-protect mode currently behave differently on none ptes +(when e.g. page is missing) over different types of memories. + +For anonymous memory, ``ioctl(UFFDIO_WRITEPROTECT)`` will ignore none ptes +(e.g. when pages are missing and not populated). For file-backed memories +like shmem and hugetlbfs, none ptes will be write protected just like a +present pte. In other words, there will be a userfaultfd write fault +message generated when writing to a missing page on file typed memories, +as long as the page range was write-protected before. Such a message will +not be generated on anonymous memories by default. + +If the application wants to be able to write protect none ptes on anonymous +memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ. On +newer kernels, one can also detect the feature UFFD_FEATURE_WP_UNPOPULATED +and set the feature bit in advance to make sure none ptes will also be +write protected even upon anonymous memory. + +When using ``UFFDIO_REGISTER_MODE_WP`` in combination with either +``UFFDIO_REGISTER_MODE_MISSING`` or ``UFFDIO_REGISTER_MODE_MINOR``, when +resolving missing / minor faults with ``UFFDIO_COPY`` or ``UFFDIO_CONTINUE`` +respectively, it may be desirable for the new page / mapping to be +write-protected (so future writes will also result in a WP fault). These ioctls +support a mode flag (``UFFDIO_COPY_MODE_WP`` or ``UFFDIO_CONTINUE_MODE_WP`` +respectively) to configure the mapping this way. + QEMU/KVM ======== diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst index 6e5298b521b1..1cf40f69278c 100644 --- a/Documentation/admin-guide/pm/amd-pstate.rst +++ b/Documentation/admin-guide/pm/amd-pstate.rst @@ -303,13 +303,18 @@ efficiency frequency management method on AMD processors. AMD Pstate Driver Operation Modes ================================= -``amd_pstate`` CPPC has two operation modes: CPPC Autonomous(active) mode and -CPPC non-autonomous(passive) mode. -active mode and passive mode can be chosen by different kernel parameters. -When in Autonomous mode, CPPC ignores requests done in the Desired Performance -Target register and takes into account only the values set to the Minimum requested -performance, Maximum requested performance, and Energy Performance Preference -registers. When Autonomous is disabled, it only considers the Desired Performance Target. +``amd_pstate`` CPPC has 3 operation modes: autonomous (active) mode, +non-autonomous (passive) mode and guided autonomous (guided) mode. +Active/passive/guided mode can be chosen by different kernel parameters. + +- In autonomous mode, platform ignores the desired performance level request + and takes into account only the values set to the minimum, maximum and energy + performance preference registers. +- In non-autonomous mode, platform gets desired performance level + from OS directly through Desired Performance Register. +- In guided-autonomous mode, platform sets operating performance level + autonomously according to the current workload and within the limits set by + OS through min and max performance registers. Active Mode ------------ @@ -338,6 +343,15 @@ to the Performance Reduction Tolerance register. Above the nominal performance l processor must provide at least nominal performance requested and go higher if current operating conditions allow. +Guided Mode +----------- + +``amd_pstate=guided`` + +If ``amd_pstate=guided`` is passed to kernel command line option then this mode +is activated. In this mode, driver requests minimum and maximum performance +level and the platform autonomously selects a performance level in this range +and appropriate to the current workload. User Space Interface in ``sysfs`` - General =========================================== @@ -358,6 +372,9 @@ control its functionality at the system level. They are located in the "passive" The driver is functional and in the ``passive mode`` + "guided" + The driver is functional and in the ``guided mode`` + "disable" The driver is unregistered and not functional now. diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst new file mode 100644 index 000000000000..ff4f4cc8522b --- /dev/null +++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst @@ -0,0 +1,1092 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) +.. [see the bottom of this file for redistribution information] + +=========================================== +How to quickly build a trimmed Linux kernel +=========================================== + +This guide explains how to swiftly build Linux kernels that are ideal for +testing purposes, but perfectly fine for day-to-day use, too. + +The essence of the process (aka 'TL;DR') +======================================== + +*[If you are new to compiling Linux, ignore this TLDR and head over to the next +section below: it contains a step-by-step guide, which is more detailed, but +still brief and easy to follow; that guide and its accompanying reference +section also mention alternatives, pitfalls, and additional aspects, all of +which might be relevant for you.]* + +If your system uses techniques like Secure Boot, prepare it to permit starting +self-compiled Linux kernels; install compilers and everything else needed for +building Linux; make sure to have 12 Gigabyte free space in your home directory. +Now run the following commands to download fresh Linux mainline sources, which +you then use to configure, build and install your own kernel:: + + git clone --depth 1 -b master \ + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux/ + cd ~/linux/ + # Hint: if you want to apply patches, do it at this point. See below for details. + # Hint: it's recommended to tag your build at this point. See below for details. + yes "" | make localmodconfig + # Hint: at this point you might want to adjust the build configuration; you'll + # have to, if you are running Debian. See below for details. + make -j $(nproc --all) + # Note: on many commodity distributions the next command suffices, but on Arch + # Linux, its derivatives, and some others it does not. See below for details. + command -v installkernel && sudo make modules_install install + reboot + +If you later want to build a newer mainline snapshot, use these commands:: + + cd ~/linux/ + git fetch --depth 1 origin + # Note: the next command will discard any changes you did to the code: + git checkout --force --detach origin/master + # Reminder: if you want to (re)apply patches, do it at this point. + # Reminder: you might want to add or modify a build tag at this point. + make olddefconfig + make -j $(nproc --all) + # Reminder: the next command on some distributions does not suffice. + command -v installkernel && sudo make modules_install install + reboot + +Step-by-step guide +================== + +Compiling your own Linux kernel is easy in principle. There are various ways to +do it. Which of them actually work and is the best depends on the circumstances. + +This guide describes a way perfectly suited for those who want to quickly +install Linux from sources without being bothered by complicated details; the +goal is to cover everything typically needed on mainstream Linux distributions +running on commodity PC or server hardware. + +The described approach is great for testing purposes, for example to try a +proposed fix or to check if a problem was already fixed in the latest codebase. +Nonetheless, kernels built this way are also totally fine for day-to-day use +while at the same time being easy to keep up to date. + +The following steps describe the important aspects of the process; a +comprehensive reference section later explains each of them in more detail. It +sometimes also describes alternative approaches, pitfalls, as well as errors +that might occur at a particular point -- and how to then get things rolling +again. + +.. + Note: if you see this note, you are reading the text's source file. You + might want to switch to a rendered version, as it makes it a lot easier to + quickly look something up in the reference section and afterwards jump back + to where you left off. Find a the latest rendered version here: + https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html + +.. _backup_sbs: + + * Create a fresh backup and put system repair and restore tools at hand, just + to be prepared for the unlikely case of something going sideways. + + [:ref:`details<backup>`] + +.. _secureboot_sbs: + + * On platforms with 'Secure Boot' or similar techniques, prepare everything to + ensure the system will permit your self-compiled kernel to boot later. The + quickest and easiest way to achieve this on commodity x86 systems is to + disable such techniques in the BIOS setup utility; alternatively, remove + their restrictions through a process initiated by + ``mokutil --disable-validation``. + + [:ref:`details<secureboot>`] + +.. _buildrequires_sbs: + + * Install all software required to build a Linux kernel. Often you will need: + 'bc', 'binutils' ('ld' et al.), 'bison', 'flex', 'gcc', 'git', 'openssl', + 'pahole', 'perl', and the development headers for 'libelf' and 'openssl'. The + reference section shows how to quickly install those on various popular Linux + distributions. + + [:ref:`details<buildrequires>`] + +.. _diskspace_sbs: + + * Ensure to have enough free space for building and installing Linux. For the + latter 150 Megabyte in /lib/ and 100 in /boot/ are a safe bet. For storing + sources and build artifacts 12 Gigabyte in your home directory should + typically suffice. If you have less available, be sure to check the reference + section for the step that explains adjusting your kernels build + configuration: it mentions a trick that reduce the amount of required space + in /home/ to around 4 Gigabyte. + + [:ref:`details<diskspace>`] + +.. _sources_sbs: + + * Retrieve the sources of the Linux version you intend to build; then change + into the directory holding them, as all further commands in this guide are + meant to be executed from there. + + *[Note: the following paragraphs describe how to retrieve the sources by + partially cloning the Linux stable git repository. This is called a shallow + clone. The reference section explains two alternatives:* :ref:`packaged + archives<sources_archive>` *and* :ref:`a full git clone<sources_full>` *; + prefer the latter, if downloading a lot of data does not bother you, as that + will avoid some* :ref:`peculiar characteristics of shallow clones the + reference section explains<sources_shallow>` *.]* + + First, execute the following command to retrieve a fresh mainline codebase:: + + git clone --no-checkout --depth 1 -b master \ + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux/ + cd ~/linux/ + + If you want to access recent mainline releases and pre-releases, deepen you + clone's history to the oldest mainline version you are interested in:: + + git fetch --shallow-exclude=v6.0 origin + + In case you want to access a stable/longterm release (say v6.1.5), simply add + the branch holding that series; afterwards fetch the history at least up to + the mainline version that started the series (v6.1):: + + git remote set-branches --add origin linux-6.1.y + git fetch --shallow-exclude=v6.0 origin + + Now checkout the code you are interested in. If you just performed the + initial clone, you will be able to check out a fresh mainline codebase, which + is ideal for checking whether developers already fixed an issue:: + + git checkout --detach origin/master + + If you deepened your clone, you instead of ``origin/master`` can specify the + version you deepened to (``v6.0`` above); later releases like ``v6.1`` and + pre-release like ``v6.2-rc1`` will work, too. Stable or longterm versions + like ``v6.1.5`` work just the same, if you added the appropriate + stable/longterm branch as described. + + [:ref:`details<sources>`] + +.. _patching_sbs: + + * In case you want to apply a kernel patch, do so now. Often a command like + this will do the trick:: + + patch -p1 < ../proposed-fix.patch + + If the ``-p1`` is actually needed, depends on how the patch was created; in + case it does not apply thus try without it. + + If you cloned the sources with git and anything goes sideways, run ``git + reset --hard`` to undo any changes to the sources. + + [:ref:`details<patching>`] + +.. _tagging_sbs: + + * If you patched your kernel or have one of the same version installed already, + better add a unique tag to the one you are about to build:: + + echo "-proposed_fix" > localversion + + Running ``uname -r`` under your kernel later will then print something like + '6.1-rc4-proposed_fix'. + + [:ref:`details<tagging>`] + + .. _configuration_sbs: + + * Create the build configuration for your kernel based on an existing + configuration. + + If you already prepared such a '.config' file yourself, copy it to + ~/linux/ and run ``make olddefconfig``. + + Use the same command, if your distribution or somebody else already tailored + your running kernel to your or your hardware's needs: the make target + 'olddefconfig' will then try to use that kernel's .config as base. + + Using this make target is fine for everybody else, too -- but you often can + save a lot of time by using this command instead:: + + yes "" | make localmodconfig + + This will try to pick your distribution's kernel as base, but then disable + modules for any features apparently superfluous for your setup. This will + reduce the compile time enormously, especially if you are running an + universal kernel from a commodity Linux distribution. + + There is a catch: the make target 'localmodconfig' will disable kernel + features you have not directly or indirectly through some program utilized + since you booted the system. You can reduce or nearly eliminate that risk by + using tricks outlined in the reference section; for quick testing purposes + that risk is often negligible, but it is an aspect you want to keep in mind + in case your kernel behaves oddly. + + [:ref:`details<configuration>`] + +.. _configmods_sbs: + + * Check if you might want to or have to adjust some kernel configuration + options: + + * Evaluate how you want to handle debug symbols. Enable them, if you later + might need to decode a stack trace found for example in a 'panic', 'Oops', + 'warning', or 'BUG'; on the other hand disable them, if you are short on + storage space or prefer a smaller kernel binary. See the reference section + for details on how to do either. If neither applies, it will likely be fine + to simply not bother with this. [:ref:`details<configmods_debugsymbols>`] + + * Are you running Debian? Then to avoid known problems by performing + additional adjustments explained in the reference section. + [:ref:`details<configmods_distros>`]. + + * If you want to influence the other aspects of the configuration, do so now + by using make targets like 'menuconfig' or 'xconfig'. + [:ref:`details<configmods_individual>`]. + +.. _build_sbs: + + * Build the image and the modules of your kernel:: + + make -j $(nproc --all) + + If you want your kernel packaged up as deb, rpm, or tar file, see the + reference section for alternatives. + + [:ref:`details<build>`] + +.. _install_sbs: + + * Now install your kernel:: + + command -v installkernel && sudo make modules_install install + + Often all left for you to do afterwards is a ``reboot``, as many commodity + Linux distributions will then create an initramfs (also known as initrd) and + an entry for your kernel in your bootloader's configuration; but on some + distributions you have to take care of these two steps manually for reasons + the reference section explains. + + On a few distributions like Arch Linux and its derivatives the above command + does nothing at all; in that case you have to manually install your kernel, + as outlined in the reference section. + + [:ref:`details<install>`] + +.. _another_sbs: + + * To later build another kernel you need similar steps, but sometimes slightly + different commands. + + First, switch back into the sources tree:: + + cd ~/linux/ + + In case you want to build a version from a stable/longterm series you have + not used yet (say 6.2.y), tell git to track it:: + + git remote set-branches --add origin linux-6.2.y + + Now fetch the latest upstream changes; you again need to specify the earliest + version you care about, as git otherwise might retrieve the entire commit + history:: + + git fetch --shallow-exclude=v6.1 origin + + If you modified the sources (for example by applying a patch), you now need + to discard those modifications; that's because git otherwise will not be able + to switch to the sources of another version due to potential conflicting + changes:: + + git reset --hard + + Now checkout the version you are interested in, as explained above:: + + git checkout --detach origin/master + + At this point you might want to patch the sources again or set/modify a build + tag, as explained earlier; afterwards adjust the build configuration to the + new codebase and build your next kernel:: + + # reminder: if you want to apply patches, do it at this point + # reminder: you might want to update your build tag at this point + make olddefconfig + make -j $(nproc --all) + + Install the kernel as outlined above:: + + command -v installkernel && sudo make modules_install install + + [:ref:`details<another>`] + +.. _uninstall_sbs: + + * Your kernel is easy to remove later, as its parts are only stored in two + places and clearly identifiable by the kernel's release name. Just ensure to + not delete the kernel you are running, as that might render your system + unbootable. + + Start by deleting the directory holding your kernel's modules, which is named + after its release name -- '6.0.1-foobar' in the following example:: + + sudo rm -rf /lib/modules/6.0.1-foobar + + Now try the following command, which on some distributions will delete all + other kernel files installed while also removing the kernel's entry from the + bootloader configuration:: + + command -v kernel-install && sudo kernel-install -v remove 6.0.1-foobar + + If that command does not output anything or fails, see the reference section; + do the same if any files named '*6.0.1-foobar*' remain in /boot/. + + [:ref:`details<uninstall>`] + +.. _submit_improvements: + +Did you run into trouble following any of the above steps that is not cleared up +by the reference section below? Or do you have ideas how to improve the text? +Then please take a moment of your time and let the maintainer of this document +know by email (Thorsten Leemhuis <linux@leemhuis.info>), ideally while CCing the +Linux docs mailing list (linux-doc@vger.kernel.org). Such feedback is vital to +improve this document further, which is in everybody's interest, as it will +enable more people to master the task described here. + +Reference section for the step-by-step guide +============================================ + +This section holds additional information for each of the steps in the above +guide. + +.. _backup: + +Prepare for emergencies +----------------------- + + *Create a fresh backup and put system repair and restore tools at hand* + [:ref:`... <backup_sbs>`] + +Remember, you are dealing with computers, which sometimes do unexpected things +-- especially if you fiddle with crucial parts like the kernel of an operating +system. That's what you are about to do in this process. Hence, better prepare +for something going sideways, even if that should not happen. + +[:ref:`back to step-by-step guide <backup_sbs>`] + +.. _secureboot: + +Dealing with techniques like Secure Boot +---------------------------------------- + + *On platforms with 'Secure Boot' or similar techniques, prepare everything to + ensure the system will permit your self-compiled kernel to boot later.* + [:ref:`... <secureboot_sbs>`] + +Many modern systems allow only certain operating systems to start; they thus by +default will reject booting self-compiled kernels. + +You ideally deal with this by making your platform trust your self-built kernels +with the help of a certificate and signing. How to do that is not described +here, as it requires various steps that would take the text too far away from +its purpose; 'Documentation/admin-guide/module-signing.rst' and various web +sides already explain this in more detail. + +Temporarily disabling solutions like Secure Boot is another way to make your own +Linux boot. On commodity x86 systems it is possible to do this in the BIOS Setup +utility; the steps to do so are not described here, as they greatly vary between +machines. + +On mainstream x86 Linux distributions there is a third and universal option: +disable all Secure Boot restrictions for your Linux environment. You can +initiate this process by running ``mokutil --disable-validation``; this will +tell you to create a one-time password, which is safe to write down. Now +restart; right after your BIOS performed all self-tests the bootloader Shim will +show a blue box with a message 'Press any key to perform MOK management'. Hit +some key before the countdown exposes. This will open a menu and choose 'Change +Secure Boot state' there. Shim's 'MokManager' will now ask you to enter three +randomly chosen characters from the one-time password specified earlier. Once +you provided them, confirm that you really want to disable the validation. +Afterwards, permit MokManager to reboot the machine. + +[:ref:`back to step-by-step guide <secureboot_sbs>`] + +.. _buildrequires: + +Install build requirements +-------------------------- + + *Install all software required to build a Linux kernel.* + [:ref:`...<buildrequires_sbs>`] + +The kernel is pretty stand-alone, but besides tools like the compiler you will +sometimes need a few libraries to build one. How to install everything needed +depends on your Linux distribution and the configuration of the kernel you are +about to build. + +Here are a few examples what you typically need on some mainstream +distributions: + + * Debian, Ubuntu, and derivatives:: + + sudo apt install bc binutils bison dwarves flex gcc git make openssl \ + pahole perl-base libssl-dev libelf-dev + + * Fedora and derivatives:: + + sudo dnf install binutils /usr/include/{libelf.h,openssl/pkcs7.h} \ + /usr/bin/{bc,bison,flex,gcc,git,openssl,make,perl,pahole} + + * openSUSE and derivatives:: + + sudo zypper install bc binutils bison dwarves flex gcc git make perl-base \ + openssl openssl-devel libelf-dev + +In case you wonder why these lists include openssl and its development headers: +they are needed for the Secure Boot support, which many distributions enable in +their kernel configuration for x86 machines. + +Sometimes you will need tools for compression formats like bzip2, gzip, lz4, +lzma, lzo, xz, or zstd as well. + +You might need additional libraries and their development headers in case you +perform tasks not covered in this guide. For example, zlib will be needed when +building kernel tools from the tools/ directory; adjusting the build +configuration with make targets like 'menuconfig' or 'xconfig' will require +development headers for ncurses or Qt5. + +[:ref:`back to step-by-step guide <buildrequires_sbs>`] + +.. _diskspace: + +Space requirements +------------------ + + *Ensure to have enough free space for building and installing Linux.* + [:ref:`... <diskspace_sbs>`] + +The numbers mentioned are rough estimates with a big extra charge to be on the +safe side, so often you will need less. + +If you have space constraints, remember to read the reference section when you +reach the :ref:`section about configuration adjustments' <configmods>`, as +ensuring debug symbols are disabled will reduce the consumed disk space by quite +a few gigabytes. + +[:ref:`back to step-by-step guide <diskspace_sbs>`] + + +.. _sources: + +Download the sources +-------------------- + + *Retrieve the sources of the Linux version you intend to build.* + [:ref:`...<sources_sbs>`] + +The step-by-step guide outlines how to retrieve Linux' sources using a shallow +git clone. There is :ref:`more to tell about this method<sources_shallow>` and +two alternate ways worth describing: :ref:`packaged archives<sources_archive>` +and :ref:`a full git clone<sources_full>`. And the aspects ':ref:`wouldn't it +be wiser to use a proper pre-release than the latest mainline code +<sources_snapshot>`' and ':ref:`how to get an even fresher mainline codebase +<sources_fresher>`' need elaboration, too. + +Note, to keep things simple the commands used in this guide store the build +artifacts in the source tree. If you prefer to separate them, simply add +something like ``O=~/linux-builddir/`` to all make calls; also adjust the path +in all commands that add files or modify any generated (like your '.config'). + +[:ref:`back to step-by-step guide <sources_sbs>`] + +.. _sources_shallow: + +Noteworthy characteristics of shallow clones +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The step-by-step guide uses a shallow clone, as it is the best solution for most +of this document's target audience. There are a few aspects of this approach +worth mentioning: + + * This document in most places uses ``git fetch`` with ``--shallow-exclude=`` + to specify the earliest version you care about (or to be precise: its git + tag). You alternatively can use the parameter ``--shallow-since=`` to specify + an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to + define the depth of the history you want to download. As a second + alternative, you can also specify a certain depth explicitly with a parameter + like ``--depth=1``, unless you add branches for stable/longterm kernels. + + * When running ``git fetch``, remember to always specify the oldest version, + the time you care about, or an explicit depth as shown in the step-by-step + guide. Otherwise you will risk downloading nearly the entire git history, + which will consume quite a bit of time and bandwidth while also stressing the + servers. + + Note, you do not have to use the same version or date all the time. But when + you change it over time, git will deepen or flatten the history to the + specified point. That allows you to retrieve versions you initially thought + you did not need -- or it will discard the sources of older versions, for + example in case you want to free up some disk space. The latter will happen + automatically when using ``--shallow-since=`` or + ``--depth=``. + + * Be warned, when deepening your clone you might encounter an error like + 'fatal: error in object: unshallow cafecaca0c0dacafecaca0c0dacafecaca0c0da'. + In that case run ``git repack -d`` and try again`` + + * In case you want to revert changes from a certain version (say Linux 6.3) or + perform a bisection (v6.2..v6.3), better tell ``git fetch`` to retrieve + objects up to three versions earlier (e.g. 6.0): ``git describe`` will then + be able to describe most commits just like it would in a full git clone. + +[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`] + +.. _sources_archive: + +Downloading the sources using a packages archive +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +People new to compiling Linux often assume downloading an archive via the +front-page of https://kernel.org is the best approach to retrieve Linux' +sources. It actually can be, if you are certain to build just one particular +kernel version without changing any code. Thing is: you might be sure this will +be the case, but in practice it often will turn out to be a wrong assumption. + +That's because when reporting or debugging an issue developers will often ask to +give another version a try. They also might suggest temporarily undoing a commit +with ``git revert`` or might provide various patches to try. Sometimes reporters +will also be asked to use ``git bisect`` to find the change causing a problem. +These things rely on git or are a lot easier and quicker to handle with it. + +A shallow clone also does not add any significant overhead. For example, when +you use ``git clone --depth=1`` to create a shallow clone of the latest mainline +codebase git will only retrieve a little more data than downloading the latest +mainline pre-release (aka 'rc') via the front-page of kernel.org would. + +A shallow clone therefore is often the better choice. If you nevertheless want +to use a packaged source archive, download one via kernel.org; afterwards +extract its content to some directory and change to the subdirectory created +during extraction. The rest of the step-by-step guide will work just fine, apart +from things that rely on git -- but this mainly concerns the section on +successive builds of other versions. + +[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`] + +.. _sources_full: + +Downloading the sources using a full git clone +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If downloading and storing a lot of data (~4,4 Gigabyte as of early 2023) is +nothing that bothers you, instead of a shallow clone perform a full git clone +instead. You then will avoid the specialties mentioned above and will have all +versions and individual commits at hand at any time:: + + curl -L \ + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/clone.bundle \ + -o linux-stable.git.bundle + git clone clone.bundle ~/linux/ + rm linux-stable.git.bundle + cd ~/linux/ + git remote set-url origin + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git + git fetch origin + git checkout --detach origin/master + +[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`] + +.. _sources_snapshot: + +Proper pre-releases (RCs) vs. latest mainline +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When cloning the sources using git and checking out origin/master, you often +will retrieve a codebase that is somewhere between the latest and the next +release or pre-release. This almost always is the code you want when giving +mainline a shot: pre-releases like v6.1-rc5 are in no way special, as they do +not get any significant extra testing before being published. + +There is one exception: you might want to stick to the latest mainline release +(say v6.1) before its successor's first pre-release (v6.2-rc1) is out. That is +because compiler errors and other problems are more likely to occur during this +time, as mainline then is in its 'merge window': a usually two week long phase, +in which the bulk of the changes for the next release is merged. + +[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`] + +.. _sources_fresher: + +Avoiding the mainline lag +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The explanations for both the shallow clone and the full clone both retrieve the +code from the Linux stable git repository. That makes things simpler for this +document's audience, as it allows easy access to both mainline and +stable/longterm releases. This approach has just one downside: + +Changes merged into the mainline repository are only synced to the master branch +of the Linux stable repository every few hours. This lag most of the time is +not something to worry about; but in case you really need the latest code, just +add the mainline repo as additional remote and checkout the code from there:: + + git remote add mainline \ + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + git fetch mainline + git checkout --detach mainline/master + +When doing this with a shallow clone, remember to call ``git fetch`` with one +of the parameters described earlier to limit the depth. + +[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`] + +.. _patching: + +Patch the sources (optional) +---------------------------- + + *In case you want to apply a kernel patch, do so now.* + [:ref:`...<patching_sbs>`] + +This is the point where you might want to patch your kernel -- for example when +a developer proposed a fix and asked you to check if it helps. The step-by-step +guide already explains everything crucial here. + +[:ref:`back to step-by-step guide <patching_sbs>`] + +.. _tagging: + +Tagging this kernel build (optional, often wise) +------------------------------------------------ + + *If you patched your kernel or already have that kernel version installed, + better tag your kernel by extending its release name:* + [:ref:`...<tagging_sbs>`] + +Tagging your kernel will help avoid confusion later, especially when you patched +your kernel. Adding an individual tag will also ensure the kernel's image and +its modules are installed in parallel to any existing kernels. + +There are various ways to add such a tag. The step-by-step guide realizes one by +creating a 'localversion' file in your build directory from which the kernel +build scripts will automatically pick up the tag. You can later change that file +to use a different tag in subsequent builds or simply remove that file to dump +the tag. + +[:ref:`back to step-by-step guide <tagging_sbs>`] + +.. _configuration: + +Define the build configuration for your kernel +---------------------------------------------- + + *Create the build configuration for your kernel based on an existing + configuration.* [:ref:`... <configuration_sbs>`] + +There are various aspects for this steps that require a more careful +explanation: + +Pitfalls when using another configuration file as base +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Make targets like localmodconfig and olddefconfig share a few common snares you +want to be aware of: + + * These targets will reuse a kernel build configuration in your build directory + (e.g. '~/linux/.config'), if one exists. In case you want to start from + scratch you thus need to delete it. + + * The make targets try to find the configuration for your running kernel + automatically, but might choose poorly. A line like '# using defaults found + in /boot/config-6.0.7-250.fc36.x86_64' or 'using config: + '/boot/config-6.0.7-250.fc36.x86_64' tells you which file they picked. If + that is not the intended one, simply store it as '~/linux/.config' + before using these make targets. + + * Unexpected things might happen if you try to use a config file prepared for + one kernel (say v6.0) on an older generation (say v5.15). In that case you + might want to use a configuration as base which your distribution utilized + when they used that or an slightly older kernel version. + +Influencing the configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The make target olddefconfig and the ``yes "" |`` used when utilizing +localmodconfig will set any undefined build options to their default value. This +among others will disable many kernel features that were introduced after your +base kernel was released. + +If you want to set these configurations options manually, use ``oldconfig`` +instead of ``olddefconfig`` or omit the ``yes "" |`` when utilizing +localmodconfig. Then for each undefined configuration option you will be asked +how to proceed. In case you are unsure what to answer, simply hit 'enter' to +apply the default value. + +Big pitfall when using localmodconfig +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As explained briefly in the step-by-step guide already: with localmodconfig it +can easily happen that your self-built kernel will lack modules for tasks you +did not perform before utilizing this make target. That's because those tasks +require kernel modules that are normally autoloaded when you perform that task +for the first time; if you didn't perform that task at least once before using +localmodonfig, the latter will thus assume these modules are superfluous and +disable them. + +You can try to avoid this by performing typical tasks that often will autoload +additional kernel modules: start a VM, establish VPN connections, loop-mount a +CD/DVD ISO, mount network shares (CIFS, NFS, ...), and connect all external +devices (2FA keys, headsets, webcams, ...) as well as storage devices with file +systems you otherwise do not utilize (btrfs, ext4, FAT, NTFS, XFS, ...). But it +is hard to think of everything that might be needed -- even kernel developers +often forget one thing or another at this point. + +Do not let that risk bother you, especially when compiling a kernel only for +testing purposes: everything typically crucial will be there. And if you forget +something important you can turn on a missing feature later and quickly run the +commands to compile and install a better kernel. + +But if you plan to build and use self-built kernels regularly, you might want to +reduce the risk by recording which modules your system loads over the course of +a few weeks. You can automate this with `modprobed-db +<https://github.com/graysky2/modprobed-db>`_. Afterwards use ``LSMOD=<path>`` to +point localmodconfig to the list of modules modprobed-db noticed being used:: + + yes "" | make LSMOD="${HOME}"/.config/modprobed.db localmodconfig + +Remote building with localmodconfig +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to use localmodconfig to build a kernel for another machine, run +``lsmod > lsmod_foo-machine`` on it and transfer that file to your build host. +Now point the build scripts to the file like this: ``yes "" | make +LSMOD=~/lsmod_foo-machine localmodconfig``. Note, in this case +you likely want to copy a base kernel configuration from the other machine over +as well and place it as .config in your build directory. + +[:ref:`back to step-by-step guide <configuration_sbs>`] + +.. _configmods: + +Adjust build configuration +-------------------------- + + *Check if you might want to or have to adjust some kernel configuration + options:* + +Depending on your needs you at this point might want or have to adjust some +kernel configuration options. + +.. _configmods_debugsymbols: + +Debug symbols +~~~~~~~~~~~~~ + + *Evaluate how you want to handle debug symbols.* + [:ref:`...<configmods_sbs>`] + +Most users do not need to care about this, it's often fine to leave everything +as it is; but you should take a closer look at this, if you might need to decode +a stack trace or want to reduce space consumption. + +Having debug symbols available can be important when your kernel throws a +'panic', 'Oops', 'warning', or 'BUG' later when running, as then you will be +able to find the exact place where the problem occurred in the code. But +collecting and embedding the needed debug information takes time and consumes +quite a bit of space: in late 2022 the build artifacts for a typical x86 kernel +configured with localmodconfig consumed around 5 Gigabyte of space with debug +symbols, but less than 1 when they were disabled. The resulting kernel image and +the modules are bigger as well, which increases load times. + +Hence, if you want a small kernel and are unlikely to decode a stack trace +later, you might want to disable debug symbols to avoid above downsides:: + + ./scripts/config --file .config -d DEBUG_INFO \ + -d DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -d DEBUG_INFO_DWARF4 \ + -d DEBUG_INFO_DWARF5 -e CONFIG_DEBUG_INFO_NONE + make olddefconfig + +You on the other hand definitely want to enable them, if there is a decent +chance that you need to decode a stack trace later (as explained by 'Decode +failure messages' in Documentation/admin-guide/tainted-kernels.rst in more +detail):: + + ./scripts/config --file .config -d DEBUG_INFO_NONE -e DEBUG_KERNEL + -e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS -e KALLSYMS_ALL + make olddefconfig + +Note, many mainstream distributions enable debug symbols in their kernel +configurations -- make targets like localmodconfig and olddefconfig thus will +often pick that setting up. + +[:ref:`back to step-by-step guide <configmods_sbs>`] + +.. _configmods_distros: + +Distro specific adjustments +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + *Are you running* [:ref:`... <configmods_sbs>`] + +The following sections help you to avoid build problems that are known to occur +when following this guide on a few commodity distributions. + +**Debian:** + + * Remove a stale reference to a certificate file that would cause your build to + fail:: + + ./scripts/config --file .config --set-str SYSTEM_TRUSTED_KEYS '' + + Alternatively, download the needed certificate and make that configuration + option point to it, as `the Debian handbook explains in more detail + <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_ + -- or generate your own, as explained in + Documentation/admin-guide/module-signing.rst. + +[:ref:`back to step-by-step guide <configmods_sbs>`] + +.. _configmods_individual: + +Individual adjustments +~~~~~~~~~~~~~~~~~~~~~~ + + *If you want to influence the other aspects of the configuration, do so + now* [:ref:`... <configmods_sbs>`] + +You at this point can use a command like ``make menuconfig`` to enable or +disable certain features using a text-based user interface; to use a graphical +configuration utilize, use the make target ``xconfig`` or ``gconfig`` instead. +All of them require development libraries from toolkits they are based on +(ncurses, Qt5, Gtk2); an error message will tell you if something required is +missing. + +[:ref:`back to step-by-step guide <configmods_sbs>`] + +.. _build: + +Build your kernel +----------------- + + *Build the image and the modules of your kernel* [:ref:`... <build_sbs>`] + +A lot can go wrong at this stage, but the instructions below will help you help +yourself. Another subsection explains how to directly package your kernel up as +deb, rpm or tar file. + +Dealing with build errors +~~~~~~~~~~~~~~~~~~~~~~~~~ + +When a build error occurs, it might be caused by some aspect of your machine's +setup that often can be fixed quickly; other times though the problem lies in +the code and can only be fixed by a developer. A close examination of the +failure messages coupled with some research on the internet will often tell you +which of the two it is. To perform such a investigation, restart the build +process like this:: + + make V=1 + +The ``V=1`` activates verbose output, which might be needed to see the actual +error. To make it easier to spot, this command also omits the ``-j $(nproc +--all)`` used earlier to utilize every CPU core in the system for the job -- but +this parallelism also results in some clutter when failures occur. + +After a few seconds the build process should run into the error again. Now try +to find the most crucial line describing the problem. Then search the internet +for the most important and non-generic section of that line (say 4 to 8 words); +avoid or remove anything that looks remotely system-specific, like your username +or local path names like ``/home/username/linux/``. First try your regular +internet search engine with that string, afterwards search Linux kernel mailing +lists via `lore.kernel.org/all/ <https://lore.kernel.org/all/>`_. + +This most of the time will find something that will explain what is wrong; quite +often one of the hits will provide a solution for your problem, too. If you +do not find anything that matches your problem, try again from a different angle +by modifying your search terms or using another line from the error messages. + +In the end, most trouble you are to run into has likely been encountered and +reported by others already. That includes issues where the cause is not your +system, but lies the code. If you run into one of those, you might thus find a +solution (e.g. a patch) or workaround for your problem, too. + +Package your kernel up +~~~~~~~~~~~~~~~~~~~~~~ + +The step-by-step guide uses the default make targets (e.g. 'bzImage' and +'modules' on x86) to build the image and the modules of your kernel, which later +steps of the guide then install. You instead can also directly build everything +and directly package it up by using one of the following targets: + + * ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package + + * ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package + + * ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball + +This is just a selection of available make targets for this purpose, see +``make help`` for others. You can also use these targets after running +``make -j $(nproc --all)``, as they will pick up everything already built. + +If you employ the targets to generate deb or rpm packages, ignore the +step-by-step guide's instructions on installing and removing your kernel; +instead install and remove the packages using the package utility for the format +(e.g. dpkg and rpm) or a package management utility build on top of them (apt, +aptitude, dnf/yum, zypper, ...). Be aware that the packages generated using +these two make targets are designed to work on various distributions utilizing +those formats, they thus will sometimes behave differently than your +distribution's kernel packages. + +[:ref:`back to step-by-step guide <build_sbs>`] + +.. _install: + +Install your kernel +------------------- + + *Now install your kernel* [:ref:`... <install_sbs>`] + +What you need to do after executing the command in the step-by-step guide +depends on the existence and the implementation of an ``installkernel`` +executable. Many commodity Linux distributions ship such a kernel installer in +``/sbin/`` that does everything needed, hence there is nothing left for you +except rebooting. But some distributions contain an installkernel that does +only part of the job -- and a few lack it completely and leave all the work to +you. + +If ``installkernel`` is found, the kernel's build system will delegate the +actual installation of your kernel's image and related files to this executable. +On almost all Linux distributions it will store the image as '/boot/vmlinuz- +<your kernel's release name>' and put a 'System.map-<your kernel's release +name>' alongside it. Your kernel will thus be installed in parallel to any +existing ones, unless you already have one with exactly the same release name. + +Installkernel on many distributions will afterwards generate an 'initramfs' +(often also called 'initrd'), which commodity distributions rely on for booting; +hence be sure to keep the order of the two make targets used in the step-by-step +guide, as things will go sideways if you install your kernel's image before its +modules. Often installkernel will then add your kernel to the bootloader +configuration, too. You have to take care of one or both of these tasks +yourself, if your distributions installkernel doesn't handle them. + +A few distributions like Arch Linux and its derivatives totally lack an +installkernel executable. On those just install the modules using the kernel's +build system and then install the image and the System.map file manually:: + + sudo make modules_install + sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease) + sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease) + +If your distribution boots with the help of an initramfs, now generate one for +your kernel using the tools your distribution provides for this process. +Afterwards add your kernel to your bootloader configuration and reboot. + +[:ref:`back to step-by-step guide <install_sbs>`] + +.. _another: + +Another round later +------------------- + + *To later build another kernel you need similar, but sometimes slightly + different commands* [:ref:`... <another_sbs>`] + +The process to build later kernels is similar, but at some points slightly +different. You for example do not want to use 'localmodconfig' for succeeding +kernel builds, as you already created a trimmed down configuration you want to +use from now on. Hence instead just use ``oldconfig`` or ``olddefconfig`` to +adjust your build configurations to the needs of the kernel version you are +about to build. + +If you created a shallow-clone with git, remember what the :ref:`section that +explained the setup described in more detail <sources>`: you need to use a +slightly different ``git fetch`` command and when switching to another series +need to add an additional remote branch. + +[:ref:`back to step-by-step guide <another_sbs>`] + +.. _uninstall: + +Uninstall the kernel later +-------------------------- + + *All parts of your installed kernel are identifiable by its release name and + thus easy to remove later.* [:ref:`... <uninstall_sbs>`] + +Do not worry installing your kernel manually and thus bypassing your +distribution's packaging system will totally mess up your machine: all parts of +your kernel are easy to remove later, as files are stored in two places only and +normally identifiable by the kernel's release name. + +One of the two places is a directory in /lib/modules/, which holds the modules +for each installed kernel. This directory is named after the kernel's release +name; hence, to remove all modules for one of your kernels, simply remove its +modules directory in /lib/modules/. + +The other place is /boot/, where typically one to five files will be placed +during installation of a kernel. All of them usually contain the release name in +their file name, but how many files and their name depends somewhat on your +distribution's installkernel executable (:ref:`see above <install>`) and its +initramfs generator. On some distributions the ``kernel-install`` command +mentioned in the step-by-step guide will remove all of these files for you -- +and the entry for your kernel in the bootloader configuration at the same time, +too. On others you have to take care of these steps yourself. The following +command should interactively remove the two main files of a kernel with the +release name '6.0.1-foobar':: + + rm -i /boot/{System.map,vmlinuz}-6.0.1-foobar + +Now remove the belonging initramfs, which often will be called something like +``/boot/initramfs-6.0.1-foobar.img`` or ``/boot/initrd.img-6.0.1-foobar``. +Afterwards check for other files in /boot/ that have '6.0.1-foobar' in their +name and delete them as well. Now remove the kernel from your bootloader's +configuration. + +Note, be very careful with wildcards like '*' when deleting files or directories +for kernels manually: you might accidentally remove files of a 6.0.11 kernel +when all you want is to remove 6.0 or 6.0.1. + +[:ref:`back to step-by-step guide <uninstall_sbs>`] + +.. _faq: + +FAQ +=== + +Why does this 'how-to' not work on my system? +--------------------------------------------- + +As initially stated, this guide is 'designed to cover everything typically +needed [to build a kernel] on mainstream Linux distributions running on +commodity PC or server hardware'. The outlined approach despite this should work +on many other setups as well. But trying to cover every possible use-case in one +guide would defeat its purpose, as without such a focus you would need dozens or +hundreds of constructs along the lines of 'in case you are having <insert +machine or distro>, you at this point have to do <this and that> +<instead|additionally>'. Each of which would make the text longer, more +complicated, and harder to follow. + +That being said: this of course is a balancing act. Hence, if you think an +additional use-case is worth describing, suggest it to the maintainers of this +document, as :ref:`described above <submit_improvements>`. + + +.. + end-of-content +.. + This document is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If + you spot a typo or small mistake, feel free to let him know directly and + he'll fix it. You are free to do the same in a mostly informal way if you + want to contribute changes to the text -- but for copyright reasons please CC + linux-doc@vger.kernel.org and 'sign-off' your contribution as + Documentation/process/submitting-patches.rst explains in the section 'Sign + your work - the Developer's Certificate of Origin'. +.. + This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top + of the file. If you want to distribute this text under CC-BY-4.0 only, + please use 'The Linux kernel development community' for author attribution + and link this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/quickly-build-trimmed-linux.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. + diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst index 7b481b2a368e..8e03751d126d 100644 --- a/Documentation/admin-guide/ras.rst +++ b/Documentation/admin-guide/ras.rst @@ -199,7 +199,7 @@ Architecture (MCA)\ [#f3]_. mode). .. [#f3] For more details about the Machine Check Architecture (MCA), - please read Documentation/x86/x86_64/machinecheck.rst at the Kernel tree. + please read Documentation/arch/x86/x86_64/machinecheck.rst at the Kernel tree. EDAC - Error Detection And Correction ************************************* diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst index ec62151fe672..2fd5a030235a 100644 --- a/Documentation/admin-guide/reporting-issues.rst +++ b/Documentation/admin-guide/reporting-issues.rst @@ -395,7 +395,7 @@ might want to be aware of; it for example explains how to add your issue to the list of tracked regressions, to ensure it won't fall through the cracks. What qualifies as security issue is left to your judgment. Consider reading -Documentation/admin-guide/security-bugs.rst before proceeding, as it +Documentation/process/security-bugs.rst before proceeding, as it provides additional details how to best handle security issues. An issue is a 'really severe problem' when something totally unacceptably bad @@ -1269,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward the report's text to these addresses; but on top of it put a small note where you mention that you filed it with a link to the ticket. -See Documentation/admin-guide/security-bugs.rst for more information. +See Documentation/process/security-bugs.rst for more information. Duties after the report went out diff --git a/Documentation/admin-guide/serial-console.rst b/Documentation/admin-guide/serial-console.rst index 58b32832e50a..8c8b94e54e26 100644 --- a/Documentation/admin-guide/serial-console.rst +++ b/Documentation/admin-guide/serial-console.rst @@ -33,8 +33,11 @@ The format of this option is:: 9600n8. The maximum baudrate is 115200. You can specify multiple console= options on the kernel command line. -Output will appear on all of them. The last device will be used when -you open ``/dev/console``. So, for example:: + +The behavior is well defined when each device type is mentioned only once. +In this case, the output will appear on all requested consoles. And +the last device will be used when you open ``/dev/console``. +So, for example:: console=ttyS1,9600 console=tty0 @@ -42,7 +45,34 @@ defines that opening ``/dev/console`` will get you the current foreground virtual console, and kernel messages will appear on both the VGA console and the 2nd serial port (ttyS1 or COM2) at 9600 baud. -Note that you can only define one console per device type (serial, video). +The behavior is more complicated when the same device type is defined more +times. In this case, there are the following two rules: + +1. The output will appear only on the first device of each defined type. + +2. ``/dev/console`` will be associated with the first registered device. + Where the registration order depends on how kernel initializes various + subsystems. + + This rule is used also when the last console= parameter is not used + for other reasons. For example, because of a typo or because + the hardware is not available. + +The result might be surprising. For example, the following two command +lines have the same result: + + console=ttyS1,9600 console=tty0 console=tty1 + console=tty0 console=ttyS1,9600 console=tty1 + +The kernel messages are printed only on ``tty0`` and ``ttyS1``. And +``/dev/console`` gets associated with ``tty0``. It is because kernel +tries to register graphical consoles before serial ones. It does it +because of the default behavior when no console device is specified, +see below. + +Note that the last ``console=tty1`` parameter still makes a difference. +The kernel command line is used also by systemd. It would use the last +defined ``tty1`` as the login console. 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 diff --git a/Documentation/admin-guide/syscall-user-dispatch.rst b/Documentation/admin-guide/syscall-user-dispatch.rst index 60314953c728..e3cfffef5a63 100644 --- a/Documentation/admin-guide/syscall-user-dispatch.rst +++ b/Documentation/admin-guide/syscall-user-dispatch.rst @@ -73,6 +73,10 @@ thread-wide, without the need to invoke the kernel directly. selector can be set to SYSCALL_DISPATCH_FILTER_ALLOW or SYSCALL_DISPATCH_FILTER_BLOCK. Any other value should terminate the program with a SIGSYS. +Additionally, a tasks syscall user dispatch configuration can be peeked +and poked via the PTRACE_(GET|SET)_SYSCALL_USER_DISPATCH_CONFIG ptrace +requests. This is useful for checkpoint/restart software. + Security Notes -------------- diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 4b7bfea28cd7..d85d90f5d000 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -95,7 +95,7 @@ is 0x15 and the full version number is 0x234, this file will contain the value 340 = 0x154. See the ``type_of_loader`` and ``ext_loader_type`` fields in -Documentation/x86/boot.rst for additional information. +Documentation/arch/x86/boot.rst for additional information. bootloader_version (x86 only) @@ -105,7 +105,7 @@ The complete bootloader version number. In the example above, this file will contain the value 564 = 0x234. See the ``type_of_loader`` and ``ext_loader_ver`` fields in -Documentation/x86/boot.rst for additional information. +Documentation/arch/x86/boot.rst for additional information. bpf_stats_enabled diff --git a/Documentation/admin-guide/unicode.rst b/Documentation/admin-guide/unicode.rst index 290fe83ebe82..cba7e5017d36 100644 --- a/Documentation/admin-guide/unicode.rst +++ b/Documentation/admin-guide/unicode.rst @@ -3,11 +3,10 @@ Unicode support Last update: 2005-01-17, version 1.4 -This file is maintained by H. Peter Anvin <unicode@lanana.org> as part -of the Linux Assigned Names And Numbers Authority (LANANA) project. -The current version can be found at: - - http://www.lanana.org/docs/unicode/admin-guide/unicode.rst +Note: The original version of this document, which was maintained at +lanana.org as part of the Linux Assigned Names And Numbers Authority +(LANANA) project, is no longer existent. So, this version in the +mainline Linux kernel is now the maintained main document. Introduction ------------ diff --git a/Documentation/admin-guide/xfs.rst b/Documentation/admin-guide/xfs.rst index e2561416391c..3a9c041d7f6c 100644 --- a/Documentation/admin-guide/xfs.rst +++ b/Documentation/admin-guide/xfs.rst @@ -236,13 +236,14 @@ the dates listed above. Deprecated Mount Options ======================== -=========================== ================ +============================ ================ Name Removal Schedule -=========================== ================ +============================ ================ Mounting with V4 filesystem September 2030 +Mounting ascii-ci filesystem September 2030 ikeep/noikeep September 2025 attr2/noattr2 September 2025 -=========================== ================ +============================ ================ Removed Mount Options diff --git a/Documentation/arc/arc.rst b/Documentation/arch/arc/arc.rst index 6c4d978f3f4e..6c4d978f3f4e 100644 --- a/Documentation/arc/arc.rst +++ b/Documentation/arch/arc/arc.rst diff --git a/Documentation/arc/features.rst b/Documentation/arch/arc/features.rst index b793583d688a..b793583d688a 100644 --- a/Documentation/arc/features.rst +++ b/Documentation/arch/arc/features.rst diff --git a/Documentation/arc/index.rst b/Documentation/arch/arc/index.rst index 7b098d4a5e3e..7b098d4a5e3e 100644 --- a/Documentation/arc/index.rst +++ b/Documentation/arch/arc/index.rst diff --git a/Documentation/ia64/aliasing.rst b/Documentation/arch/ia64/aliasing.rst index 36a1e1d4842b..36a1e1d4842b 100644 --- a/Documentation/ia64/aliasing.rst +++ b/Documentation/arch/ia64/aliasing.rst diff --git a/Documentation/ia64/efirtc.rst b/Documentation/arch/ia64/efirtc.rst index fd8328408301..fd8328408301 100644 --- a/Documentation/ia64/efirtc.rst +++ b/Documentation/arch/ia64/efirtc.rst diff --git a/Documentation/ia64/err_inject.rst b/Documentation/arch/ia64/err_inject.rst index 900f71e93a29..900f71e93a29 100644 --- a/Documentation/ia64/err_inject.rst +++ b/Documentation/arch/ia64/err_inject.rst diff --git a/Documentation/ia64/features.rst b/Documentation/arch/ia64/features.rst index d7226fdcf5f8..d7226fdcf5f8 100644 --- a/Documentation/ia64/features.rst +++ b/Documentation/arch/ia64/features.rst diff --git a/Documentation/ia64/fsys.rst b/Documentation/arch/ia64/fsys.rst index a702d2cc94b6..a702d2cc94b6 100644 --- a/Documentation/ia64/fsys.rst +++ b/Documentation/arch/ia64/fsys.rst diff --git a/Documentation/ia64/ia64.rst b/Documentation/arch/ia64/ia64.rst index b725019a9492..b725019a9492 100644 --- a/Documentation/ia64/ia64.rst +++ b/Documentation/arch/ia64/ia64.rst diff --git a/Documentation/ia64/index.rst b/Documentation/arch/ia64/index.rst index 761f2154dfa2..761f2154dfa2 100644 --- a/Documentation/ia64/index.rst +++ b/Documentation/arch/ia64/index.rst diff --git a/Documentation/ia64/irq-redir.rst b/Documentation/arch/ia64/irq-redir.rst index 6bbbbe4f73ef..6bbbbe4f73ef 100644 --- a/Documentation/ia64/irq-redir.rst +++ b/Documentation/arch/ia64/irq-redir.rst diff --git a/Documentation/ia64/mca.rst b/Documentation/arch/ia64/mca.rst index 08270bba44a4..08270bba44a4 100644 --- a/Documentation/ia64/mca.rst +++ b/Documentation/arch/ia64/mca.rst diff --git a/Documentation/ia64/serial.rst b/Documentation/arch/ia64/serial.rst index 1de70c305a79..1de70c305a79 100644 --- a/Documentation/ia64/serial.rst +++ b/Documentation/arch/ia64/serial.rst diff --git a/Documentation/arch.rst b/Documentation/arch/index.rst index 41a66a8b38e4..80ee31016584 100644 --- a/Documentation/arch.rst +++ b/Documentation/arch/index.rst @@ -10,18 +10,18 @@ implementation. :maxdepth: 2 arc/index - arm/index - arm64/index + ../arm/index + ../arm64/index ia64/index - loongarch/index + ../loongarch/index m68k/index - mips/index + ../mips/index nios2/index openrisc/index parisc/index - powerpc/index - riscv/index - s390/index + ../powerpc/index + ../riscv/index + ../s390/index sh/index sparc/index x86/index diff --git a/Documentation/m68k/buddha-driver.rst b/Documentation/arch/m68k/buddha-driver.rst index 20e401413991..20e401413991 100644 --- a/Documentation/m68k/buddha-driver.rst +++ b/Documentation/arch/m68k/buddha-driver.rst diff --git a/Documentation/m68k/features.rst b/Documentation/arch/m68k/features.rst index 5107a2119472..5107a2119472 100644 --- a/Documentation/m68k/features.rst +++ b/Documentation/arch/m68k/features.rst diff --git a/Documentation/m68k/index.rst b/Documentation/arch/m68k/index.rst index 0f890dbb5fe2..0f890dbb5fe2 100644 --- a/Documentation/m68k/index.rst +++ b/Documentation/arch/m68k/index.rst diff --git a/Documentation/m68k/kernel-options.rst b/Documentation/arch/m68k/kernel-options.rst index 2008a20b4329..2008a20b4329 100644 --- a/Documentation/m68k/kernel-options.rst +++ b/Documentation/arch/m68k/kernel-options.rst diff --git a/Documentation/nios2/features.rst b/Documentation/arch/nios2/features.rst index 8449e63f69b2..8449e63f69b2 100644 --- a/Documentation/nios2/features.rst +++ b/Documentation/arch/nios2/features.rst diff --git a/Documentation/nios2/index.rst b/Documentation/arch/nios2/index.rst index 4468fe1a1037..4468fe1a1037 100644 --- a/Documentation/nios2/index.rst +++ b/Documentation/arch/nios2/index.rst diff --git a/Documentation/nios2/nios2.rst b/Documentation/arch/nios2/nios2.rst index 43da3f7cee76..43da3f7cee76 100644 --- a/Documentation/nios2/nios2.rst +++ b/Documentation/arch/nios2/nios2.rst diff --git a/Documentation/openrisc/features.rst b/Documentation/arch/openrisc/features.rst index 3f7c40d219f2..3f7c40d219f2 100644 --- a/Documentation/openrisc/features.rst +++ b/Documentation/arch/openrisc/features.rst diff --git a/Documentation/openrisc/index.rst b/Documentation/arch/openrisc/index.rst index 6879f998b87a..6879f998b87a 100644 --- a/Documentation/openrisc/index.rst +++ b/Documentation/arch/openrisc/index.rst diff --git a/Documentation/openrisc/openrisc_port.rst b/Documentation/arch/openrisc/openrisc_port.rst index 657ac4af7be6..657ac4af7be6 100644 --- a/Documentation/openrisc/openrisc_port.rst +++ b/Documentation/arch/openrisc/openrisc_port.rst diff --git a/Documentation/openrisc/todo.rst b/Documentation/arch/openrisc/todo.rst index 420b18b87eda..420b18b87eda 100644 --- a/Documentation/openrisc/todo.rst +++ b/Documentation/arch/openrisc/todo.rst diff --git a/Documentation/parisc/debugging.rst b/Documentation/arch/parisc/debugging.rst index de1b60402c5b..de1b60402c5b 100644 --- a/Documentation/parisc/debugging.rst +++ b/Documentation/arch/parisc/debugging.rst diff --git a/Documentation/parisc/features.rst b/Documentation/arch/parisc/features.rst index 501d7c450037..501d7c450037 100644 --- a/Documentation/parisc/features.rst +++ b/Documentation/arch/parisc/features.rst diff --git a/Documentation/parisc/index.rst b/Documentation/arch/parisc/index.rst index 240685751825..240685751825 100644 --- a/Documentation/parisc/index.rst +++ b/Documentation/arch/parisc/index.rst diff --git a/Documentation/parisc/registers.rst b/Documentation/arch/parisc/registers.rst index 59c8ecf3e856..59c8ecf3e856 100644 --- a/Documentation/parisc/registers.rst +++ b/Documentation/arch/parisc/registers.rst diff --git a/Documentation/sh/booting.rst b/Documentation/arch/sh/booting.rst index d851c49a01bf..d851c49a01bf 100644 --- a/Documentation/sh/booting.rst +++ b/Documentation/arch/sh/booting.rst diff --git a/Documentation/sh/features.rst b/Documentation/arch/sh/features.rst index f722af3b6c99..f722af3b6c99 100644 --- a/Documentation/sh/features.rst +++ b/Documentation/arch/sh/features.rst diff --git a/Documentation/sh/index.rst b/Documentation/arch/sh/index.rst index c64776738cf6..c64776738cf6 100644 --- a/Documentation/sh/index.rst +++ b/Documentation/arch/sh/index.rst diff --git a/Documentation/sh/new-machine.rst b/Documentation/arch/sh/new-machine.rst index e501c52b3b30..e501c52b3b30 100644 --- a/Documentation/sh/new-machine.rst +++ b/Documentation/arch/sh/new-machine.rst diff --git a/Documentation/sh/register-banks.rst b/Documentation/arch/sh/register-banks.rst index 2bef5c8fcbbc..2bef5c8fcbbc 100644 --- a/Documentation/sh/register-banks.rst +++ b/Documentation/arch/sh/register-banks.rst diff --git a/Documentation/sparc/adi.rst b/Documentation/arch/sparc/adi.rst index dbcd8b6e7bc3..dbcd8b6e7bc3 100644 --- a/Documentation/sparc/adi.rst +++ b/Documentation/arch/sparc/adi.rst diff --git a/Documentation/sparc/console.rst b/Documentation/arch/sparc/console.rst index 73132db83ece..73132db83ece 100644 --- a/Documentation/sparc/console.rst +++ b/Documentation/arch/sparc/console.rst diff --git a/Documentation/sparc/features.rst b/Documentation/arch/sparc/features.rst index c0c92468b0fe..c0c92468b0fe 100644 --- a/Documentation/sparc/features.rst +++ b/Documentation/arch/sparc/features.rst diff --git a/Documentation/sparc/index.rst b/Documentation/arch/sparc/index.rst index ae884224eec2..ae884224eec2 100644 --- a/Documentation/sparc/index.rst +++ b/Documentation/arch/sparc/index.rst diff --git a/Documentation/sparc/oradax/dax-hv-api.txt b/Documentation/arch/sparc/oradax/dax-hv-api.txt index 7ecd0bf4957b..7ecd0bf4957b 100644 --- a/Documentation/sparc/oradax/dax-hv-api.txt +++ b/Documentation/arch/sparc/oradax/dax-hv-api.txt diff --git a/Documentation/sparc/oradax/oracle-dax.rst b/Documentation/arch/sparc/oradax/oracle-dax.rst index d1e14d572918..d1e14d572918 100644 --- a/Documentation/sparc/oradax/oracle-dax.rst +++ b/Documentation/arch/sparc/oradax/oracle-dax.rst diff --git a/Documentation/x86/amd-memory-encryption.rst b/Documentation/arch/x86/amd-memory-encryption.rst index 934310ce7258..934310ce7258 100644 --- a/Documentation/x86/amd-memory-encryption.rst +++ b/Documentation/arch/x86/amd-memory-encryption.rst diff --git a/Documentation/x86/amd_hsmp.rst b/Documentation/arch/x86/amd_hsmp.rst index 440e4b645a1c..440e4b645a1c 100644 --- a/Documentation/x86/amd_hsmp.rst +++ b/Documentation/arch/x86/amd_hsmp.rst diff --git a/Documentation/x86/boot.rst b/Documentation/arch/x86/boot.rst index 240d084782a6..33520ecdb37a 100644 --- a/Documentation/x86/boot.rst +++ b/Documentation/arch/x86/boot.rst @@ -1344,7 +1344,7 @@ follow:: In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should also fill the additional fields of the struct boot_params as -described in chapter Documentation/x86/zero-page.rst. +described in chapter Documentation/arch/x86/zero-page.rst. After setting up the struct boot_params, the boot loader can load the 32/64-bit kernel in the same way as that of 16-bit boot protocol. @@ -1380,7 +1380,7 @@ can be calculated as follows:: In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should also fill the additional fields of the struct boot_params as described -in chapter Documentation/x86/zero-page.rst. +in chapter Documentation/arch/x86/zero-page.rst. After setting up the struct boot_params, the boot loader can load 64-bit kernel in the same way as that of 16-bit boot protocol, but diff --git a/Documentation/x86/booting-dt.rst b/Documentation/arch/x86/booting-dt.rst index 965a374071ab..b089ffd56e6e 100644 --- a/Documentation/x86/booting-dt.rst +++ b/Documentation/arch/x86/booting-dt.rst @@ -7,7 +7,7 @@ DeviceTree Booting the decompressor (the real mode entry point goes to the same 32bit entry point once it switched into protected mode). That entry point supports one calling convention which is documented in - Documentation/x86/boot.rst + Documentation/arch/x86/boot.rst The physical pointer to the device-tree block is passed via setup_data which requires at least boot protocol 2.09. The type filed is defined as diff --git a/Documentation/x86/buslock.rst b/Documentation/arch/x86/buslock.rst index 7c051e714943..31ec0ef78086 100644 --- a/Documentation/x86/buslock.rst +++ b/Documentation/arch/x86/buslock.rst @@ -53,8 +53,14 @@ parameter "split_lock_detect". Here is a summary of different options: |off |Do nothing |Do nothing | +------------------+----------------------------+-----------------------+ |warn |Kernel OOPs |Warn once per task and | -|(default) |Warn once per task and |and continues to run. | -| |disable future checking | | +|(default) |Warn once per task, add a |and continues to run. | +| |delay, add synchronization | | +| |to prevent more than one | | +| |core from executing a | | +| |split lock in parallel. | | +| |sysctl split_lock_mitigate | | +| |can be used to avoid the | | +| |delay and synchronization | | | |When both features are | | | |supported, warn in #AC | | +------------------+----------------------------+-----------------------+ diff --git a/Documentation/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst index 08246e8ac835..08246e8ac835 100644 --- a/Documentation/x86/cpuinfo.rst +++ b/Documentation/arch/x86/cpuinfo.rst diff --git a/Documentation/x86/earlyprintk.rst b/Documentation/arch/x86/earlyprintk.rst index 51ef11e8f725..51ef11e8f725 100644 --- a/Documentation/x86/earlyprintk.rst +++ b/Documentation/arch/x86/earlyprintk.rst diff --git a/Documentation/x86/elf_auxvec.rst b/Documentation/arch/x86/elf_auxvec.rst index 18e4744717f9..18e4744717f9 100644 --- a/Documentation/x86/elf_auxvec.rst +++ b/Documentation/arch/x86/elf_auxvec.rst diff --git a/Documentation/x86/entry_64.rst b/Documentation/arch/x86/entry_64.rst index 0afdce3c06f4..0afdce3c06f4 100644 --- a/Documentation/x86/entry_64.rst +++ b/Documentation/arch/x86/entry_64.rst diff --git a/Documentation/x86/exception-tables.rst b/Documentation/arch/x86/exception-tables.rst index efde1fef4fbd..efde1fef4fbd 100644 --- a/Documentation/x86/exception-tables.rst +++ b/Documentation/arch/x86/exception-tables.rst diff --git a/Documentation/x86/features.rst b/Documentation/arch/x86/features.rst index b663f15053ce..b663f15053ce 100644 --- a/Documentation/x86/features.rst +++ b/Documentation/arch/x86/features.rst diff --git a/Documentation/x86/i386/IO-APIC.rst b/Documentation/arch/x86/i386/IO-APIC.rst index ce4d8df15e7c..ce4d8df15e7c 100644 --- a/Documentation/x86/i386/IO-APIC.rst +++ b/Documentation/arch/x86/i386/IO-APIC.rst diff --git a/Documentation/x86/i386/index.rst b/Documentation/arch/x86/i386/index.rst index 8747cf5bbd49..8747cf5bbd49 100644 --- a/Documentation/x86/i386/index.rst +++ b/Documentation/arch/x86/i386/index.rst diff --git a/Documentation/x86/ifs.rst b/Documentation/arch/x86/ifs.rst index 97abb696a680..97abb696a680 100644 --- a/Documentation/x86/ifs.rst +++ b/Documentation/arch/x86/ifs.rst diff --git a/Documentation/x86/index.rst b/Documentation/arch/x86/index.rst index c73d133fd37c..c73d133fd37c 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/arch/x86/index.rst diff --git a/Documentation/x86/intel-hfi.rst b/Documentation/arch/x86/intel-hfi.rst index 49dea58ea4fb..49dea58ea4fb 100644 --- a/Documentation/x86/intel-hfi.rst +++ b/Documentation/arch/x86/intel-hfi.rst diff --git a/Documentation/x86/intel_txt.rst b/Documentation/arch/x86/intel_txt.rst index d83c1a2122c9..d83c1a2122c9 100644 --- a/Documentation/x86/intel_txt.rst +++ b/Documentation/arch/x86/intel_txt.rst diff --git a/Documentation/x86/iommu.rst b/Documentation/arch/x86/iommu.rst index 42c7a6faa39a..42c7a6faa39a 100644 --- a/Documentation/x86/iommu.rst +++ b/Documentation/arch/x86/iommu.rst diff --git a/Documentation/x86/kernel-stacks.rst b/Documentation/arch/x86/kernel-stacks.rst index 6b0bcf027ff1..6b0bcf027ff1 100644 --- a/Documentation/x86/kernel-stacks.rst +++ b/Documentation/arch/x86/kernel-stacks.rst diff --git a/Documentation/x86/mds.rst b/Documentation/arch/x86/mds.rst index 5d4330be200f..5d4330be200f 100644 --- a/Documentation/x86/mds.rst +++ b/Documentation/arch/x86/mds.rst diff --git a/Documentation/x86/microcode.rst b/Documentation/arch/x86/microcode.rst index b627c6f36bcf..b627c6f36bcf 100644 --- a/Documentation/x86/microcode.rst +++ b/Documentation/arch/x86/microcode.rst diff --git a/Documentation/x86/mtrr.rst b/Documentation/arch/x86/mtrr.rst index 9f0b1851771a..f65ef034da7a 100644 --- a/Documentation/x86/mtrr.rst +++ b/Documentation/arch/x86/mtrr.rst @@ -28,7 +28,7 @@ are aligned with platform MTRR setup. If MTRRs are only set up by the platform firmware code though and the OS does not make any specific MTRR mapping requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID. -For details refer to Documentation/x86/pat.rst. +For details refer to Documentation/arch/x86/pat.rst. .. tip:: On Intel P6 family processors (Pentium Pro, Pentium II and later) diff --git a/Documentation/x86/orc-unwinder.rst b/Documentation/arch/x86/orc-unwinder.rst index cdb257015bd9..cdb257015bd9 100644 --- a/Documentation/x86/orc-unwinder.rst +++ b/Documentation/arch/x86/orc-unwinder.rst diff --git a/Documentation/x86/pat.rst b/Documentation/arch/x86/pat.rst index 5d901771016d..5d901771016d 100644 --- a/Documentation/x86/pat.rst +++ b/Documentation/arch/x86/pat.rst diff --git a/Documentation/x86/pti.rst b/Documentation/arch/x86/pti.rst index 4b858a9bad8d..4b858a9bad8d 100644 --- a/Documentation/x86/pti.rst +++ b/Documentation/arch/x86/pti.rst diff --git a/Documentation/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst index 387ccbcb558f..387ccbcb558f 100644 --- a/Documentation/x86/resctrl.rst +++ b/Documentation/arch/x86/resctrl.rst diff --git a/Documentation/x86/sgx.rst b/Documentation/arch/x86/sgx.rst index 2bcbffacbed5..2bcbffacbed5 100644 --- a/Documentation/x86/sgx.rst +++ b/Documentation/arch/x86/sgx.rst diff --git a/Documentation/x86/sva.rst b/Documentation/arch/x86/sva.rst index 2e9b8b0f9a0f..33cb05005982 100644 --- a/Documentation/x86/sva.rst +++ b/Documentation/arch/x86/sva.rst @@ -107,7 +107,7 @@ process share the same page tables, thus the same MSR value. PASID Life Cycle Management =========================== -PASID is initialized as INVALID_IOASID (-1) when a process is created. +PASID is initialized as IOMMU_PASID_INVALID (-1) when a process is created. Only processes that access SVA-capable devices need to have a PASID allocated. This allocation happens when a process opens/binds an SVA-capable diff --git a/Documentation/x86/tdx.rst b/Documentation/arch/x86/tdx.rst index dc8d9fd2c3f7..dc8d9fd2c3f7 100644 --- a/Documentation/x86/tdx.rst +++ b/Documentation/arch/x86/tdx.rst diff --git a/Documentation/x86/tlb.rst b/Documentation/arch/x86/tlb.rst index 82ec58ae63a8..82ec58ae63a8 100644 --- a/Documentation/x86/tlb.rst +++ b/Documentation/arch/x86/tlb.rst diff --git a/Documentation/x86/topology.rst b/Documentation/arch/x86/topology.rst index 7f58010ea86a..7f58010ea86a 100644 --- a/Documentation/x86/topology.rst +++ b/Documentation/arch/x86/topology.rst diff --git a/Documentation/x86/tsx_async_abort.rst b/Documentation/arch/x86/tsx_async_abort.rst index 583ddc185ba2..583ddc185ba2 100644 --- a/Documentation/x86/tsx_async_abort.rst +++ b/Documentation/arch/x86/tsx_async_abort.rst diff --git a/Documentation/x86/usb-legacy-support.rst b/Documentation/arch/x86/usb-legacy-support.rst index e01c08b7c981..e01c08b7c981 100644 --- a/Documentation/x86/usb-legacy-support.rst +++ b/Documentation/arch/x86/usb-legacy-support.rst diff --git a/Documentation/x86/x86_64/5level-paging.rst b/Documentation/arch/x86/x86_64/5level-paging.rst index b792bbdc0b01..71f882f4a173 100644 --- a/Documentation/x86/x86_64/5level-paging.rst +++ b/Documentation/arch/x86/x86_64/5level-paging.rst @@ -20,7 +20,7 @@ physical address space. This "ought to be enough for anybody" ©. QEMU 2.9 and later support 5-level paging. Virtual memory layout for 5-level paging is described in -Documentation/x86/x86_64/mm.rst +Documentation/arch/x86/x86_64/mm.rst Enabling 5-level paging diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/arch/x86/x86_64/boot-options.rst index cbd14124a667..137432d34109 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/arch/x86/x86_64/boot-options.rst @@ -9,7 +9,7 @@ only the AMD64 specific ones are listed here. Machine check ============= -Please see Documentation/x86/x86_64/machinecheck.rst for sysfs runtime tunables. +Please see Documentation/arch/x86/x86_64/machinecheck.rst for sysfs runtime tunables. mce=off Disable machine check @@ -82,7 +82,7 @@ APICs Don't use the local APIC (alias for i386 compatibility) pirq=... - See Documentation/x86/i386/IO-APIC.rst + See Documentation/arch/x86/i386/IO-APIC.rst noapictimer Don't set up the APIC timer diff --git a/Documentation/x86/x86_64/cpu-hotplug-spec.rst b/Documentation/arch/x86/x86_64/cpu-hotplug-spec.rst index 8d1c91f0c880..8d1c91f0c880 100644 --- a/Documentation/x86/x86_64/cpu-hotplug-spec.rst +++ b/Documentation/arch/x86/x86_64/cpu-hotplug-spec.rst diff --git a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst b/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst index ff9bcfd2cc14..ba74617d4999 100644 --- a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst +++ b/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst @@ -18,7 +18,7 @@ For more information on the features of cpusets, see Documentation/admin-guide/cgroup-v1/cpusets.rst. There are a number of different configurations you can use for your needs. For more information on the numa=fake command line option and its various ways of -configuring fake nodes, see Documentation/x86/x86_64/boot-options.rst. +configuring fake nodes, see Documentation/arch/x86/x86_64/boot-options.rst. For the purposes of this introduction, we'll assume a very primitive NUMA emulation setup of "numa=fake=4*512,". This will split our system memory into diff --git a/Documentation/x86/x86_64/fsgs.rst b/Documentation/arch/x86/x86_64/fsgs.rst index 50960e09e1f6..50960e09e1f6 100644 --- a/Documentation/x86/x86_64/fsgs.rst +++ b/Documentation/arch/x86/x86_64/fsgs.rst diff --git a/Documentation/x86/x86_64/index.rst b/Documentation/arch/x86/x86_64/index.rst index a56070fc8e77..a56070fc8e77 100644 --- a/Documentation/x86/x86_64/index.rst +++ b/Documentation/arch/x86/x86_64/index.rst diff --git a/Documentation/x86/x86_64/machinecheck.rst b/Documentation/arch/x86/x86_64/machinecheck.rst index cea12ee97200..cea12ee97200 100644 --- a/Documentation/x86/x86_64/machinecheck.rst +++ b/Documentation/arch/x86/x86_64/machinecheck.rst diff --git a/Documentation/x86/x86_64/mm.rst b/Documentation/arch/x86/x86_64/mm.rst index 35e5e18c83d0..35e5e18c83d0 100644 --- a/Documentation/x86/x86_64/mm.rst +++ b/Documentation/arch/x86/x86_64/mm.rst diff --git a/Documentation/x86/x86_64/uefi.rst b/Documentation/arch/x86/x86_64/uefi.rst index fbc30c9a071d..fbc30c9a071d 100644 --- a/Documentation/x86/x86_64/uefi.rst +++ b/Documentation/arch/x86/x86_64/uefi.rst diff --git a/Documentation/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst new file mode 100644 index 000000000000..ae5c69e48b11 --- /dev/null +++ b/Documentation/arch/x86/xstate.rst @@ -0,0 +1,174 @@ +Using XSTATE features in user space applications +================================================ + +The x86 architecture supports floating-point extensions which are +enumerated via CPUID. Applications consult CPUID and use XGETBV to +evaluate which features have been enabled by the kernel XCR0. + +Up to AVX-512 and PKRU states, these features are automatically enabled by +the kernel if available. Features like AMX TILE_DATA (XSTATE component 18) +are enabled by XCR0 as well, but the first use of related instruction is +trapped by the kernel because by default the required large XSTATE buffers +are not allocated automatically. + +The purpose for dynamic features +-------------------------------- + +Legacy userspace libraries often have hard-coded, static sizes for +alternate signal stacks, often using MINSIGSTKSZ which is typically 2KB. +That stack must be able to store at *least* the signal frame that the +kernel sets up before jumping into the signal handler. That signal frame +must include an XSAVE buffer defined by the CPU. + +However, that means that the size of signal stacks is dynamic, not static, +because different CPUs have differently-sized XSAVE buffers. A compiled-in +size of 2KB with existing applications is too small for new CPU features +like AMX. Instead of universally requiring larger stack, with the dynamic +enabling, the kernel can enforce userspace applications to have +properly-sized altstacks. + +Using dynamically enabled XSTATE features in user space applications +-------------------------------------------------------------------- + +The kernel provides an arch_prctl(2) based mechanism for applications to +request the usage of such features. The arch_prctl(2) options related to +this are: + +-ARCH_GET_XCOMP_SUPP + + arch_prctl(ARCH_GET_XCOMP_SUPP, &features); + + ARCH_GET_XCOMP_SUPP stores the supported features in userspace storage of + type uint64_t. The second argument is a pointer to that storage. + +-ARCH_GET_XCOMP_PERM + + arch_prctl(ARCH_GET_XCOMP_PERM, &features); + + ARCH_GET_XCOMP_PERM stores the features for which the userspace process + has permission in userspace storage of type uint64_t. The second argument + is a pointer to that storage. + +-ARCH_REQ_XCOMP_PERM + + arch_prctl(ARCH_REQ_XCOMP_PERM, feature_nr); + + ARCH_REQ_XCOMP_PERM allows to request permission for a dynamically enabled + feature or a feature set. A feature set can be mapped to a facility, e.g. + AMX, and can require one or more XSTATE components to be enabled. + + The feature argument is the number of the highest XSTATE component which + is required for a facility to work. + +When requesting permission for a feature, the kernel checks the +availability. The kernel ensures that sigaltstacks in the process's tasks +are large enough to accommodate the resulting large signal frame. It +enforces this both during ARCH_REQ_XCOMP_SUPP and during any subsequent +sigaltstack(2) calls. If an installed sigaltstack is smaller than the +resulting sigframe size, ARCH_REQ_XCOMP_SUPP results in -ENOSUPP. Also, +sigaltstack(2) results in -ENOMEM if the requested altstack is too small +for the permitted features. + +Permission, when granted, is valid per process. Permissions are inherited +on fork(2) and cleared on exec(3). + +The first use of an instruction related to a dynamically enabled feature is +trapped by the kernel. The trap handler checks whether the process has +permission to use the feature. If the process has no permission then the +kernel sends SIGILL to the application. If the process has permission then +the handler allocates a larger xstate buffer for the task so the large +state can be context switched. In the unlikely cases that the allocation +fails, the kernel sends SIGSEGV. + +AMX TILE_DATA enabling example +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Below is the example of how userspace applications enable +TILE_DATA dynamically: + + 1. The application first needs to query the kernel for AMX + support:: + + #include <asm/prctl.h> + #include <sys/syscall.h> + #include <stdio.h> + #include <unistd.h> + + #ifndef ARCH_GET_XCOMP_SUPP + #define ARCH_GET_XCOMP_SUPP 0x1021 + #endif + + #ifndef ARCH_XCOMP_TILECFG + #define ARCH_XCOMP_TILECFG 17 + #endif + + #ifndef ARCH_XCOMP_TILEDATA + #define ARCH_XCOMP_TILEDATA 18 + #endif + + #define MASK_XCOMP_TILE ((1 << ARCH_XCOMP_TILECFG) | \ + (1 << ARCH_XCOMP_TILEDATA)) + + unsigned long features; + long rc; + + ... + + rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_SUPP, &features); + + if (!rc && (features & MASK_XCOMP_TILE) == MASK_XCOMP_TILE) + printf("AMX is available.\n"); + + 2. After that, determining support for AMX, an application must + explicitly ask permission to use it:: + + #ifndef ARCH_REQ_XCOMP_PERM + #define ARCH_REQ_XCOMP_PERM 0x1023 + #endif + + ... + + rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, ARCH_XCOMP_TILEDATA); + + if (!rc) + printf("AMX is ready for use.\n"); + +Note this example does not include the sigaltstack preparation. + +Dynamic features in signal frames +--------------------------------- + +Dynamcally enabled features are not written to the signal frame upon signal +entry if the feature is in its initial configuration. This differs from +non-dynamic features which are always written regardless of their +configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV +field to determine if a features was written. + +Dynamic features for virtual machines +------------------------------------- + +The permission for the guest state component needs to be managed separately +from the host, as they are exclusive to each other. A coupled of options +are extended to control the guest permission: + +-ARCH_GET_XCOMP_GUEST_PERM + + arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features); + + ARCH_GET_XCOMP_GUEST_PERM is a variant of ARCH_GET_XCOMP_PERM. So it + provides the same semantics and functionality but for the guest + components. + +-ARCH_REQ_XCOMP_GUEST_PERM + + arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM, feature_nr); + + ARCH_REQ_XCOMP_GUEST_PERM is a variant of ARCH_REQ_XCOMP_PERM. It has the + same semantics for the guest permission. While providing a similar + functionality, this comes with a constraint. Permission is frozen when the + first VCPU is created. Any attempt to change permission after that point + is going to be rejected. So, the permission has to be requested before the + first VCPU creation. + +Note that some VMMs may have already established a set of supported state +components. These options are not presumed to support any particular VMM. diff --git a/Documentation/x86/zero-page.rst b/Documentation/arch/x86/zero-page.rst index 45aa9cceb4f1..45aa9cceb4f1 100644 --- a/Documentation/x86/zero-page.rst +++ b/Documentation/arch/x86/zero-page.rst diff --git a/Documentation/xtensa/atomctl.rst b/Documentation/arch/xtensa/atomctl.rst index 1ecbd0ba9a2e..1ecbd0ba9a2e 100644 --- a/Documentation/xtensa/atomctl.rst +++ b/Documentation/arch/xtensa/atomctl.rst diff --git a/Documentation/xtensa/booting.rst b/Documentation/arch/xtensa/booting.rst index e1b83707e5b6..e1b83707e5b6 100644 --- a/Documentation/xtensa/booting.rst +++ b/Documentation/arch/xtensa/booting.rst diff --git a/Documentation/xtensa/features.rst b/Documentation/arch/xtensa/features.rst index 6b92c7bfa19d..6b92c7bfa19d 100644 --- a/Documentation/xtensa/features.rst +++ b/Documentation/arch/xtensa/features.rst diff --git a/Documentation/xtensa/index.rst b/Documentation/arch/xtensa/index.rst index 69952446a9be..69952446a9be 100644 --- a/Documentation/xtensa/index.rst +++ b/Documentation/arch/xtensa/index.rst diff --git a/Documentation/xtensa/mmu.rst b/Documentation/arch/xtensa/mmu.rst index 450573afa31a..450573afa31a 100644 --- a/Documentation/xtensa/mmu.rst +++ b/Documentation/arch/xtensa/mmu.rst diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst index ae42fe886f0d..fd43502ae924 100644 --- a/Documentation/arm/index.rst +++ b/Documentation/arm/index.rst @@ -58,6 +58,7 @@ SoC-specific documents stm32/stm32f769-overview stm32/stm32f429-overview stm32/stm32mp13-overview + stm32/stm32mp151-overview stm32/stm32mp157-overview stm32/stm32-dma-mdma-chaining @@ -69,11 +70,9 @@ SoC-specific documents spear/overview - sti/stih416-overview sti/stih407-overview sti/stih418-overview sti/overview - sti/stih415-overview vfp/release-notes diff --git a/Documentation/arm/sti/overview.rst b/Documentation/arm/sti/overview.rst index 70743617a74f..ae16aced800f 100644 --- a/Documentation/arm/sti/overview.rst +++ b/Documentation/arm/sti/overview.rst @@ -7,22 +7,18 @@ Introduction The ST Microelectronics Multimedia and Application Processors range of CortexA9 System-on-Chip are supported by the 'STi' platform of - ARM Linux. Currently STiH415, STiH416 SOCs are supported with both - B2000 and B2020 Reference boards. + ARM Linux. Currently STiH407, STiH410 and STiH418 are supported. configuration ------------- - A generic configuration is provided for both STiH415/416, and can be used as the - default by:: - - make stih41x_defconfig + The configuration for the STi platform is supported via the multi_v7_defconfig. Layout ------ - All the files for multiple machine families (STiH415, STiH416, and STiG125) + All the files for multiple machine families (STiH407, STiH410, and STiH418) are located in the platform code contained in arch/arm/mach-sti There is a generic board board-dt.c in the mach folder which support diff --git a/Documentation/arm/sti/stih415-overview.rst b/Documentation/arm/sti/stih415-overview.rst deleted file mode 100644 index b67452d610c4..000000000000 --- a/Documentation/arm/sti/stih415-overview.rst +++ /dev/null @@ -1,14 +0,0 @@ -================ -STiH415 Overview -================ - -Introduction ------------- - - The STiH415 is the next generation of HD, AVC set-top box processors - for satellite, cable, terrestrial and IP-STB markets. - - Features: - - - ARM Cortex-A9 1.0 GHz, dual-core CPU - - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2 diff --git a/Documentation/arm/sti/stih416-overview.rst b/Documentation/arm/sti/stih416-overview.rst deleted file mode 100644 index 93f17d74d8db..000000000000 --- a/Documentation/arm/sti/stih416-overview.rst +++ /dev/null @@ -1,13 +0,0 @@ -================ -STiH416 Overview -================ - -Introduction ------------- - - The STiH416 is the next generation of HD, AVC set-top box processors - for satellite, cable, terrestrial and IP-STB markets. - - Features - - ARM Cortex-A9 1.2 GHz dual core CPU - - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2 diff --git a/Documentation/arm/stm32/stm32mp151-overview.rst b/Documentation/arm/stm32/stm32mp151-overview.rst new file mode 100644 index 000000000000..f42a2ac309c0 --- /dev/null +++ b/Documentation/arm/stm32/stm32mp151-overview.rst @@ -0,0 +1,36 @@ +=================== +STM32MP151 Overview +=================== + +Introduction +------------ + +The STM32MP151 is a Cortex-A MPU aimed at various applications. +It features: + +- Single Cortex-A7 application core +- Standard memories interface support +- Standard connectivity, widely inherited from the STM32 MCU family +- Comprehensive security support + +More details: + +- Cortex-A7 core running up to @800MHz +- FMC controller to connect SDRAM, NOR and NAND memories +- QSPI +- SD/MMC/SDIO support +- Ethernet controller +- ADC/DAC +- USB EHCI/OHCI controllers +- USB OTG +- I2C, SPI busses support +- Several general purpose timers +- Serial Audio interface +- LCD-TFT controller +- DCMIPP +- SPDIFRX +- DFSDM + +:Authors: + +- Roan van Dijk <roan@protonic.nl> diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index ec5f889d7681..9e311bc43e05 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -172,6 +172,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM | +----------------+-----------------+-----------------+-----------------------------+ +| NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 | +----------------+-----------------+-----------------+-----------------------------+ @@ -205,6 +207,9 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 | +----------------+-----------------+-----------------+-----------------------------+ ++----------------+-----------------+-----------------+-----------------------------+ +| Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 | diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index f9bf18ea6509..90b733422ed4 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -270,8 +270,7 @@ Request queue based layered devices like dm-rq that wish to support inline encryption need to create their own blk_crypto_profile for their request_queue, and expose whatever functionality they choose. When a layered device wants to pass a clone of that request to another request_queue, blk-crypto will -initialize and prepare the clone as necessary; see -``blk_crypto_insert_cloned_request()``. +initialize and prepare the clone as necessary. Interaction between inline encryption and blk integrity ======================================================= diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst index bfff0e7e37c2..38372a956d65 100644 --- a/Documentation/bpf/bpf_design_QA.rst +++ b/Documentation/bpf/bpf_design_QA.rst @@ -314,7 +314,7 @@ Q: What is the compatibility story for special BPF types in map values? Q: Users are allowed to embed bpf_spin_lock, bpf_timer fields in their BPF map values (when using BTF support for BPF maps). This allows to use helpers for such objects on these fields inside map values. Users are also allowed to embed -pointers to some kernel types (with __kptr and __kptr_ref BTF tags). Will the +pointers to some kernel types (with __kptr_untrusted and __kptr BTF tags). Will the kernel preserve backwards compatibility for these features? A: It depends. For bpf_spin_lock, bpf_timer: YES, for kptr and everything else: @@ -324,7 +324,7 @@ For struct types that have been added already, like bpf_spin_lock and bpf_timer, the kernel will preserve backwards compatibility, as they are part of UAPI. For kptrs, they are also part of UAPI, but only with respect to the kptr -mechanism. The types that you can use with a __kptr and __kptr_ref tagged +mechanism. The types that you can use with a __kptr_untrusted and __kptr tagged pointer in your struct are NOT part of the UAPI contract. The supported types can and will change across kernel releases. However, operations like accessing kptr fields and bpf_kptr_xchg() helper will continue to be supported across kernel diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst index 03d4993eda6f..609b71f5747d 100644 --- a/Documentation/bpf/bpf_devel_QA.rst +++ b/Documentation/bpf/bpf_devel_QA.rst @@ -7,8 +7,8 @@ workflows related to reporting bugs, submitting patches, and queueing patches for stable kernels. For general information about submitting patches, please refer to -`Documentation/process/`_. This document only describes additional specifics -related to BPF. +Documentation/process/submitting-patches.rst. This document only describes +additional specifics related to BPF. .. contents:: :local: @@ -128,7 +128,8 @@ into the bpf-next tree will make their way into net-next tree. net and net-next are both run by David S. Miller. From there, they will go into the kernel mainline tree run by Linus Torvalds. To read up on the process of net and net-next being merged into the mainline tree, see -the :ref:`netdev-FAQ` +the documentation on netdev subsystem at +Documentation/process/maintainer-netdev.rst. @@ -147,7 +148,8 @@ request):: Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to? --------------------------------------------------------------------------------- -A: The process is the very same as described in the :ref:`netdev-FAQ`, +A: The process is the very same as described in the netdev subsystem +documentation at Documentation/process/maintainer-netdev.rst, so please read up on it. The subject line must indicate whether the patch is a fix or rather "next-like" content in order to let the maintainers know whether it is targeted at bpf or bpf-next. @@ -206,8 +208,9 @@ ii) run extensive BPF test suite and Once the BPF pull request was accepted by David S. Miller, then the patches end up in net or net-next tree, respectively, and make their way from there further into mainline. Again, see the -:ref:`netdev-FAQ` for additional information e.g. on how often they are -merged to mainline. +documentation for netdev subsystem at +Documentation/process/maintainer-netdev.rst for additional information +e.g. on how often they are merged to mainline. Q: How long do I need to wait for feedback on my BPF patches? ------------------------------------------------------------- @@ -230,7 +233,8 @@ Q: Are patches applied to bpf-next when the merge window is open? ----------------------------------------------------------------- A: For the time when the merge window is open, bpf-next will not be processed. This is roughly analogous to net-next patch processing, -so feel free to read up on the :ref:`netdev-FAQ` about further details. +so feel free to read up on the netdev docs at +Documentation/process/maintainer-netdev.rst about further details. During those two weeks of merge window, we might ask you to resend your patch series once bpf-next is open again. Once Linus released @@ -394,7 +398,8 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up: netdev@vger.kernel.org The process in general is the same as on netdev itself, see also the -:ref:`netdev-FAQ`. +the documentation on networking subsystem at +Documentation/process/maintainer-netdev.rst. Q: Do you also backport to kernels not currently maintained as stable? ---------------------------------------------------------------------- @@ -410,7 +415,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well What should I do? A: The same rules apply as with netdev patch submissions in general, see -the :ref:`netdev-FAQ`. +the netdev docs at Documentation/process/maintainer-netdev.rst. Never add "``Cc: stable@vger.kernel.org``" to the patch description, but ask the BPF maintainers to queue the patches instead. This can be done @@ -461,15 +466,15 @@ needed:: $ sudo make run_tests -See the kernels selftest `Documentation/dev-tools/kselftest.rst`_ -document for further documentation. +See :doc:`kernel selftest documentation </dev-tools/kselftest>` +for details. To maximize the number of tests passing, the .config of the kernel under test should match the config file fragment in tools/testing/selftests/bpf as closely as possible. Finally to ensure support for latest BPF Type Format features - -discussed in `Documentation/bpf/btf.rst`_ - pahole version 1.16 +discussed in Documentation/bpf/btf.rst - pahole version 1.16 is required for kernels built with CONFIG_DEBUG_INFO_BTF=y. pahole is delivered in the dwarves package or can be built from source at @@ -684,12 +689,7 @@ when: .. Links -.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/ -.. _netdev-FAQ: Documentation/process/maintainer-netdev.rst .. _selftests: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/ -.. _Documentation/dev-tools/kselftest.rst: - https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html -.. _Documentation/bpf/btf.rst: btf.rst Happy BPF hacking! diff --git a/Documentation/bpf/clang-notes.rst b/Documentation/bpf/clang-notes.rst index 528feddf2db9..2c872a1ee08e 100644 --- a/Documentation/bpf/clang-notes.rst +++ b/Documentation/bpf/clang-notes.rst @@ -20,6 +20,12 @@ Arithmetic instructions For CPU versions prior to 3, Clang v7.0 and later can enable ``BPF_ALU`` support with ``-Xclang -target-feature -Xclang +alu32``. In CPU version 3, support is automatically included. +Jump instructions +================= + +If ``-O0`` is used, Clang will generate the ``BPF_CALL | BPF_X | BPF_JMP`` (0x8d) +instruction, which is not supported by the Linux kernel verifier. + Atomic operations ================= diff --git a/Documentation/bpf/cpumasks.rst b/Documentation/bpf/cpumasks.rst index 24bef9cbbeee..41efd8874eeb 100644 --- a/Documentation/bpf/cpumasks.rst +++ b/Documentation/bpf/cpumasks.rst @@ -51,7 +51,7 @@ For example: .. code-block:: c struct cpumask_map_value { - struct bpf_cpumask __kptr_ref * cpumask; + struct bpf_cpumask __kptr * cpumask; }; struct array_map { @@ -117,18 +117,13 @@ For example: As mentioned and illustrated above, these ``struct bpf_cpumask *`` objects can also be stored in a map and used as kptrs. If a ``struct bpf_cpumask *`` is in a map, the reference can be removed from the map with bpf_kptr_xchg(), or -opportunistically acquired with bpf_cpumask_kptr_get(): - -.. kernel-doc:: kernel/bpf/cpumask.c - :identifiers: bpf_cpumask_kptr_get - -Here is an example of a ``struct bpf_cpumask *`` being retrieved from a map: +opportunistically acquired using RCU: .. code-block:: c /* struct containing the struct bpf_cpumask kptr which is stored in the map. */ struct cpumasks_kfunc_map_value { - struct bpf_cpumask __kptr_ref * bpf_cpumask; + struct bpf_cpumask __kptr * bpf_cpumask; }; /* The map containing struct cpumasks_kfunc_map_value entries. */ @@ -144,7 +139,7 @@ Here is an example of a ``struct bpf_cpumask *`` being retrieved from a map: /** * A simple example tracepoint program showing how a * struct bpf_cpumask * kptr that is stored in a map can - * be acquired using the bpf_cpumask_kptr_get() kfunc. + * be passed to kfuncs using RCU protection. */ SEC("tp_btf/cgroup_mkdir") int BPF_PROG(cgrp_ancestor_example, struct cgroup *cgrp, const char *path) @@ -158,26 +153,21 @@ Here is an example of a ``struct bpf_cpumask *`` being retrieved from a map: if (!v) return -ENOENT; + bpf_rcu_read_lock(); /* Acquire a reference to the bpf_cpumask * kptr that's already stored in the map. */ - kptr = bpf_cpumask_kptr_get(&v->cpumask); - if (!kptr) + kptr = v->cpumask; + if (!kptr) { /* If no bpf_cpumask was present in the map, it's because * we're racing with another CPU that removed it with * bpf_kptr_xchg() between the bpf_map_lookup_elem() - * above, and our call to bpf_cpumask_kptr_get(). - * bpf_cpumask_kptr_get() internally safely handles this - * race, and will return NULL if the cpumask is no longer - * present in the map by the time we invoke the kfunc. + * above, and our load of the pointer from the map. */ + bpf_rcu_read_unlock(); return -EBUSY; + } - /* Free the reference we just took above. Note that the - * original struct bpf_cpumask * kptr is still in the map. It will - * be freed either at a later time if another context deletes - * it from the map, or automatically by the BPF subsystem if - * it's still present when the map is destroyed. - */ - bpf_cpumask_release(kptr); + bpf_cpumask_setall(kptr); + bpf_rcu_read_unlock(); return 0; } diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index af515de5fc38..492980ece1ab 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -11,7 +11,8 @@ Documentation conventions ========================= For brevity, this document uses the type notion "u64", "u32", etc. -to mean an unsigned integer whose width is the specified number of bits. +to mean an unsigned integer whose width is the specified number of bits, +and "s32", etc. to mean a signed integer of the specified number of bits. Registers and calling convention ================================ @@ -38,14 +39,11 @@ eBPF has two instruction encodings: * the wide instruction encoding, which appends a second 64-bit immediate (i.e., constant) value after the basic instruction for a total of 128 bits. -The basic instruction encoding is as follows, where MSB and LSB mean the most significant -bits and least significant bits, respectively: +The fields conforming an encoded basic instruction are stored in the +following order:: -============= ======= ======= ======= ============ -32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB) -============= ======= ======= ======= ============ -imm offset src_reg dst_reg opcode -============= ======= ======= ======= ============ + opcode:8 src_reg:4 dst_reg:4 offset:16 imm:32 // In little-endian BPF. + opcode:8 dst_reg:4 src_reg:4 offset:16 imm:32 // In big-endian BPF. **imm** signed integer immediate value @@ -63,6 +61,18 @@ imm offset src_reg dst_reg opcode **opcode** operation to perform +Note that the contents of multi-byte fields ('imm' and 'offset') are +stored using big-endian byte ordering in big-endian BPF and +little-endian byte ordering in little-endian BPF. + +For example:: + + opcode offset imm assembly + src_reg dst_reg + 07 0 1 00 00 44 33 22 11 r1 += 0x11223344 // little + dst_reg src_reg + 07 1 0 00 00 11 22 33 44 r1 += 0x11223344 // big + Note that most instructions do not use all of the fields. Unused fields shall be cleared to zero. @@ -72,18 +82,23 @@ The 64 bits following the basic instruction contain a pseudo instruction using the same format but with opcode, dst_reg, src_reg, and offset all set to zero, and imm containing the high 32 bits of the immediate value. -================= ================== -64 bits (MSB) 64 bits (LSB) -================= ================== -basic instruction pseudo instruction -================= ================== +This is depicted in the following figure:: + + basic_instruction + .-----------------------------. + | | + code:8 regs:8 offset:16 imm:32 unused:32 imm:32 + | | + '--------------' + pseudo instruction Thus the 64-bit immediate value is constructed as follows: imm64 = (next_imm << 32) | imm where 'next_imm' refers to the imm value of the pseudo instruction -following the basic instruction. +following the basic instruction. The unused bytes in the pseudo +instruction are reserved and shall be cleared to zero. Instruction classes ------------------- @@ -228,28 +243,58 @@ Jump instructions otherwise identical operations. The 'code' field encodes the operation as below: -======== ===== ========================= ============ -code value description notes -======== ===== ========================= ============ -BPF_JA 0x00 PC += off BPF_JMP only -BPF_JEQ 0x10 PC += off if dst == src -BPF_JGT 0x20 PC += off if dst > src unsigned -BPF_JGE 0x30 PC += off if dst >= src unsigned -BPF_JSET 0x40 PC += off if dst & src -BPF_JNE 0x50 PC += off if dst != src -BPF_JSGT 0x60 PC += off if dst > src signed -BPF_JSGE 0x70 PC += off if dst >= src signed -BPF_CALL 0x80 function call -BPF_EXIT 0x90 function / program return BPF_JMP only -BPF_JLT 0xa0 PC += off if dst < src unsigned -BPF_JLE 0xb0 PC += off if dst <= src unsigned -BPF_JSLT 0xc0 PC += off if dst < src signed -BPF_JSLE 0xd0 PC += off if dst <= src signed -======== ===== ========================= ============ +======== ===== === =========================================== ========================================= +code value src description notes +======== ===== === =========================================== ========================================= +BPF_JA 0x0 0x0 PC += offset BPF_JMP only +BPF_JEQ 0x1 any PC += offset if dst == src +BPF_JGT 0x2 any PC += offset if dst > src unsigned +BPF_JGE 0x3 any PC += offset if dst >= src unsigned +BPF_JSET 0x4 any PC += offset if dst & src +BPF_JNE 0x5 any PC += offset if dst != src +BPF_JSGT 0x6 any PC += offset if dst > src signed +BPF_JSGE 0x7 any PC += offset if dst >= src signed +BPF_CALL 0x8 0x0 call helper function by address see `Helper functions`_ +BPF_CALL 0x8 0x1 call PC += offset see `Program-local functions`_ +BPF_CALL 0x8 0x2 call helper function by BTF ID see `Helper functions`_ +BPF_EXIT 0x9 0x0 return BPF_JMP only +BPF_JLT 0xa any PC += offset if dst < src unsigned +BPF_JLE 0xb any PC += offset if dst <= src unsigned +BPF_JSLT 0xc any PC += offset if dst < src signed +BPF_JSLE 0xd any PC += offset if dst <= src signed +======== ===== === =========================================== ========================================= The eBPF program needs to store the return value into register R0 before doing a -BPF_EXIT. +``BPF_EXIT``. + +Example: + +``BPF_JSGE | BPF_X | BPF_JMP32`` (0x7e) means:: + + if (s32)dst s>= (s32)src goto +offset + +where 's>=' indicates a signed '>=' comparison. +Helper functions +~~~~~~~~~~~~~~~~ + +Helper functions are a concept whereby BPF programs can call into a +set of function calls exposed by the underlying platform. + +Historically, each helper function was identified by an address +encoded in the imm field. The available helper functions may differ +for each program type, but address values are unique across all program types. + +Platforms that support the BPF Type Format (BTF) support identifying +a helper function by a BTF ID encoded in the imm field, where the BTF ID +identifies the helper name and type. + +Program-local functions +~~~~~~~~~~~~~~~~~~~~~~~ +Program-local functions are functions exposed by the same BPF program as the +caller, and are referenced by offset from the call instruction, similar to +``BPF_JA``. A ``BPF_EXIT`` within the program-local function will return to +the caller. Load and store instructions =========================== @@ -371,14 +416,56 @@ and loaded back to ``R0``. ----------------------------- Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction -encoding for an extra imm64 value. - -There is currently only one such instruction. - -``BPF_LD | BPF_DW | BPF_IMM`` means:: - - dst = imm64 - +encoding defined in `Instruction encoding`_, and use the 'src' field of the +basic instruction to hold an opcode subtype. + +The following table defines a set of ``BPF_IMM | BPF_DW | BPF_LD`` instructions +with opcode subtypes in the 'src' field, using new terms such as "map" +defined further below: + +========================= ====== === ========================================= =========== ============== +opcode construction opcode src pseudocode imm type dst type +========================= ====== === ========================================= =========== ============== +BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = imm64 integer integer +BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map +BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer +BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer +BPF_IMM | BPF_DW | BPF_LD 0x18 0x4 dst = code_addr(imm) integer code pointer +BPF_IMM | BPF_DW | BPF_LD 0x18 0x5 dst = map_by_idx(imm) map index map +BPF_IMM | BPF_DW | BPF_LD 0x18 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer +========================= ====== === ========================================= =========== ============== + +where + +* map_by_fd(imm) means to convert a 32-bit file descriptor into an address of a map (see `Maps`_) +* map_by_idx(imm) means to convert a 32-bit index into an address of a map +* map_val(map) gets the address of the first value in a given map +* var_addr(imm) gets the address of a platform variable (see `Platform Variables`_) with a given id +* code_addr(imm) gets the address of the instruction at a specified relative offset in number of (64-bit) instructions +* the 'imm type' can be used by disassemblers for display +* the 'dst type' can be used for verification and JIT compilation purposes + +Maps +~~~~ + +Maps are shared memory regions accessible by eBPF programs on some platforms. +A map can have various semantics as defined in a separate document, and may or +may not have a single contiguous memory region, but the 'map_val(map)' is +currently only defined for maps that do have a single contiguous memory region. + +Each map can have a file descriptor (fd) if supported by the platform, where +'map_by_fd(imm)' means to get the map with the specified file descriptor. Each +BPF program can also be defined to use a set of maps associated with the +program at load time, and 'map_by_idx(imm)' means to get the map with the given +index in the set associated with the BPF program containing the instruction. + +Platform Variables +~~~~~~~~~~~~~~~~~~ + +Platform variables are memory regions, identified by integer ids, exposed by +the runtime and accessible by BPF programs on some platforms. The +'var_addr(imm)' operation means to get the address of the memory region +identified by the given id. Legacy BPF Packet access instructions ------------------------------------- diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst index ca96ef3f6896..ea2516374d92 100644 --- a/Documentation/bpf/kfuncs.rst +++ b/Documentation/bpf/kfuncs.rst @@ -100,6 +100,23 @@ Hence, whenever a constant scalar argument is accepted by a kfunc which is not a size parameter, and the value of the constant matters for program safety, __k suffix should be used. +2.2.2 __uninit Annotation +------------------------- + +This annotation is used to indicate that the argument will be treated as +uninitialized. + +An example is given below:: + + __bpf_kfunc int bpf_dynptr_from_skb(..., struct bpf_dynptr_kern *ptr__uninit) + { + ... + } + +Here, the dynptr will be treated as an uninitialized dynptr. Without this +annotation, the verifier will reject the program if the dynptr passed in is +not initialized. + .. _BPF_kfunc_nodef: 2.3 Using an existing kernel function @@ -162,20 +179,12 @@ both are orthogonal to each other. --------------------- The KF_RELEASE flag is used to indicate that the kfunc releases the pointer -passed in to it. There can be only one referenced pointer that can be passed in. -All copies of the pointer being released are invalidated as a result of invoking -kfunc with this flag. - -2.4.4 KF_KPTR_GET flag ----------------------- - -The KF_KPTR_GET flag is used to indicate that the kfunc takes the first argument -as a pointer to kptr, safely increments the refcount of the object it points to, -and returns a reference to the user. The rest of the arguments may be normal -arguments of a kfunc. The KF_KPTR_GET flag should be used in conjunction with -KF_ACQUIRE and KF_RET_NULL flags. +passed in to it. There can be only one referenced pointer that can be passed +in. All copies of the pointer being released are invalidated as a result of +invoking kfunc with this flag. KF_RELEASE kfuncs automatically receive the +protection afforded by the KF_TRUSTED_ARGS flag described below. -2.4.5 KF_TRUSTED_ARGS flag +2.4.4 KF_TRUSTED_ARGS flag -------------------------- The KF_TRUSTED_ARGS flag is used for kfuncs taking pointer arguments. It @@ -187,7 +196,7 @@ exception described below). There are two types of pointers to kernel objects which are considered "valid": 1. Pointers which are passed as tracepoint or struct_ops callback arguments. -2. Pointers which were returned from a KF_ACQUIRE or KF_KPTR_GET kfunc. +2. Pointers which were returned from a KF_ACQUIRE kfunc. Pointers to non-BTF objects (e.g. scalar pointers) may also be passed to KF_TRUSTED_ARGS kfuncs, and may have a non-zero offset. @@ -214,13 +223,13 @@ In other words, you must: 2. Specify the type and name of the trusted nested field. This field must match the field in the original type definition exactly. -2.4.6 KF_SLEEPABLE flag +2.4.5 KF_SLEEPABLE flag ----------------------- The KF_SLEEPABLE flag is used for kfuncs that may sleep. Such kfuncs can only be called by sleepable BPF programs (BPF_F_SLEEPABLE). -2.4.7 KF_DESTRUCTIVE flag +2.4.6 KF_DESTRUCTIVE flag -------------------------- The KF_DESTRUCTIVE flag is used to indicate functions calling which is @@ -229,18 +238,20 @@ rebooting or panicking. Due to this additional restrictions apply to these calls. At the moment they only require CAP_SYS_BOOT capability, but more can be added later. -2.4.8 KF_RCU flag +2.4.7 KF_RCU flag ----------------- -The KF_RCU flag is used for kfuncs which have a rcu ptr as its argument. -When used together with KF_ACQUIRE, it indicates the kfunc should have a -single argument which must be a trusted argument or a MEM_RCU pointer. -The argument may have reference count of 0 and the kfunc must take this -into consideration. +The KF_RCU flag is a weaker version of KF_TRUSTED_ARGS. The kfuncs marked with +KF_RCU expect either PTR_TRUSTED or MEM_RCU arguments. The verifier guarantees +that the objects are valid and there is no use-after-free. The pointers are not +NULL, but the object's refcount could have reached zero. The kfuncs need to +consider doing refcnt != 0 check, especially when returning a KF_ACQUIRE +pointer. Note as well that a KF_ACQUIRE kfunc that is KF_RCU should very likely +also be KF_RET_NULL. .. _KF_deprecated_flag: -2.4.9 KF_DEPRECATED flag +2.4.8 KF_DEPRECATED flag ------------------------ The KF_DEPRECATED flag is used for kfuncs which are scheduled to be @@ -451,13 +462,50 @@ struct_ops callback arg. For example: struct task_struct *acquired; acquired = bpf_task_acquire(task); + if (acquired) + /* + * In a typical program you'd do something like store + * the task in a map, and the map will automatically + * release it later. Here, we release it manually. + */ + bpf_task_release(acquired); + return 0; + } + + +References acquired on ``struct task_struct *`` objects are RCU protected. +Therefore, when in an RCU read region, you can obtain a pointer to a task +embedded in a map value without having to acquire a reference: + +.. code-block:: c + + #define private(name) SEC(".data." #name) __hidden __attribute__((aligned(8))) + private(TASK) static struct task_struct *global; + + /** + * A trivial example showing how to access a task stored + * in a map using RCU. + */ + SEC("tp_btf/task_newtask") + int BPF_PROG(task_rcu_read_example, struct task_struct *task, u64 clone_flags) + { + struct task_struct *local_copy; + + bpf_rcu_read_lock(); + local_copy = global; + if (local_copy) + /* + * We could also pass local_copy to kfuncs or helper functions here, + * as we're guaranteed that local_copy will be valid until we exit + * the RCU read region below. + */ + bpf_printk("Global task %s is valid", local_copy->comm); + else + bpf_printk("No global task found"); + bpf_rcu_read_unlock(); + + /* At this point we can no longer reference local_copy. */ - /* - * In a typical program you'd do something like store - * the task in a map, and the map will automatically - * release it later. Here, we release it manually. - */ - bpf_task_release(acquired); return 0; } @@ -515,80 +563,16 @@ bpf_task_release() respectively, so we won't provide examples for them. ---- -You may also acquire a reference to a ``struct cgroup`` kptr that's already -stored in a map using bpf_cgroup_kptr_get(): +Other kfuncs available for interacting with ``struct cgroup *`` objects are +bpf_cgroup_ancestor() and bpf_cgroup_from_id(), allowing callers to access +the ancestor of a cgroup and find a cgroup by its ID, respectively. Both +return a cgroup kptr. .. kernel-doc:: kernel/bpf/helpers.c - :identifiers: bpf_cgroup_kptr_get - -Here's an example of how it can be used: - -.. code-block:: c - - /* struct containing the struct task_struct kptr which is actually stored in the map. */ - struct __cgroups_kfunc_map_value { - struct cgroup __kptr_ref * cgroup; - }; - - /* The map containing struct __cgroups_kfunc_map_value entries. */ - struct { - __uint(type, BPF_MAP_TYPE_HASH); - __type(key, int); - __type(value, struct __cgroups_kfunc_map_value); - __uint(max_entries, 1); - } __cgroups_kfunc_map SEC(".maps"); - - /* ... */ - - /** - * A simple example tracepoint program showing how a - * struct cgroup kptr that is stored in a map can - * be acquired using the bpf_cgroup_kptr_get() kfunc. - */ - SEC("tp_btf/cgroup_mkdir") - int BPF_PROG(cgroup_kptr_get_example, struct cgroup *cgrp, const char *path) - { - struct cgroup *kptr; - struct __cgroups_kfunc_map_value *v; - s32 id = cgrp->self.id; - - /* Assume a cgroup kptr was previously stored in the map. */ - v = bpf_map_lookup_elem(&__cgroups_kfunc_map, &id); - if (!v) - return -ENOENT; - - /* Acquire a reference to the cgroup kptr that's already stored in the map. */ - kptr = bpf_cgroup_kptr_get(&v->cgroup); - if (!kptr) - /* If no cgroup was present in the map, it's because - * we're racing with another CPU that removed it with - * bpf_kptr_xchg() between the bpf_map_lookup_elem() - * above, and our call to bpf_cgroup_kptr_get(). - * bpf_cgroup_kptr_get() internally safely handles this - * race, and will return NULL if the task is no longer - * present in the map by the time we invoke the kfunc. - */ - return -EBUSY; - - /* Free the reference we just took above. Note that the - * original struct cgroup kptr is still in the map. It will - * be freed either at a later time if another context deletes - * it from the map, or automatically by the BPF subsystem if - * it's still present when the map is destroyed. - */ - bpf_cgroup_release(kptr); - - return 0; - } - ----- - -Another kfunc available for interacting with ``struct cgroup *`` objects is -bpf_cgroup_ancestor(). This allows callers to access the ancestor of a cgroup, -and return it as a cgroup kptr. + :identifiers: bpf_cgroup_ancestor .. kernel-doc:: kernel/bpf/helpers.c - :identifiers: bpf_cgroup_ancestor + :identifiers: bpf_cgroup_from_id Eventually, BPF should be updated to allow this to happen with a normal memory load in the program itself. This is currently not possible without more work in diff --git a/Documentation/bpf/libbpf/index.rst b/Documentation/bpf/libbpf/index.rst index f9b3b252e28f..7545a2049692 100644 --- a/Documentation/bpf/libbpf/index.rst +++ b/Documentation/bpf/libbpf/index.rst @@ -2,23 +2,32 @@ .. _libbpf: +====== libbpf ====== +If you are looking to develop BPF applications using the libbpf library, this +directory contains important documentation that you should read. + +To get started, it is recommended to begin with the :doc:`libbpf Overview +<libbpf_overview>` document, which provides a high-level understanding of the +libbpf APIs and their usage. This will give you a solid foundation to start +exploring and utilizing the various features of libbpf to develop your BPF +applications. + .. toctree:: :maxdepth: 1 + libbpf_overview API Documentation <https://libbpf.readthedocs.io/en/latest/api.html> program_types libbpf_naming_convention libbpf_build -This is documentation for libbpf, a userspace library for loading and -interacting with bpf programs. -All general BPF questions, including kernel functionality, libbpf APIs and -their application, should be sent to bpf@vger.kernel.org mailing list. -You can `subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the -mailing list search its `archive <https://lore.kernel.org/bpf/>`_. -Please search the archive before asking new questions. It very well might -be that this was already addressed or answered before. +All general BPF questions, including kernel functionality, libbpf APIs and their +application, should be sent to bpf@vger.kernel.org mailing list. You can +`subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the mailing list +search its `archive <https://lore.kernel.org/bpf/>`_. Please search the archive +before asking new questions. It may be that this was already addressed or +answered before. diff --git a/Documentation/bpf/libbpf/libbpf_overview.rst b/Documentation/bpf/libbpf/libbpf_overview.rst new file mode 100644 index 000000000000..f36a2d4ffea2 --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf_overview.rst @@ -0,0 +1,228 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +libbpf Overview +=============== + +libbpf is a C-based library containing a BPF loader that takes compiled BPF +object files and prepares and loads them into the Linux kernel. libbpf takes the +heavy lifting of loading, verifying, and attaching BPF programs to various +kernel hooks, allowing BPF application developers to focus only on BPF program +correctness and performance. + +The following are the high-level features supported by libbpf: + +* Provides high-level and low-level APIs for user space programs to interact + with BPF programs. The low-level APIs wrap all the bpf system call + functionality, which is useful when users need more fine-grained control + over the interactions between user space and BPF programs. +* Provides overall support for the BPF object skeleton generated by bpftool. + The skeleton file simplifies the process for the user space programs to access + global variables and work with BPF programs. +* Provides BPF-side APIS, including BPF helper definitions, BPF maps support, + and tracing helpers, allowing developers to simplify BPF code writing. +* Supports BPF CO-RE mechanism, enabling BPF developers to write portable + BPF programs that can be compiled once and run across different kernel + versions. + +This document will delve into the above concepts in detail, providing a deeper +understanding of the capabilities and advantages of libbpf and how it can help +you develop BPF applications efficiently. + +BPF App Lifecycle and libbpf APIs +================================== + +A BPF application consists of one or more BPF programs (either cooperating or +completely independent), BPF maps, and global variables. The global +variables are shared between all BPF programs, which allows them to cooperate on +a common set of data. libbpf provides APIs that user space programs can use to +manipulate the BPF programs by triggering different phases of a BPF application +lifecycle. + +The following section provides a brief overview of each phase in the BPF life +cycle: + +* **Open phase**: In this phase, libbpf parses the BPF + object file and discovers BPF maps, BPF programs, and global variables. After + a BPF app is opened, user space apps can make additional adjustments + (setting BPF program types, if necessary; pre-setting initial values for + global variables, etc.) before all the entities are created and loaded. + +* **Load phase**: In the load phase, libbpf creates BPF + maps, resolves various relocations, and verifies and loads BPF programs into + the kernel. At this point, libbpf validates all the parts of a BPF application + and loads the BPF program into the kernel, but no BPF program has yet been + executed. After the load phase, it’s possible to set up the initial BPF map + state without racing with the BPF program code execution. + +* **Attachment phase**: In this phase, libbpf + attaches BPF programs to various BPF hook points (e.g., tracepoints, kprobes, + cgroup hooks, network packet processing pipeline, etc.). During this + phase, BPF programs perform useful work such as processing + packets, or updating BPF maps and global variables that can be read from user + space. + +* **Tear down phase**: In the tear down phase, + libbpf detaches BPF programs and unloads them from the kernel. BPF maps are + destroyed, and all the resources used by the BPF app are freed. + +BPF Object Skeleton File +======================== + +BPF skeleton is an alternative interface to libbpf APIs for working with BPF +objects. Skeleton code abstract away generic libbpf APIs to significantly +simplify code for manipulating BPF programs from user space. Skeleton code +includes a bytecode representation of the BPF object file, simplifying the +process of distributing your BPF code. With BPF bytecode embedded, there are no +extra files to deploy along with your application binary. + +You can generate the skeleton header file ``(.skel.h)`` for a specific object +file by passing the BPF object to the bpftool. The generated BPF skeleton +provides the following custom functions that correspond to the BPF lifecycle, +each of them prefixed with the specific object name: + +* ``<name>__open()`` – creates and opens BPF application (``<name>`` stands for + the specific bpf object name) +* ``<name>__load()`` – instantiates, loads,and verifies BPF application parts +* ``<name>__attach()`` – attaches all auto-attachable BPF programs (it’s + optional, you can have more control by using libbpf APIs directly) +* ``<name>__destroy()`` – detaches all BPF programs and + frees up all used resources + +Using the skeleton code is the recommended way to work with bpf programs. Keep +in mind, BPF skeleton provides access to the underlying BPF object, so whatever +was possible to do with generic libbpf APIs is still possible even when the BPF +skeleton is used. It's an additive convenience feature, with no syscalls, and no +cumbersome code. + +Other Advantages of Using Skeleton File +--------------------------------------- + +* BPF skeleton provides an interface for user space programs to work with BPF + global variables. The skeleton code memory maps global variables as a struct + into user space. The struct interface allows user space programs to initialize + BPF programs before the BPF load phase and fetch and update data from user + space afterward. + +* The ``skel.h`` file reflects the object file structure by listing out the + available maps, programs, etc. BPF skeleton provides direct access to all the + BPF maps and BPF programs as struct fields. This eliminates the need for + string-based lookups with ``bpf_object_find_map_by_name()`` and + ``bpf_object_find_program_by_name()`` APIs, reducing errors due to BPF source + code and user-space code getting out of sync. + +* The embedded bytecode representation of the object file ensures that the + skeleton and the BPF object file are always in sync. + +BPF Helpers +=========== + +libbpf provides BPF-side APIs that BPF programs can use to interact with the +system. The BPF helpers definition allows developers to use them in BPF code as +any other plain C function. For example, there are helper functions to print +debugging messages, get the time since the system was booted, interact with BPF +maps, manipulate network packets, etc. + +For a complete description of what the helpers do, the arguments they take, and +the return value, see the `bpf-helpers +<https://man7.org/linux/man-pages/man7/bpf-helpers.7.html>`_ man page. + +BPF CO-RE (Compile Once – Run Everywhere) +========================================= + +BPF programs work in the kernel space and have access to kernel memory and data +structures. One limitation that BPF applications come across is the lack of +portability across different kernel versions and configurations. `BCC +<https://github.com/iovisor/bcc/>`_ is one of the solutions for BPF +portability. However, it comes with runtime overhead and a large binary size +from embedding the compiler with the application. + +libbpf steps up the BPF program portability by supporting the BPF CO-RE concept. +BPF CO-RE brings together BTF type information, libbpf, and the compiler to +produce a single executable binary that you can run on multiple kernel versions +and configurations. + +To make BPF programs portable libbpf relies on the BTF type information of the +running kernel. Kernel also exposes this self-describing authoritative BTF +information through ``sysfs`` at ``/sys/kernel/btf/vmlinux``. + +You can generate the BTF information for the running kernel with the following +command: + +:: + + $ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h + +The command generates a ``vmlinux.h`` header file with all kernel types +(:doc:`BTF types <../btf>`) that the running kernel uses. Including +``vmlinux.h`` in your BPF program eliminates dependency on system-wide kernel +headers. + +libbpf enables portability of BPF programs by looking at the BPF program’s +recorded BTF type and relocation information and matching them to BTF +information (vmlinux) provided by the running kernel. libbpf then resolves and +matches all the types and fields, and updates necessary offsets and other +relocatable data to ensure that BPF program’s logic functions correctly for a +specific kernel on the host. BPF CO-RE concept thus eliminates overhead +associated with BPF development and allows developers to write portable BPF +applications without modifications and runtime source code compilation on the +target machine. + +The following code snippet shows how to read the parent field of a kernel +``task_struct`` using BPF CO-RE and libbf. The basic helper to read a field in a +CO-RE relocatable manner is ``bpf_core_read(dst, sz, src)``, which will read +``sz`` bytes from the field referenced by ``src`` into the memory pointed to by +``dst``. + +.. code-block:: C + :emphasize-lines: 6 + + //... + struct task_struct *task = (void *)bpf_get_current_task(); + struct task_struct *parent_task; + int err; + + err = bpf_core_read(&parent_task, sizeof(void *), &task->parent); + if (err) { + /* handle error */ + } + + /* parent_task contains the value of task->parent pointer */ + +In the code snippet, we first get a pointer to the current ``task_struct`` using +``bpf_get_current_task()``. We then use ``bpf_core_read()`` to read the parent +field of task struct into the ``parent_task`` variable. ``bpf_core_read()`` is +just like ``bpf_probe_read_kernel()`` BPF helper, except it records information +about the field that should be relocated on the target kernel. i.e, if the +``parent`` field gets shifted to a different offset within +``struct task_struct`` due to some new field added in front of it, libbpf will +automatically adjust the actual offset to the proper value. + +Getting Started with libbpf +=========================== + +Check out the `libbpf-bootstrap <https://github.com/libbpf/libbpf-bootstrap>`_ +repository with simple examples of using libbpf to build various BPF +applications. + +See also `libbpf API documentation +<https://libbpf.readthedocs.io/en/latest/api.html>`_. + +libbpf and Rust +=============== + +If you are building BPF applications in Rust, it is recommended to use the +`Libbpf-rs <https://github.com/libbpf/libbpf-rs>`_ library instead of bindgen +bindings directly to libbpf. Libbpf-rs wraps libbpf functionality in +Rust-idiomatic interfaces and provides libbpf-cargo plugin to handle BPF code +compilation and skeleton generation. Using Libbpf-rs will make building user +space part of the BPF application easier. Note that the BPF program themselves +must still be written in plain C. + +Additional Documentation +======================== + +* `Program types and ELF Sections <https://libbpf.readthedocs.io/en/latest/program_types.html>`_ +* `API naming convention <https://libbpf.readthedocs.io/en/latest/libbpf_naming_convention.html>`_ +* `Building libbpf <https://libbpf.readthedocs.io/en/latest/libbpf_build.html>`_ +* `API documentation Convention <https://libbpf.readthedocs.io/en/latest/libbpf_naming_convention.html#api-documentation-convention>`_ diff --git a/Documentation/bpf/linux-notes.rst b/Documentation/bpf/linux-notes.rst index 956b0c86699d..508d009d3bed 100644 --- a/Documentation/bpf/linux-notes.rst +++ b/Documentation/bpf/linux-notes.rst @@ -12,6 +12,36 @@ Byte swap instructions ``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and ``BPF_TO_BE`` respectively. +Jump instructions +================= + +``BPF_CALL | BPF_X | BPF_JMP`` (0x8d), where the helper function +integer would be read from a specified register, is not currently supported +by the verifier. Any programs with this instruction will fail to load +until such support is added. + +Maps +==== + +Linux only supports the 'map_val(map)' operation on array maps with a single element. + +Linux uses an fd_array to store maps associated with a BPF program. Thus, +map_by_idx(imm) uses the fd at that index in the array. + +Variables +========= + +The following 64-bit immediate instruction specifies that a variable address, +which corresponds to some integer stored in the 'imm' field, should be loaded: + +========================= ====== === ========================================= =========== ============== +opcode construction opcode src pseudocode imm type dst type +========================= ====== === ========================================= =========== ============== +BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer +========================= ====== === ========================================= =========== ============== + +On Linux, this integer is a BTF ID. + Legacy BPF Packet access instructions ===================================== diff --git a/Documentation/bpf/maps.rst b/Documentation/bpf/maps.rst index 4906ff0f8382..6f069f3d6f4b 100644 --- a/Documentation/bpf/maps.rst +++ b/Documentation/bpf/maps.rst @@ -11,9 +11,9 @@ maps are accessed from BPF programs via BPF helpers which are documented in the `man-pages`_ for `bpf-helpers(7)`_. BPF maps are accessed from user space via the ``bpf`` syscall, which provides -commands to create maps, lookup elements, update elements and delete -elements. More details of the BPF syscall are available in -:doc:`/userspace-api/ebpf/syscall` and in the `man-pages`_ for `bpf(2)`_. +commands to create maps, lookup elements, update elements and delete elements. +More details of the BPF syscall are available in `ebpf-syscall`_ and in the +`man-pages`_ for `bpf(2)`_. Map Types ========= @@ -79,3 +79,4 @@ Find and delete element by key in a given map using ``attr->map_fd``, .. _man-pages: https://www.kernel.org/doc/man-pages/ .. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html .. _bpf-helpers(7): https://man7.org/linux/man-pages/man7/bpf-helpers.7.html +.. _ebpf-syscall: https://docs.kernel.org/userspace-api/ebpf/syscall.html diff --git a/Documentation/bpf/prog_lsm.rst b/Documentation/bpf/prog_lsm.rst index 0dc3fb0d9544..ad2be02f30c2 100644 --- a/Documentation/bpf/prog_lsm.rst +++ b/Documentation/bpf/prog_lsm.rst @@ -18,7 +18,7 @@ LSM hook: .. c:function:: int file_mprotect(struct vm_area_struct *vma, unsigned long reqprot, unsigned long prot); Other LSM hooks which can be instrumented can be found in -``include/linux/lsm_hooks.h``. +``security/security.c``. eBPF programs that use Documentation/bpf/btf.rst do not need to include kernel headers for accessing information from the attached eBPF program's context. diff --git a/Documentation/conf.py b/Documentation/conf.py index db16814f182f..37314afd1ac8 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -343,9 +343,10 @@ sys.stderr.write("Using %s theme\n" % html_theme) # so a file named "default.css" will overwrite the builtin "default.css". html_static_path = ['sphinx-static'] -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -html_use_smartypants = False +# If true, Docutils "smart quotes" will be used to convert quotes and dashes +# to typographically correct entities. This will convert "--" to "—", +# which is not always what we want, so disable it. +smartquotes = False # Custom sidebar templates, maps document names to template names. # Note that the RTD theme ignores this diff --git a/Documentation/core-api/asm-annotations.rst b/Documentation/core-api/asm-annotations.rst index bc514ed59887..11c96d3f9ad6 100644 --- a/Documentation/core-api/asm-annotations.rst +++ b/Documentation/core-api/asm-annotations.rst @@ -44,7 +44,7 @@ information. In particular, on properly annotated objects, ``objtool`` can be run to check and fix the object if needed. Currently, ``objtool`` can report missing frame pointer setup/destruction in functions. It can also automatically generate annotations for the ORC unwinder -(Documentation/x86/orc-unwinder.rst) +(Documentation/arch/x86/orc-unwinder.rst) for most code. Both of these are especially important to support reliable stack traces which are in turn necessary for kernel live patching (Documentation/livepatch/livepatch.rst). diff --git a/Documentation/core-api/dma-api-howto.rst b/Documentation/core-api/dma-api-howto.rst index 828846804e25..72f6cdb6be1c 100644 --- a/Documentation/core-api/dma-api-howto.rst +++ b/Documentation/core-api/dma-api-howto.rst @@ -185,7 +185,7 @@ device struct of your device is embedded in the bus-specific device struct of your device. For example, &pdev->dev is a pointer to the device struct of a PCI device (pdev is a pointer to the PCI device struct of your device). -These calls usually return zero to indicated your device can perform DMA +These calls usually return zero to indicate your device can perform DMA properly on the machine given the address mask you provided, but they might return an error if the mask is too small to be supportable on the given system. If it returns non-zero, your device cannot perform DMA properly on diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 62f961610773..9b3f3e5f5a95 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -220,12 +220,30 @@ relay interface Module Support ============== -Module Loading --------------- +Kernel module auto-loading +-------------------------- -.. kernel-doc:: kernel/kmod.c +.. kernel-doc:: kernel/module/kmod.c :export: +Module debugging +---------------- + +.. kernel-doc:: kernel/module/stats.c + :doc: module debugging statistics overview + +dup_failed_modules - tracks duplicate failed modules +**************************************************** + +.. kernel-doc:: kernel/module/stats.c + :doc: dup_failed_modules - tracks duplicate failed modules + +module statistics debugfs counters +********************************** + +.. kernel-doc:: kernel/module/stats.c + :doc: module statistics debugfs counters + Inter Module support -------------------- diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst index 5954ddf6ee13..1c58d883b273 100644 --- a/Documentation/core-api/memory-allocation.rst +++ b/Documentation/core-api/memory-allocation.rst @@ -170,7 +170,16 @@ should be used if a part of the cache might be copied to the userspace. After the cache is created kmem_cache_alloc() and its convenience wrappers can allocate memory from that cache. -When the allocated memory is no longer needed it must be freed. You can -use kvfree() for the memory allocated with `kmalloc`, `vmalloc` and -`kvmalloc`. The slab caches should be freed with kmem_cache_free(). And -don't forget to destroy the cache with kmem_cache_destroy(). +When the allocated memory is no longer needed it must be freed. + +Objects allocated by `kmalloc` can be freed by `kfree` or `kvfree`. Objects +allocated by `kmem_cache_alloc` can be freed with `kmem_cache_free`, `kfree` +or `kvfree`, where the latter two might be more convenient thanks to not +needing the kmem_cache pointer. + +The same rules apply to _bulk and _rcu flavors of freeing functions. + +Memory allocated by `vmalloc` can be freed with `vfree` or `kvfree`. +Memory allocated by `kvmalloc` can be freed with `kvfree`. +Caches created by `kmem_cache_create` should be freed with +`kmem_cache_destroy` only after freeing all the allocated objects first. diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index dbe1aacc79d0..dfe7e75a71de 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -575,20 +575,26 @@ The field width is passed by value, the bitmap is passed by reference. Helper macros cpumask_pr_args() and nodemask_pr_args() are available to ease printing cpumask and nodemask. -Flags bitfields such as page flags, gfp_flags ---------------------------------------------- +Flags bitfields such as page flags, page_type, gfp_flags +-------------------------------------------------------- :: %pGp 0x17ffffc0002036(referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff) + %pGt 0xffffff7f(buddy) %pGg GFP_USER|GFP_DMA32|GFP_NOWARN %pGv read|exec|mayread|maywrite|mayexec|denywrite For printing flags bitfields as a collection of symbolic constants that would construct the value. The type of flags is given by the third -character. Currently supported are [p]age flags, [v]ma_flags (both -expect ``unsigned long *``) and [g]fp_flags (expects ``gfp_t *``). The flag -names and print order depends on the particular type. +character. Currently supported are: + + - p - [p]age flags, expects value of type (``unsigned long *``) + - t - page [t]ype, expects value of type (``unsigned int *``) + - v - [v]ma_flags, expects value of type (``unsigned long *``) + - g - [g]fp_flags, expects value of type (``gfp_t *``) + +The flag names and print order depends on the particular type. Note that this format should not be used directly in the :c:func:`TP_printk()` part of a tracepoint. Instead, use the show_*_flags() diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst index d83c9ab49427..6611434e2dd2 100644 --- a/Documentation/dev-tools/kcov.rst +++ b/Documentation/dev-tools/kcov.rst @@ -1,42 +1,50 @@ -kcov: code coverage for fuzzing +KCOV: code coverage for fuzzing =============================== -kcov exposes kernel code coverage information in a form suitable for coverage- -guided fuzzing (randomized testing). Coverage data of a running kernel is -exported via the "kcov" debugfs file. Coverage collection is enabled on a task -basis, and thus it can capture precise coverage of a single system call. +KCOV collects and exposes kernel code coverage information in a form suitable +for coverage-guided fuzzing. Coverage data of a running kernel is exported via +the ``kcov`` debugfs file. Coverage collection is enabled on a task basis, and +thus KCOV can capture precise coverage of a single system call. -Note that kcov does not aim to collect as much coverage as possible. It aims -to collect more or less stable coverage that is function of syscall inputs. -To achieve this goal it does not collect coverage in soft/hard interrupts -and instrumentation of some inherently non-deterministic parts of kernel is -disabled (e.g. scheduler, locking). +Note that KCOV does not aim to collect as much coverage as possible. It aims +to collect more or less stable coverage that is a function of syscall inputs. +To achieve this goal, it does not collect coverage in soft/hard interrupts +(unless remove coverage collection is enabled, see below) and from some +inherently non-deterministic parts of the kernel (e.g. scheduler, locking). -kcov is also able to collect comparison operands from the instrumented code -(this feature currently requires that the kernel is compiled with clang). +Besides collecting code coverage, KCOV can also collect comparison operands. +See the "Comparison operands collection" section for details. + +Besides collecting coverage data from syscall handlers, KCOV can also collect +coverage for annotated parts of the kernel executing in background kernel +tasks or soft interrupts. See the "Remote coverage collection" section for +details. Prerequisites ------------- -Configure the kernel with:: +KCOV relies on compiler instrumentation and requires GCC 6.1.0 or later +or any Clang version supported by the kernel. - CONFIG_KCOV=y +Collecting comparison operands is supported with GCC 8+ or with Clang. -CONFIG_KCOV requires gcc 6.1.0 or later. +To enable KCOV, configure the kernel with:: -If the comparison operands need to be collected, set:: + CONFIG_KCOV=y + +To enable comparison operands collection, set:: CONFIG_KCOV_ENABLE_COMPARISONS=y -Profiling data will only become accessible once debugfs has been mounted:: +Coverage data only becomes accessible once debugfs has been mounted:: mount -t debugfs none /sys/kernel/debug Coverage collection ------------------- -The following program demonstrates coverage collection from within a test -program using kcov: +The following program demonstrates how to use KCOV to collect coverage for a +single syscall from within a test program: .. code-block:: c @@ -84,7 +92,7 @@ program using kcov: perror("ioctl"), exit(1); /* Reset coverage from the tail of the ioctl() call. */ __atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED); - /* That's the target syscal call. */ + /* Call the target syscall call. */ read(-1, NULL, 0); /* Read number of PCs collected. */ n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED); @@ -103,7 +111,7 @@ program using kcov: return 0; } -After piping through addr2line output of the program looks as follows:: +After piping through ``addr2line`` the output of the program looks as follows:: SyS_read fs/read_write.c:562 @@ -121,12 +129,13 @@ After piping through addr2line output of the program looks as follows:: fs/read_write.c:562 If a program needs to collect coverage from several threads (independently), -it needs to open /sys/kernel/debug/kcov in each thread separately. +it needs to open ``/sys/kernel/debug/kcov`` in each thread separately. The interface is fine-grained to allow efficient forking of test processes. -That is, a parent process opens /sys/kernel/debug/kcov, enables trace mode, -mmaps coverage buffer and then forks child processes in a loop. Child processes -only need to enable coverage (disable happens automatically on thread end). +That is, a parent process opens ``/sys/kernel/debug/kcov``, enables trace mode, +mmaps coverage buffer, and then forks child processes in a loop. The child +processes only need to enable coverage (it gets disabled automatically when +a thread exits). Comparison operands collection ------------------------------ @@ -205,52 +214,78 @@ Comparison operands collection is similar to coverage collection: return 0; } -Note that the kcov modes (coverage collection or comparison operands) are -mutually exclusive. +Note that the KCOV modes (collection of code coverage or comparison operands) +are mutually exclusive. Remote coverage collection -------------------------- -With KCOV_ENABLE coverage is collected only for syscalls that are issued -from the current process. With KCOV_REMOTE_ENABLE it's possible to collect -coverage for arbitrary parts of the kernel code, provided that those parts -are annotated with kcov_remote_start()/kcov_remote_stop(). - -This allows to collect coverage from two types of kernel background -threads: the global ones, that are spawned during kernel boot in a limited -number of instances (e.g. one USB hub_event() worker thread is spawned per -USB HCD); and the local ones, that are spawned when a user interacts with -some kernel interface (e.g. vhost workers); as well as from soft -interrupts. - -To enable collecting coverage from a global background thread or from a -softirq, a unique global handle must be assigned and passed to the -corresponding kcov_remote_start() call. Then a userspace process can pass -a list of such handles to the KCOV_REMOTE_ENABLE ioctl in the handles -array field of the kcov_remote_arg struct. This will attach the used kcov -device to the code sections, that are referenced by those handles. - -Since there might be many local background threads spawned from different -userspace processes, we can't use a single global handle per annotation. -Instead, the userspace process passes a non-zero handle through the -common_handle field of the kcov_remote_arg struct. This common handle gets -saved to the kcov_handle field in the current task_struct and needs to be -passed to the newly spawned threads via custom annotations. Those threads -should in turn be annotated with kcov_remote_start()/kcov_remote_stop(). - -Internally kcov stores handles as u64 integers. The top byte of a handle -is used to denote the id of a subsystem that this handle belongs to, and -the lower 4 bytes are used to denote the id of a thread instance within -that subsystem. A reserved value 0 is used as a subsystem id for common -handles as they don't belong to a particular subsystem. The bytes 4-7 are -currently reserved and must be zero. In the future the number of bytes -used for the subsystem or handle ids might be increased. - -When a particular userspace process collects coverage via a common -handle, kcov will collect coverage for each code section that is annotated -to use the common handle obtained as kcov_handle from the current -task_struct. However non common handles allow to collect coverage -selectively from different subsystems. +Besides collecting coverage data from handlers of syscalls issued from a +userspace process, KCOV can also collect coverage for parts of the kernel +executing in other contexts - so-called "remote" coverage. + +Using KCOV to collect remote coverage requires: + +1. Modifying kernel code to annotate the code section from where coverage + should be collected with ``kcov_remote_start`` and ``kcov_remote_stop``. + +2. Using ``KCOV_REMOTE_ENABLE`` instead of ``KCOV_ENABLE`` in the userspace + process that collects coverage. + +Both ``kcov_remote_start`` and ``kcov_remote_stop`` annotations and the +``KCOV_REMOTE_ENABLE`` ioctl accept handles that identify particular coverage +collection sections. The way a handle is used depends on the context where the +matching code section executes. + +KCOV supports collecting remote coverage from the following contexts: + +1. Global kernel background tasks. These are the tasks that are spawned during + kernel boot in a limited number of instances (e.g. one USB ``hub_event`` + worker is spawned per one USB HCD). + +2. Local kernel background tasks. These are spawned when a userspace process + interacts with some kernel interface and are usually killed when the process + exits (e.g. vhost workers). + +3. Soft interrupts. + +For #1 and #3, a unique global handle must be chosen and passed to the +corresponding ``kcov_remote_start`` call. Then a userspace process must pass +this handle to ``KCOV_REMOTE_ENABLE`` in the ``handles`` array field of the +``kcov_remote_arg`` struct. This will attach the used KCOV device to the code +section referenced by this handle. Multiple global handles identifying +different code sections can be passed at once. + +For #2, the userspace process instead must pass a non-zero handle through the +``common_handle`` field of the ``kcov_remote_arg`` struct. This common handle +gets saved to the ``kcov_handle`` field in the current ``task_struct`` and +needs to be passed to the newly spawned local tasks via custom kernel code +modifications. Those tasks should in turn use the passed handle in their +``kcov_remote_start`` and ``kcov_remote_stop`` annotations. + +KCOV follows a predefined format for both global and common handles. Each +handle is a ``u64`` integer. Currently, only the one top and the lower 4 bytes +are used. Bytes 4-7 are reserved and must be zero. + +For global handles, the top byte of the handle denotes the id of a subsystem +this handle belongs to. For example, KCOV uses ``1`` as the USB subsystem id. +The lower 4 bytes of a global handle denote the id of a task instance within +that subsystem. For example, each ``hub_event`` worker uses the USB bus number +as the task instance id. + +For common handles, a reserved value ``0`` is used as a subsystem id, as such +handles don't belong to a particular subsystem. The lower 4 bytes of a common +handle identify a collective instance of all local tasks spawned by the +userspace process that passed a common handle to ``KCOV_REMOTE_ENABLE``. + +In practice, any value can be used for common handle instance id if coverage +is only collected from a single userspace process on the system. However, if +common handles are used by multiple processes, unique instance ids must be +used for each process. One option is to use the process id as the common +handle instance id. + +The following program demonstrates using KCOV to collect coverage from both +local tasks spawned by the process and the global task that handles USB bus #1: .. code-block:: c diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst index 5483fd39ef29..2cb00b53339f 100644 --- a/Documentation/dev-tools/kmemleak.rst +++ b/Documentation/dev-tools/kmemleak.rst @@ -227,7 +227,7 @@ Testing with kmemleak-test -------------------------- To check if you have all set up to use kmemleak, you can use the kmemleak-test -module, a module that deliberately leaks memory. Set CONFIG_DEBUG_KMEMLEAK_TEST +module, a module that deliberately leaks memory. Set CONFIG_SAMPLE_KMEMLEAK as module (it can't be used as built-in) and boot the kernel with kmemleak enabled. Load the module and perform a scan with:: diff --git a/Documentation/devicetree/bindings/.yamllint b/Documentation/devicetree/bindings/.yamllint index 214abd3ec440..4abe9f0a1d46 100644 --- a/Documentation/devicetree/bindings/.yamllint +++ b/Documentation/devicetree/bindings/.yamllint @@ -19,7 +19,7 @@ rules: colons: {max-spaces-before: 0, max-spaces-after: 1} commas: {min-spaces-after: 1, max-spaces-after: 1} comments: - require-starting-space: false + require-starting-space: true min-spaces-from-content: 1 comments-indentation: disable document-start: diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index b634d5b04e15..274ee0890312 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -153,17 +153,27 @@ properties: - description: Boards with the Amlogic Meson G12B A311D SoC items: - enum: + - bananapi,bpi-m2s - khadas,vim3 - radxa,zero2 - const: amlogic,a311d - const: amlogic,g12b + - description: Boards using the BPI-CM4 module with Amlogic Meson G12B A311D SoC + items: + - enum: + - bananapi,bpi-cm4io + - const: bananapi,bpi-cm4 + - const: amlogic,a311d + - const: amlogic,g12b + - description: Boards with the Amlogic Meson G12B S922X SoC items: - enum: - azw,gsking-x - azw,gtking - azw,gtking-pro + - bananapi,bpi-m2s - hardkernel,odroid-go-ultra - hardkernel,odroid-n2 - hardkernel,odroid-n2l diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml index 1748f1605cc7..7dff32f373cb 100644 --- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson Firmware registers Interface diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml index eee7cda9f91b..09b27e98d4c9 100644 --- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-mx-secbus2.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/amlogic/amlogic,meson-mx-secbus2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson8/Meson8b/Meson8m2 SECBUS2 register interface diff --git a/Documentation/devicetree/bindings/arm/apple.yaml b/Documentation/devicetree/bindings/arm/apple.yaml index da78c69774f2..883fd67e3752 100644 --- a/Documentation/devicetree/bindings/arm/apple.yaml +++ b/Documentation/devicetree/bindings/arm/apple.yaml @@ -19,6 +19,12 @@ description: | - MacBook Air (M1, 2020) - iMac (24-inch, M1, 2021) + Devices based on the "M2" SoC: + + - MacBook Air (M2, 2022) + - MacBook Pro (13-inch, M2, 2022) + - Mac mini (M2, 2023) + And devices based on the "M1 Pro", "M1 Max" and "M1 Ultra" SoCs: - MacBook Pro (14-inch, M1 Pro, 2021) @@ -70,6 +76,15 @@ properties: - const: apple,t8103 - const: apple,arm-platform + - description: Apple M2 SoC based platforms + items: + - enum: + - apple,j413 # MacBook Air (M2, 2022) + - apple,j473 # Mac mini (M2, 2023) + - apple,j493 # MacBook Pro (13-inch, M2, 2022) + - const: apple,t8112 + - const: apple,arm-platform + - description: Apple M1 Pro 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 0dc957a56d35..673277a7a224 100644 --- a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml +++ b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml @@ -23,6 +23,7 @@ properties: items: - enum: - apple,t8103-pmgr + - apple,t8112-pmgr - apple,t6000-pmgr - const: apple,pmgr - const: syscon diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml index eec190a96225..09c319f803ba 100644 --- a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml +++ b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml @@ -144,6 +144,7 @@ patternProperties: it is stricter and always has two compatibles. type: object $ref: '/schemas/simple-bus.yaml' + unevaluatedProperties: false properties: compatible: diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml index b369b374fc4a..39e3c248f5b7 100644 --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml @@ -30,6 +30,7 @@ properties: clocks: type: object + additionalProperties: false properties: compatible: @@ -47,6 +48,7 @@ properties: reset: type: object + additionalProperties: false properties: compatible: @@ -63,6 +65,7 @@ properties: pwm: type: object + additionalProperties: false properties: compatible: @@ -76,8 +79,6 @@ properties: - compatible - "#pwm-cells" - additionalProperties: false - required: - compatible - mboxes diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index c145f6a035ee..ff272e517d57 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -85,6 +85,8 @@ properties: compatible: enum: + - apple,avalanche + - apple,blizzard - apple,icestorm - apple,firestorm - arm,arm710t @@ -139,6 +141,7 @@ properties: - arm,cortex-a77 - arm,cortex-a78 - arm,cortex-a78ae + - arm,cortex-a78c - arm,cortex-a510 - arm,cortex-a710 - arm,cortex-a715 @@ -151,6 +154,7 @@ properties: - arm,cortex-r5 - arm,cortex-r7 - arm,cortex-x1 + - arm,cortex-x1c - arm,cortex-x2 - arm,cortex-x3 - arm,neoverse-e1 diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml index d4dc0749f9fd..5d033570b57b 100644 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -28,7 +28,8 @@ properties: maxItems: 1 description: | This interrupt which is used to signal an event by the secure world - software is expected to be edge-triggered. + software is expected to be either a per-cpu interrupt or an + edge-triggered peripheral interrupt. method: enum: [smc, hvc] diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 442ce8f4d675..15d411084065 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -300,6 +300,7 @@ properties: - variscite,dt6customboard - wand,imx6q-wandboard # Wandboard i.MX6 Quad Board - ysoft,imx6q-yapp4-crux # i.MX6 Quad Y Soft IOTA Crux board + - ysoft,imx6q-yapp4-pegasus # i.MX6 Quad Y Soft IOTA Pegasus board - zealz,imx6q-gk802 # Zealz GK802 - zii,imx6q-zii-rdu2 # ZII RDU2 Board - const: fsl,imx6q @@ -410,6 +411,7 @@ properties: - prt,prtwd3 # Protonic WD3 board - wand,imx6qp-wandboard # Wandboard i.MX6 QuadPlus Board - ysoft,imx6qp-yapp4-crux-plus # i.MX6 Quad Plus Y Soft IOTA Crux+ board + - ysoft,imx6qp-yapp4-pegasus-plus # i.MX6 Quad Plus Y Soft IOTA Pegasus+ board - zii,imx6qp-zii-rdu2 # ZII RDU2+ Board - const: fsl,imx6qp @@ -474,9 +476,11 @@ properties: - 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 - - ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board + - ysoft,imx6dl-yapp4-draco # i.MX6 Solo Y Soft IOTA Draco board - ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board + - ysoft,imx6dl-yapp4-lynx # i.MX6 DualLite Y Soft IOTA Lynx board - ysoft,imx6dl-yapp4-orion # i.MX6 DualLite Y Soft IOTA Orion board + - ysoft,imx6dl-yapp4-phoenix # i.MX6 DualLite Y Soft IOTA Phoenix board - ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board - const: fsl,imx6dl @@ -581,6 +585,7 @@ properties: - kobo,aura2 - kobo,tolino-shine2hd - kobo,tolino-shine3 + - kobo,tolino-vision - kobo,tolino-vision5 - revotics,imx6sl-warp # Revotics WaRP Board - const: fsl,imx6sl @@ -702,6 +707,15 @@ properties: - const: armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM - const: fsl,imx6ull + - description: i.MX6ULL chargebyte Tarragon Boards + items: + - enum: + - chargebyte,imx6ull-tarragon-master + - chargebyte,imx6ull-tarragon-micro + - chargebyte,imx6ull-tarragon-slave + - chargebyte,imx6ull-tarragon-slavext + - const: fsl,imx6ull + - description: i.MX6ULL DHCOM SoM based Boards items: - enum: @@ -1002,6 +1016,7 @@ properties: items: - enum: - beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit + - dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC - fsl,imx8mp-evk # i.MX8MP EVK Board - gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board - polyhex,imx8mp-debix # Polyhex Debix boards @@ -1020,7 +1035,9 @@ properties: - description: i.MX8MP DHCOM based Boards items: - - const: dh,imx8mp-dhcom-pdk2 # i.MX8MP DHCOM SoM on PDK2 board + - enum: + - dh,imx8mp-dhcom-pdk2 # i.MX8MP DHCOM SoM on PDK2 board + - dh,imx8mp-dhcom-pdk3 # i.MX8MP DHCOM SoM on PDK3 board - const: dh,imx8mp-dhcom-som # i.MX8MP DHCOM SoM - const: fsl,imx8mp @@ -1119,6 +1136,25 @@ properties: items: - enum: - fsl,imx8qm-mek # i.MX8QM MEK 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 + items: + - enum: + - toradex,apalis-imx8-eval # Apalis iMX8 Module on Apalis Evaluation Board + - toradex,apalis-imx8-ixora-v1.1 # Apalis iMX8 Module on Ixora V1.1 Carrier Board + - const: toradex,apalis-imx8 + - const: fsl,imx8qm + + - description: i.MX8QM Boards with Toradex Apalis iMX8 V1.1 Modules + items: + - enum: + - toradex,apalis-imx8-v1.1-eval # Apalis iMX8 V1.1 Module on Apalis Eval. Board + - toradex,apalis-imx8-v1.1-ixora-v1.1 # Apalis iMX8 V1.1 Module on Ixora V1.1 C. Board + - toradex,apalis-imx8-v1.1-ixora-v1.2 # Apalis iMX8 V1.1 Module on Ixora V1.2 C. Board + - const: toradex,apalis-imx8-v1.1 - const: fsl,imx8qm - description: i.MX8QXP based Boards @@ -1135,10 +1171,13 @@ properties: - fsl,imx8dxl-evk # i.MX8DXL EVK Board - const: fsl,imx8dxl - - description: i.MX8QXP Boards with Toradex Coilbri iMX8X Modules + - description: i.MX8QXP Boards with Toradex Colibri iMX8X Modules items: - enum: + - toradex,colibri-imx8x-aster # Colibri iMX8X Module on Aster Board - toradex,colibri-imx8x-eval-v3 # Colibri iMX8X Module on Colibri Evaluation Board V3 + - toradex,colibri-imx8x-iris # Colibri iMX8X Module on Iris Board + - toradex,colibri-imx8x-iris-v2 # Colibri iMX8X Module on Iris Board V2 - const: toradex,colibri-imx8x - const: fsl,imx8qxp diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml index e997635e4fe4..ea98043c6ba3 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek Infrastructure System Configuration Controller diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index d1410345ef18..536f5a5ebd24 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek mmsys controller diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml index 9fbeb626ab23..d89848a8f478 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek PCIE Mirror Controller for MT7622 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml index 5c223cb063d4..28ded09d72e3 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-wed.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-wed.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek Wireless Ethernet Dispatch Controller for MT7622 @@ -20,6 +20,7 @@ properties: items: - enum: - mediatek,mt7622-wed + - mediatek,mt7981-wed - mediatek,mt7986-wed - const: syscon diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7986-wed-pcie.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7986-wed-pcie.yaml index 96221f51c1c3..82f64469a601 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7986-wed-pcie.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7986-wed-pcie.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7986-wed-pcie.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7986-wed-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek PCIE WED Controller for MT7986 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml index cf1002c3efa6..7cd14b163abe 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-clock.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek Functional Clock Controller for MT8186 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml index 661047d26e11..64c769416690 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-sys-clock.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-sys-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek System Clock Controller for MT8186 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml index b57cc2e69efb..dff4c8e8fd4b 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-clock.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek Functional Clock Controller for MT8192 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml index 27f79175c678..8d608fddf3f9 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-sys-clock.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-sys-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek System Clock Controller for MT8192 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml index d62d60181147..d17164b0b13e 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-clock.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-clock.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek Functional Clock Controller for MT8195 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml index 95b6bdf99936..066c9b3d6ac9 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-sys-clock.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-sys-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek System Clock Controller for MT8195 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml index ef62cbb13590..26158d0d72f3 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek Peripheral Configuration Controller diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt deleted file mode 100644 index d2c24c277514..000000000000 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt +++ /dev/null @@ -1,27 +0,0 @@ -MediaTek SGMIISYS controller -============================ - -The MediaTek SGMIISYS controller provides various clocks to the system. - -Required Properties: - -- compatible: Should be: - - "mediatek,mt7622-sgmiisys", "syscon" - - "mediatek,mt7629-sgmiisys", "syscon" - - "mediatek,mt7981-sgmiisys_0", "syscon" - - "mediatek,mt7981-sgmiisys_1", "syscon" - - "mediatek,mt7986-sgmiisys_0", "syscon" - - "mediatek,mt7986-sgmiisys_1", "syscon" -- #clock-cells: Must be 1 - -The SGMIISYS controller uses the common clk binding from -Documentation/devicetree/bindings/clock/clock-bindings.txt -The available clocks are defined in dt-bindings/clock/mt*-clk.h. - -Example: - -sgmiisys: sgmiisys@1b128000 { - compatible = "mediatek,mt7622-sgmiisys", "syscon"; - reg = <0 0x1b128000 0 0x1000>; - #clock-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt deleted file mode 100644 index 7f696362a4a1..000000000000 --- a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt +++ /dev/null @@ -1,49 +0,0 @@ -Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) - -The KPSS ACC provides clock, power domain, and reset control to a Krait CPU. -There is one ACC register region per CPU within the KPSS remapped region as -well as an alias register region that remaps accesses to the ACC associated -with the CPU accessing the region. - -PROPERTIES - -- compatible: - Usage: required - Value type: <string> - Definition: should be one of: - "qcom,kpss-acc-v1" - "qcom,kpss-acc-v2" - -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: the first element specifies the base address and size of - the register region. An optional second element specifies - the base address and size of the alias register region. - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: reference to the pll parents. - -- clock-names: - Usage: required - Value type: <stringlist> - Definition: must be "pll8_vote", "pxo". - -- clock-output-names: - Usage: optional - Value type: <string> - Definition: Name of the output clock. Typically acpuX_aux where X is a - CPU number starting at 0. - -Example: - - clock-controller@2088000 { - compatible = "qcom,kpss-acc-v2"; - reg = <0x02088000 0x1000>, - <0x02008000 0x1000>; - clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>; - clock-names = "pll8_vote", "pxo"; - clock-output-names = "acpu0_aux"; - }; diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt deleted file mode 100644 index e628758950e1..000000000000 --- a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt +++ /dev/null @@ -1,44 +0,0 @@ -Krait Processor Sub-system (KPSS) Global Clock Controller (GCC) - -PROPERTIES - -- compatible: - Usage: required - Value type: <string> - Definition: should be one of the following. The generic compatible - "qcom,kpss-gcc" should also be included. - "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc" - "qcom,kpss-gcc-apq8064", "qcom,kpss-gcc" - "qcom,kpss-gcc-msm8974", "qcom,kpss-gcc" - "qcom,kpss-gcc-msm8960", "qcom,kpss-gcc" - -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: base address and size of the register region - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: reference to the pll parents. - -- clock-names: - Usage: required - Value type: <stringlist> - Definition: must be "pll8_vote", "pxo". - -- clock-output-names: - Usage: required - Value type: <string> - Definition: Name of the output clock. Typically acpu_l2_aux indicating - an L2 cache auxiliary clock. - -Example: - - l2cc: clock-controller@2011000 { - compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc"; - reg = <0x2011000 0x1000>; - clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>; - clock-names = "pll8_vote", "pxo"; - clock-output-names = "acpu_l2_aux"; - }; diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml deleted file mode 100644 index 38efcad56dbd..000000000000 --- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml +++ /dev/null @@ -1,65 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/arm/msm/qcom,llcc.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Last Level Cache Controller - -maintainers: - - Rishabh Bhatnagar <rishabhb@codeaurora.org> - - Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> - -description: | - LLCC (Last Level Cache Controller) provides last level of cache memory in SoC, - that can be shared by multiple clients. Clients here are different cores in the - SoC, the idea is to minimize the local caches at the clients and migrate to - common pool of memory. Cache memory is divided into partitions called slices - which are assigned to clients. Clients can query the slice details, activate - and deactivate them. - -properties: - compatible: - enum: - - qcom,sc7180-llcc - - qcom,sc7280-llcc - - qcom,sc8180x-llcc - - qcom,sc8280xp-llcc - - qcom,sdm845-llcc - - qcom,sm6350-llcc - - qcom,sm8150-llcc - - qcom,sm8250-llcc - - qcom,sm8350-llcc - - qcom,sm8450-llcc - - qcom,sm8550-llcc - - reg: - items: - - description: LLCC base register region - - description: LLCC broadcast base register region - - reg-names: - items: - - const: llcc_base - - const: llcc_broadcast_base - - interrupts: - maxItems: 1 - -required: - - compatible - - reg - - reg-names - -additionalProperties: false - -examples: - - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - - system-cache-controller@1100000 { - compatible = "qcom,sdm845-llcc"; - reg = <0x1100000 0x200000>, <0x1300000 0x50000> ; - reg-names = "llcc_base", "llcc_broadcast_base"; - interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>; - }; diff --git a/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml b/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml index b6f57d79a753..84dc6b7512af 100644 --- a/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml +++ b/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra194 CPU Complex @@ -25,7 +25,7 @@ properties: - nvidia,tegra194-ccplex nvidia,bpmp: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | Specifies the bpmp node that needs to be queried to get operating point data for all CPUs. diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt b/Documentation/devicetree/bindings/arm/oxnas.txt deleted file mode 100644 index ac64e60f99f1..000000000000 --- a/Documentation/devicetree/bindings/arm/oxnas.txt +++ /dev/null @@ -1,14 +0,0 @@ -Oxford Semiconductor OXNAS SoCs Family device tree bindings -------------------------------------------- - -Boards with the OX810SE SoC shall have the following properties: - Required root node property: - compatible: "oxsemi,ox810se" - -Boards with the OX820 SoC shall have the following properties: - Required root node property: - compatible: "oxsemi,ox820" - -Board compatible values: - - "wd,mbwe" (OX810SE) - - "cloudengines,pogoplugv3" (OX820) diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml index dbb6f3dc5ae5..e14358bf0b9c 100644 --- a/Documentation/devicetree/bindings/arm/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/pmu.yaml @@ -20,6 +20,8 @@ properties: items: - enum: - apm,potenza-pmu + - apple,avalanche-pmu + - apple,blizzard-pmu - apple,firestorm-pmu - apple,icestorm-pmu - arm,armv8-pmuv3 # Only for s/w models diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 1bb24d46e4ee..d9dd25695c3d 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -30,8 +30,10 @@ description: | apq8084 apq8096 ipq4018 + ipq5332 ipq6018 ipq8074 + ipq9574 mdm9615 msm8226 msm8916 @@ -45,7 +47,10 @@ description: | msm8996 msm8998 qcs404 + qcm2290 qdu1000 + qrb2210 + qrb4210 qru1000 sa8155p sa8540p @@ -80,6 +85,9 @@ description: | The 'board' element must be one of the following strings: adp + ap-al02-c7 + ap-mi01.2 + ap-mi01.6 cdp cp01-c1 dragonboard @@ -90,6 +98,7 @@ description: | liquid mtp qrd + rb2 ride sbc x100 @@ -226,6 +235,7 @@ properties: - thwc,uf896 - thwc,ufi001c - wingtech,wt88047 + - yiming,uz801-v3 - const: qcom,msm8916 - items: @@ -322,6 +332,12 @@ properties: - items: - enum: + - qcom,ipq5332-ap-mi01.2 + - qcom,ipq5332-ap-mi01.6 + - const: qcom,ipq5332 + + - items: + - enum: - mikrotik,rb3011 - qcom,ipq8064-ap148 - const: qcom,ipq8064 @@ -333,12 +349,24 @@ properties: - qcom,ipq8074-hk10-c2 - const: qcom,ipq8074 + - items: + - enum: + - qcom,ipq9574-ap-al02-c7 + - const: qcom,ipq9574 + - description: Sierra Wireless MangOH Green with WP8548 Module items: - const: swir,mangoh-green-wp8548 - const: swir,wp8548 - const: qcom,mdm9615 + - description: Qualcomm Technologies, Inc. Robotics RB1 + items: + - enum: + - qcom,qrb2210-rb1 + - const: qcom,qrb2210 + - const: qcom,qcm2290 + - description: Qualcomm Technologies, Inc. Distributed Unit 1000 platform items: - enum: @@ -850,6 +878,12 @@ properties: - items: - enum: + - qcom,qrb4210-rb2 + - const: qcom,qrb4210 + - const: qcom,sm4250 + + - items: + - enum: - lenovo,j606f - const: qcom,sm6115p - const: qcom,sm6115 @@ -857,6 +891,7 @@ properties: - items: - enum: - sony,pdx201 + - xiaomi,laurel-sprout - const: qcom,sm6125 - items: @@ -913,6 +948,7 @@ properties: - items: - enum: - qcom,sm8550-mtp + - qcom,sm8550-qrd - const: qcom,sm8550 # Board compatibles go above diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 35f74eda30ae..ec141c937b8b 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -185,9 +185,11 @@ properties: - const: firefly,rk3566-roc-pc - const: rockchip,rk3566 - - description: FriendlyElec NanoPi R2S + - description: FriendlyElec NanoPi R2 series boards items: - - const: friendlyarm,nanopi-r2s + - enum: + - friendlyarm,nanopi-r2c + - friendlyarm,nanopi-r2s - const: rockchip,rk3328 - description: FriendlyElec NanoPi4 series boards @@ -201,6 +203,13 @@ properties: - friendlyarm,nanopi-r4s-enterprise - const: rockchip,rk3399 + - description: FriendlyElec NanoPi R5 series boards + items: + - enum: + - friendlyarm,nanopi-r5c + - friendlyarm,nanopi-r5s + - const: rockchip,rk3568 + - description: GeekBuying GeekBox items: - const: geekbuying,geekbox @@ -533,6 +542,11 @@ properties: - khadas,edge-v - const: rockchip,rk3399 + - description: Khadas Edge2 series boards + items: + - const: khadas,edge2 + - const: rockchip,rk3588s + - description: Kobol Helios64 items: - const: kobol,helios64 @@ -817,9 +831,11 @@ properties: - const: tronsmart,orion-r68-meta - const: rockchip,rk3368 - - description: Xunlong Orange Pi R1 Plus + - description: Xunlong Orange Pi R1 Plus / LTS items: - - const: xunlong,orangepi-r1-plus + - enum: + - xunlong,orangepi-r1-plus + - xunlong,orangepi-r1-plus-lts - const: rockchip,rk3328 - description: Zkmagic A95X Z2 diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml index b2b156cc160a..ad8e51aa01b0 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml @@ -20,6 +20,7 @@ properties: - st,stm32-syscfg - st,stm32-power-config - st,stm32-tamp + - st,stm32f4-gcan - const: syscon - items: - const: st,stm32-tamp @@ -42,6 +43,7 @@ if: contains: enum: - st,stm32mp157-syscfg + - st,stm32f4-gcan then: required: - clocks diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 3ad1cd50e3fe..013821f4a7b8 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -366,6 +366,12 @@ properties: - const: lamobo,lamobo-r1 - const: allwinner,sun7i-a20 + - description: Lctech Pi F1C200s + items: + - const: lctech,pi-f1c200s + - const: allwinner,suniv-f1c200s + - const: allwinner,suniv-f1c100s + - description: Libre Computer Board ALL-H3-CC H2+ items: - const: libretech,all-h3-cc-h2-plus @@ -807,6 +813,13 @@ properties: - const: sinlinx,sina33 - const: allwinner,sun8i-a33 + - description: SourceParts PopStick v1.1 + items: + - const: sourceparts,popstick-v1.1 + - const: sourceparts,popstick + - const: allwinner,suniv-f1c200s + - const: allwinner,suniv-f1c100s + - description: SL631 Action Camera with IMX179 items: - const: allwinner,sl631-imx179 @@ -843,6 +856,11 @@ properties: - const: wexler,tab7200 - const: allwinner,sun7i-a20 + - description: MangoPi MQ-R board + items: + - const: widora,mangopi-mq-r-t113 + - const: allwinner,sun8i-t113s + - description: WITS A31 Colombus Evaluation Board items: - const: wits,colombus diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 1f62253f9410..0df41f5b7e2a 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -167,5 +167,14 @@ properties: - const: nvidia,p3737-0000+p3701-0000 - const: nvidia,p3701-0000 - const: nvidia,tegra234 + - description: Jetson Orin NX + items: + - const: nvidia,p3767-0000 + - const: nvidia,tegra234 + - description: Jetson Orin NX Engineering Reference Developer Kit + items: + - const: nvidia,p3768-0000+p3767-0000 + - const: nvidia,p3767-0000 + - const: nvidia,tegra234 additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml index 6089a96eae4f..36dbd0838f2d 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra CPU COMPLEX CLUSTER area @@ -29,7 +29,7 @@ properties: maxItems: 1 nvidia,bpmp: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | Specifies the BPMP node that needs to be queried to get operating point data for all CPUs. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml index 788a13f8aa93..5e0f1dc542b0 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra194 AXI2APB bridge diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml index dd3a4770c6a1..d9c54c32c6b9 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra194 CBB 1.0 @@ -64,13 +64,13 @@ properties: - description: secure interrupt nvidia,axi2apb: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: Specifies the node having all axi2apb bridges which need to be checked for any error logged in their status register. nvidia,apbmisc: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: Specifies the apbmisc node which need to be used for reading the ERD register. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml index 4a00593b9f7f..89191cfdf619 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml @@ -234,6 +234,7 @@ properties: patternProperties: "^[a-z0-9]+$": type: object + additionalProperties: false properties: clocks: @@ -252,6 +253,9 @@ properties: for controlling a power-gate. See ../reset/reset.txt for more details. + power-domains: + maxItems: 1 + '#power-domain-cells': const: 0 description: Must be 0. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml index 44184ee01449..fcdf03131323 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra234-cbb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra234-cbb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra CBB 2.0 diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index a60a4065caa8..e1183f90bb06 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -28,7 +28,9 @@ properties: - description: K3 AM625 SoC items: - enum: + - beagle,am625-beagleplay - ti,am625-sk + - ti,am62-lp-sk - const: ti,am625 - description: K3 AM642 SoC diff --git a/Documentation/devicetree/bindings/ata/ahci-common.yaml b/Documentation/devicetree/bindings/ata/ahci-common.yaml index 94d72aeaad0f..7fdf40954a4c 100644 --- a/Documentation/devicetree/bindings/ata/ahci-common.yaml +++ b/Documentation/devicetree/bindings/ata/ahci-common.yaml @@ -59,7 +59,7 @@ properties: const: sata-phy hba-cap: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: Bitfield of the HBA generic platform capabilities like Staggered Spin-up or Mechanical Presence Switch support. It can be used to @@ -67,7 +67,7 @@ properties: in case if the system firmware hasn't done it. ports-implemented: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: Mask that indicates which ports the HBA supports. Useful if PI is not programmed by the BIOS, which is true for some embedded SoC's. @@ -110,7 +110,7 @@ $defs: description: Power regulator for SATA port target device hba-port-cap: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: Bitfield of the HBA port-specific platform capabilities like Hot plugging, eSATA, FIS-based Switching, etc (see AHCI specification diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml index 7dc2a2e8f598..358617115bb8 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.yaml +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml @@ -30,12 +30,12 @@ select: - marvell,armada-3700-ahci - marvell,armada-8k-ahci - marvell,berlin2q-ahci + - socionext,uniphier-pro4-ahci + - socionext,uniphier-pxs2-ahci + - socionext,uniphier-pxs3-ahci required: - compatible -allOf: - - $ref: "ahci-common.yaml#" - properties: compatible: oneOf: @@ -45,6 +45,9 @@ properties: - marvell,armada-8k-ahci - marvell,berlin2-ahci - marvell,berlin2q-ahci + - socionext,uniphier-pro4-ahci + - socionext,uniphier-pxs2-ahci + - socionext,uniphier-pxs3-ahci - const: generic-ahci - enum: - cavium,octeon-7130-ahci @@ -74,7 +77,8 @@ properties: maxItems: 1 resets: - maxItems: 1 + minItems: 1 + maxItems: 3 patternProperties: "^sata-port@[0-9a-f]+$": @@ -91,6 +95,43 @@ required: - reg - interrupts +allOf: + - $ref: ahci-common.yaml# + - if: + properties: + compatible: + contains: + const: socionext,uniphier-pro4-ahci + then: + properties: + resets: + items: + - description: reset line for the parent + - description: reset line for the glue logic + - description: reset line for the controller + required: + - resets + else: + if: + properties: + compatible: + contains: + enum: + - socionext,uniphier-pxs2-ahci + - socionext,uniphier-pxs3-ahci + then: + properties: + resets: + items: + - description: reset for the glue logic + - description: reset for the controller + required: + - resets + else: + properties: + resets: + maxItems: 1 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml index c4e4a9eab658..fe0909554790 100644 --- a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml +++ b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/ata/renesas,rcar-sata.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/ata/renesas,rcar-sata.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas R-Car Serial-ATA Interface diff --git a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml index fc4873deb76f..49304a1476ab 100644 --- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml +++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml @@ -10,7 +10,7 @@ maintainers: - Robin van der Gracht <robin@protonic.nl> allOf: - - $ref: "/schemas/input/matrix-keymap.yaml#" + - $ref: /schemas/input/matrix-keymap.yaml# properties: compatible: @@ -72,7 +72,7 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/input/input.h> #include <dt-bindings/leds/common.h> - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml index 85c4a979aec4..9845a187bdf6 100644 --- a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml @@ -46,6 +46,7 @@ patternProperties: # All other properties should be child nodes with unit-address and 'reg' "^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+$": type: object + additionalProperties: true properties: reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml index bee5f53f837f..24c939f59091 100644 --- a/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml +++ b/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml @@ -45,6 +45,7 @@ properties: patternProperties: "^.*@[0-9a-fA-F]+$": type: object + additionalProperties: true properties: reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml new file mode 100644 index 000000000000..a8d40c766dcd --- /dev/null +++ b/Documentation/devicetree/bindings/bus/microsoft,vmbus.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/microsoft,vmbus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microsoft Hyper-V VMBus + +maintainers: + - Saurabh Sengar <ssengar@linux.microsoft.com> + +description: + VMBus is a software bus that implement the protocols for communication + between the root or host OS and guest OSs (virtual machines). + +properties: + compatible: + const: microsoft,vmbus + + ranges: true + + '#address-cells': + const: 2 + + '#size-cells': + const: 1 + +required: + - compatible + - ranges + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <1>; + bus { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + ranges; + + vmbus@ff0000000 { + compatible = "microsoft,vmbus"; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0x0f 0xf0000000 0x0f 0xf0000000 0x10000000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/bus/palmbus.yaml b/Documentation/devicetree/bindings/bus/palmbus.yaml index 30fa6526cfc2..c36c1e92a573 100644 --- a/Documentation/devicetree/bindings/bus/palmbus.yaml +++ b/Documentation/devicetree/bindings/bus/palmbus.yaml @@ -36,6 +36,7 @@ patternProperties: # All other properties should be child nodes with unit-address and 'reg' "@[0-9a-f]+$": type: object + additionalProperties: true properties: reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/bus/xlnx,versal-net-cdx.yaml b/Documentation/devicetree/bindings/bus/xlnx,versal-net-cdx.yaml new file mode 100644 index 000000000000..7f62ffbdc245 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/xlnx,versal-net-cdx.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/xlnx,versal-net-cdx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AMD CDX bus controller + +description: | + CDX bus controller for AMD devices is implemented to dynamically + detect CDX bus and devices using the firmware. + The CDX bus manages multiple FPGA based hardware devices, which + can support network, crypto or any other specialized type of + devices. These FPGA based devices can be added/modified dynamically + on run-time. + + All devices on the CDX bus will have a unique streamid (for IOMMU) + and a unique device ID (for MSI) corresponding to a requestor ID + (one to one associated with the device). The streamid and deviceid + are used to configure SMMU and GIC-ITS respectively. + + iommu-map property is used to define the set of stream ids + corresponding to each device and the associated IOMMU. + + The MSI writes are accompanied by sideband data (Device ID). + The msi-map property is used to associate the devices with the + device ID as well as the associated ITS controller. + + rproc property (xlnx,rproc) is used to identify the remote processor + with which APU (Application Processor Unit) interacts to find out + the bus and device configuration. + +maintainers: + - Nipun Gupta <nipun.gupta@amd.com> + - Nikhil Agarwal <nikhil.agarwal@amd.com> + +properties: + compatible: + const: xlnx,versal-net-cdx + + iommu-map: true + + msi-map: true + + xlnx,rproc: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to the remoteproc_r5 rproc node using which APU interacts + with remote processor. + + ranges: true + + "#address-cells": + enum: [1, 2] + + "#size-cells": + enum: [1, 2] + +required: + - compatible + - iommu-map + - msi-map + - xlnx,rproc + - ranges + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + cdx { + compatible = "xlnx,versal-net-cdx"; + #address-cells = <1>; + #size-cells = <1>; + /* define map for RIDs 250-259 */ + iommu-map = <250 &smmu 250 10>; + /* define msi map for RIDs 250-259 */ + msi-map = <250 &its 250 10>; + xlnx,rproc = <&remoteproc_r5>; + ranges; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml b/Documentation/devicetree/bindings/cache/baikal,bt1-l2-ctl.yaml index 1fca282f64a2..ec4f367bc0b4 100644 --- a/Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml +++ b/Documentation/devicetree/bindings/cache/baikal,bt1-l2-ctl.yaml @@ -2,7 +2,7 @@ # Copyright (C) 2020 BAIKAL ELECTRONICS, JSC %YAML 1.2 --- -$id: http://devicetree.org/schemas/memory-controllers/baikal,bt1-l2-ctl.yaml# +$id: http://devicetree.org/schemas/cache/baikal,bt1-l2-ctl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Baikal-T1 L2-cache Control Block diff --git a/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt b/Documentation/devicetree/bindings/cache/freescale-l2cache.txt index 22ad012660e9..22ad012660e9 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt +++ b/Documentation/devicetree/bindings/cache/freescale-l2cache.txt diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.yaml b/Documentation/devicetree/bindings/cache/l2c2x0.yaml index 6b8f4d4fa580..d7840a5c4037 100644 --- a/Documentation/devicetree/bindings/arm/l2c2x0.yaml +++ b/Documentation/devicetree/bindings/cache/l2c2x0.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: http://devicetree.org/schemas/arm/l2c2x0.yaml# +$id: http://devicetree.org/schemas/cache/l2c2x0.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: ARM L2 Cache Controller diff --git a/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt b/Documentation/devicetree/bindings/cache/marvell,feroceon-cache.txt index 0d244b999d10..0d244b999d10 100644 --- a/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt +++ b/Documentation/devicetree/bindings/cache/marvell,feroceon-cache.txt diff --git a/Documentation/devicetree/bindings/arm/mrvl/tauros2.txt b/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.txt index 31af1cbb60bd..31af1cbb60bd 100644 --- a/Documentation/devicetree/bindings/arm/mrvl/tauros2.txt +++ b/Documentation/devicetree/bindings/cache/marvell,tauros2-cache.txt diff --git a/Documentation/devicetree/bindings/cache/qcom,llcc.yaml b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml new file mode 100644 index 000000000000..d8b91944180a --- /dev/null +++ b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml @@ -0,0 +1,168 @@ +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cache/qcom,llcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Last Level Cache Controller + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + +description: | + LLCC (Last Level Cache Controller) provides last level of cache memory in SoC, + that can be shared by multiple clients. Clients here are different cores in the + SoC, the idea is to minimize the local caches at the clients and migrate to + common pool of memory. Cache memory is divided into partitions called slices + which are assigned to clients. Clients can query the slice details, activate + and deactivate them. + +properties: + compatible: + enum: + - qcom,sc7180-llcc + - qcom,sc7280-llcc + - qcom,sc8180x-llcc + - qcom,sc8280xp-llcc + - qcom,sdm845-llcc + - qcom,sm6350-llcc + - qcom,sm7150-llcc + - qcom,sm8150-llcc + - qcom,sm8250-llcc + - qcom,sm8350-llcc + - qcom,sm8450-llcc + - qcom,sm8550-llcc + + reg: + minItems: 2 + maxItems: 9 + + reg-names: + minItems: 2 + maxItems: 9 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7180-llcc + - qcom,sm6350-llcc + then: + properties: + reg: + items: + - description: LLCC0 base register region + - description: LLCC broadcast base register region + reg-names: + items: + - const: llcc0_base + - const: llcc_broadcast_base + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7280-llcc + then: + properties: + reg: + items: + - description: LLCC0 base register region + - description: LLCC1 base register region + - description: LLCC broadcast base register region + reg-names: + items: + - const: llcc0_base + - const: llcc1_base + - const: llcc_broadcast_base + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc8180x-llcc + - qcom,sc8280xp-llcc + then: + properties: + reg: + items: + - description: LLCC0 base register region + - description: LLCC1 base register region + - description: LLCC2 base register region + - description: LLCC3 base register region + - description: LLCC4 base register region + - description: LLCC5 base register region + - description: LLCC6 base register region + - description: LLCC7 base register region + - description: LLCC broadcast base register region + reg-names: + items: + - const: llcc0_base + - const: llcc1_base + - const: llcc2_base + - const: llcc3_base + - const: llcc4_base + - const: llcc5_base + - const: llcc6_base + - const: llcc7_base + - const: llcc_broadcast_base + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdm845-llcc + - qcom,sm8150-llcc + - qcom,sm8250-llcc + - qcom,sm8350-llcc + - qcom,sm8450-llcc + then: + properties: + reg: + items: + - description: LLCC0 base register region + - description: LLCC1 base register region + - description: LLCC2 base register region + - description: LLCC3 base register region + - description: LLCC broadcast base register region + reg-names: + items: + - const: llcc0_base + - const: llcc1_base + - const: llcc2_base + - const: llcc3_base + - const: llcc_broadcast_base + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + system-cache-controller@1100000 { + compatible = "qcom,sdm845-llcc"; + reg = <0 0x01100000 0 0x50000>, <0 0x01180000 0 0x50000>, + <0 0x01200000 0 0x50000>, <0 0x01280000 0 0x50000>, + <0 0x01300000 0 0x50000>; + reg-names = "llcc0_base", "llcc1_base", "llcc2_base", + "llcc3_base", "llcc_broadcast_base"; + interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml b/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml index eb6ab73c0f31..8a6a78e1a7ab 100644 --- a/Documentation/devicetree/bindings/riscv/sifive,ccache0.yaml +++ b/Documentation/devicetree/bindings/cache/sifive,ccache0.yaml @@ -2,7 +2,7 @@ # Copyright (C) 2020 SiFive, Inc. %YAML 1.2 --- -$id: http://devicetree.org/schemas/riscv/sifive,ccache0.yaml# +$id: http://devicetree.org/schemas/cache/sifive,ccache0.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: SiFive Composable Cache Controller diff --git a/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml b/Documentation/devicetree/bindings/cache/socionext,uniphier-system-cache.yaml index 6096c082d56d..3196263685a3 100644 --- a/Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml +++ b/Documentation/devicetree/bindings/cache/socionext,uniphier-system-cache.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/arm/socionext/socionext,uniphier-system-cache.yaml# +$id: http://devicetree.org/schemas/cache/socionext,uniphier-system-cache.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: UniPhier outer cache controller diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml index defcf1e12aa1..3b0548c34791 100644 --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml @@ -41,7 +41,7 @@ additionalProperties: false examples: - |+ - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml b/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml index 40244d003c32..c94ab8f9e0b8 100644 --- a/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml +++ b/Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml @@ -20,7 +20,7 @@ additionalProperties: false examples: - | - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/clock/apple,nco.yaml b/Documentation/devicetree/bindings/clock/apple,nco.yaml index 74eab5c0d24a..8b8411dc42f6 100644 --- a/Documentation/devicetree/bindings/clock/apple,nco.yaml +++ b/Documentation/devicetree/bindings/clock/apple,nco.yaml @@ -23,6 +23,7 @@ properties: - enum: - apple,t6000-nco - apple,t8103-nco + - apple,t8112-nco - const: apple,nco clocks: diff --git a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml index 90eadf6869b2..b5533f81307c 100644 --- a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml +++ b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml @@ -81,11 +81,11 @@ properties: maxItems: 1 lock-offset: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: Offset to the unlocking register for the oscillator vco-offset: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: Offset to the VCO register for the oscillator deprecated: true diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml new file mode 100644 index 000000000000..199818b2fb6d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/brcm,bcm63268-timer-clocks.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/brcm,bcm63268-timer-clocks.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM63268 Timer Clock and Reset Device Tree Bindings + +maintainers: + - Ãlvaro Fernández Rojas <noltari@gmail.com> + +properties: + compatible: + const: brcm,bcm63268-timer-clocks + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + timer_clk: clock-controller@100000ac { + compatible = "brcm,bcm63268-timer-clocks"; + reg = <0x100000ac 0x4>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml new file mode 100644 index 000000000000..ff9600474df2 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx8mp-audiomix.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8MP AudioMIX Block Control Binding + +maintainers: + - Marek Vasut <marex@denx.de> + +description: | + NXP i.MX8M Plus AudioMIX is dedicated clock muxing and gating IP + used to control Audio related clock on the SoC. + +properties: + compatible: + const: fsl,imx8mp-audio-blk-ctrl + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + clocks: + minItems: 7 + maxItems: 7 + + clock-names: + items: + - const: ahb + - const: sai1 + - const: sai2 + - const: sai3 + - const: sai5 + - const: sai6 + - const: sai7 + + '#clock-cells': + const: 1 + description: + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mp-clock.h + for the full list of i.MX8MP IMX8MP_CLK_AUDIOMIX_ clock IDs. + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + - '#clock-cells' + +additionalProperties: false + +examples: + # Clock Control Module node: + - | + #include <dt-bindings/clock/imx8mp-clock.h> + + clock-controller@30e20000 { + compatible = "fsl,imx8mp-audio-blk-ctrl"; + reg = <0x30e20000 0x10000>; + #clock-cells = <1>; + clocks = <&clk IMX8MP_CLK_AUDIO_ROOT>, + <&clk IMX8MP_CLK_SAI1>, + <&clk IMX8MP_CLK_SAI2>, + <&clk IMX8MP_CLK_SAI3>, + <&clk IMX8MP_CLK_SAI5>, + <&clk IMX8MP_CLK_SAI6>, + <&clk IMX8MP_CLK_SAI7>; + clock-names = "ahb", + "sai1", "sai2", "sai3", + "sai5", "sai6", "sai7"; + power-domains = <&pgc_audio>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/loongson,ls1x-clk.yaml b/Documentation/devicetree/bindings/clock/loongson,ls1x-clk.yaml new file mode 100644 index 000000000000..01561a0f35d5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/loongson,ls1x-clk.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/loongson,ls1x-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson-1 Clock Controller + +maintainers: + - Keguang Zhang <keguang.zhang@gmail.com> + +properties: + compatible: + enum: + - loongson,ls1b-clk + - loongson,ls1c-clk + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#clock-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - "#clock-cells" + +additionalProperties: false + +examples: + - | + clkc: clock-controller@1fe78030 { + compatible = "loongson,ls1b-clk"; + reg = <0x1fe78030 0x8>; + + clocks = <&xtal>; + #clock-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml index dae25dba4ba6..372c1d744bc2 100644 --- a/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml +++ b/Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/clock/mediatek,apmixedsys.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/clock/mediatek,apmixedsys.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek AP Mixedsys Controller diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8186-fhctl.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-fhctl.yaml index cfd042ac1e14..d00327d12e1e 100644 --- a/Documentation/devicetree/bindings/clock/mediatek,mt8186-fhctl.yaml +++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-fhctl.yaml @@ -16,7 +16,12 @@ description: | properties: compatible: - const: mediatek,mt8186-fhctl + enum: + - mediatek,mt6795-fhctl + - mediatek,mt8173-fhctl + - mediatek,mt8186-fhctl + - mediatek,mt8192-fhctl + - mediatek,mt8195-fhctl reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml new file mode 100644 index 000000000000..d7214d97b2ba --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/mediatek,mt8188-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Functional Clock Controller for MT8188 + +maintainers: + - Garmin Chang <garmin.chang@mediatek.com> + +description: | + The clock architecture in MediaTek like below + PLLs --> + dividers --> + muxes + --> + clock gate + + The devices provide clock gate control in different IP blocks. + +properties: + compatible: + enum: + - mediatek,mt8188-adsp-audio26m + - mediatek,mt8188-camsys + - mediatek,mt8188-camsys-rawa + - mediatek,mt8188-camsys-rawb + - mediatek,mt8188-camsys-yuva + - mediatek,mt8188-camsys-yuvb + - mediatek,mt8188-ccusys + - mediatek,mt8188-imgsys + - mediatek,mt8188-imgsys-wpe1 + - mediatek,mt8188-imgsys-wpe2 + - mediatek,mt8188-imgsys-wpe3 + - mediatek,mt8188-imgsys1-dip-nr + - mediatek,mt8188-imgsys1-dip-top + - mediatek,mt8188-imp-iic-wrap-c + - mediatek,mt8188-imp-iic-wrap-en + - mediatek,mt8188-imp-iic-wrap-w + - mediatek,mt8188-ipesys + - mediatek,mt8188-mfgcfg + - mediatek,mt8188-vdecsys + - mediatek,mt8188-vdecsys-soc + - mediatek,mt8188-vencsys + - mediatek,mt8188-vppsys0 + - mediatek,mt8188-vppsys1 + - mediatek,mt8188-wpesys + - mediatek,mt8188-wpesys-vpp0 + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@11283000 { + compatible = "mediatek,mt8188-imp-iic-wrap-c"; + reg = <0x11283000 0x1000>; + #clock-cells = <1>; + }; + diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8188-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8188-sys-clock.yaml new file mode 100644 index 000000000000..4cf8d3af9803 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mediatek,mt8188-sys-clock.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/mediatek,mt8188-sys-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek System Clock Controller for MT8188 + +maintainers: + - Garmin Chang <garmin.chang@mediatek.com> + +description: | + The clock architecture in MediaTek like below + PLLs --> + dividers --> + muxes + --> + clock gate + + The apmixedsys provides most of PLLs which generated from SoC 26m. + The topckgen provides dividers and muxes which provide the clock source to other IP blocks. + The infracfg_ao provides clock gate in peripheral and infrastructure IP blocks. + The mcusys provides mux control to select the clock source in AP MCU. + The device nodes also provide the system control capacity for configuration. + +properties: + compatible: + items: + - enum: + - mediatek,mt8188-apmixedsys + - mediatek,mt8188-infracfg-ao + - mediatek,mt8188-pericfg-ao + - mediatek,mt8188-topckgen + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@10000000 { + compatible = "mediatek,mt8188-topckgen", "syscon"; + reg = <0x10000000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml index 0fdf56414833..6d087ded7437 100644 --- a/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml +++ b/Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/clock/mediatek,topckgen.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/clock/mediatek,topckgen.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek Top Clock Generator Controller diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml index 525ebaa93c85..659669bf224b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml @@ -16,6 +16,7 @@ description: properties: compatible: enum: + - qcom,ipq5332-a53pll - qcom,ipq6018-a53pll - qcom,ipq8074-a53pll - qcom,msm8916-a53pll @@ -45,14 +46,14 @@ required: additionalProperties: false examples: - #Example 1 - A53 PLL found on MSM8916 devices + # Example 1 - A53 PLL found on MSM8916 devices - | a53pll: clock@b016000 { compatible = "qcom,msm8916-a53pll"; reg = <0xb016000 0x40>; #clock-cells = <0>; }; - #Example 2 - A53 PLL found on IPQ6018 devices + # Example 2 - A53 PLL found on IPQ6018 devices - | a53pll_ipq: clock-controller@b116000 { compatible = "qcom,ipq6018-a53pll"; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml new file mode 100644 index 000000000000..6ebaef2288fa --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq4019.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-ipq4019.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on IPQ4019 + +maintainers: + - Stephen Boyd <sboyd@kernel.org> + - Taniya Das <tdas@codeaurora.org> + - Robert Marko <robert.markoo@sartura.hr> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on IPQ4019. + + See also:: include/dt-bindings/clock/qcom,gcc-ipq4019.h + +allOf: + - $ref: qcom,gcc.yaml# + +properties: + compatible: + const: qcom,gcc-ipq4019 + + clocks: + items: + - description: board XO clock + - description: sleep clock + + clock-names: + items: + - const: xo + - const: sleep_clk + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + clock-controller@1800000 { + compatible = "qcom,gcc-ipq4019"; + reg = <0x1800000 0x60000>; + #clock-cells = <1>; + #power-domain-cells = <1>; + #reset-cells = <1>; + clocks = <&xo>, <&sleep_clk>; + clock-names = "xo", "sleep_clk"; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml index 6279a59c2e20..b91462587df5 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml @@ -4,20 +4,25 @@ $id: http://devicetree.org/schemas/clock/qcom,gcc-msm8909.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Global Clock & Reset Controller on MSM8909 +title: Qualcomm Global Clock & Reset Controller on MSM8909, MSM8917 and QM215 maintainers: - Stephan Gerhold <stephan@gerhold.net> description: | Qualcomm global clock control module provides the clocks, resets and power - domains on MSM8909. + domains on MSM8909, MSM8917 or QM215. - See also:: include/dt-bindings/clock/qcom,gcc-msm8909.h + See also:: + include/dt-bindings/clock/qcom,gcc-msm8909.h + include/dt-bindings/clock/qcom,gcc-msm8917.h properties: compatible: - const: qcom,gcc-msm8909 + enum: + - qcom,gcc-msm8909 + - qcom,gcc-msm8917 + - qcom,gcc-qm215 clocks: items: diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml index 2e8acca64af1..ae01e7749534 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml @@ -15,7 +15,6 @@ description: | domains. See also:: - include/dt-bindings/clock/qcom,gcc-ipq4019.h include/dt-bindings/clock/qcom,gcc-ipq6018.h include/dt-bindings/reset/qcom,gcc-ipq6018.h include/dt-bindings/clock/qcom,gcc-msm8953.h @@ -29,7 +28,6 @@ allOf: properties: compatible: enum: - - qcom,gcc-ipq4019 - qcom,gcc-ipq6018 - qcom,gcc-mdm9607 - qcom,gcc-msm8953 diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index db53eb288995..1e3dc9deded9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -15,6 +15,7 @@ description: | See also:: include/dt-bindings/clock/qcom,gpucc-sdm845.h + include/dt-bindings/clock/qcom,gpucc-sa8775p.h include/dt-bindings/clock/qcom,gpucc-sc7180.h include/dt-bindings/clock/qcom,gpucc-sc7280.h include/dt-bindings/clock/qcom,gpucc-sc8280xp.h @@ -27,6 +28,7 @@ properties: compatible: enum: - qcom,sdm845-gpucc + - qcom,sa8775p-gpucc - qcom,sc7180-gpucc - qcom,sc7280-gpucc - qcom,sc8180x-gpucc diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5332-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5332-gcc.yaml new file mode 100644 index 000000000000..718fe0625424 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,ipq5332-gcc.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,ipq5332-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on IPQ5332 + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on IPQ5332. + + See also:: include/dt-bindings/clock/qcom,gcc-ipq5332.h + +allOf: + - $ref: qcom,gcc.yaml# + +properties: + compatible: + const: qcom,ipq5332-gcc + + clocks: + items: + - description: Board XO clock source + - description: Sleep clock source + - description: PCIE 2lane PHY pipe clock source + - description: PCIE 2lane x1 PHY pipe clock source (For second lane) + - description: USB PCIE wrapper pipe clock source + +required: + - compatible + - clocks + +unevaluatedProperties: false + +examples: + - | + clock-controller@1800000 { + compatible = "qcom,ipq5332-gcc"; + reg = <0x01800000 0x80000>; + clocks = <&xo_board>, + <&sleep_clk>, + <&pcie_2lane_phy_pipe_clk>, + <&pcie_2lane_phy_pipe_clk_x1>, + <&usb_pcie_wrapper_pipe_clk>; + #clock-cells = <1>; + #power-domain-cells = <1>; + #reset-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml new file mode 100644 index 000000000000..afc68eb9d7cc --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,ipq9574-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on IPQ9574 + +maintainers: + - Anusha Rao <quic_anusha@quicinc.com> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on IPQ9574 + + See also:: + include/dt-bindings/clock/qcom,ipq9574-gcc.h + include/dt-bindings/reset/qcom,ipq9574-gcc.h + +properties: + compatible: + const: qcom,ipq9574-gcc + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + - description: Bias PLL ubi clock source + - description: PCIE30 PHY0 pipe clock source + - description: PCIE30 PHY1 pipe clock source + - description: PCIE30 PHY2 pipe clock source + - description: PCIE30 PHY3 pipe clock source + - description: USB3 PHY pipe clock source + +required: + - compatible + - clocks + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + clock-controller@1800000 { + compatible = "qcom,ipq9574-gcc"; + reg = <0x01800000 0x80000>; + clocks = <&xo_board_clk>, + <&sleep_clk>, + <&bias_pll_ubi_nc_clk>, + <&pcie30_phy0_pipe_clk>, + <&pcie30_phy1_pipe_clk>, + <&pcie30_phy2_pipe_clk>, + <&pcie30_phy3_pipe_clk>, + <&usb3phy_0_cc_pipe_clk>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml b/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml new file mode 100644 index 000000000000..a466e4e8aacd --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,kpss-acc-v1.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,kpss-acc-v1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) v1 + +maintainers: + - Christian Marangi <ansuelsmth@gmail.com> + +description: + The KPSS ACC provides clock, power domain, and reset control to a Krait CPU. + There is one ACC register region per CPU within the KPSS remapped region as + well as an alias register region that remaps accesses to the ACC associated + with the CPU accessing the region. ACC v1 is currently used as a + clock-controller for enabling the cpu and hanling the aux clocks. + +properties: + compatible: + const: qcom,kpss-acc-v1 + + reg: + items: + - description: Base address and size of the register region + - description: Optional base address and size of the alias register region + minItems: 1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: pll8_vote + - const: pxo + + clock-output-names: + description: Name of the aux clock. Krait can have at most 4 cpu. + enum: + - acpu0_aux + - acpu1_aux + - acpu2_aux + - acpu3_aux + + '#clock-cells': + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - clock-output-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-ipq806x.h> + + clock-controller@2088000 { + compatible = "qcom,kpss-acc-v1"; + reg = <0x02088000 0x1000>, <0x02008000 0x1000>; + clocks = <&gcc PLL8_VOTE>, <&pxo_board>; + clock-names = "pll8_vote", "pxo"; + clock-output-names = "acpu0_aux"; + #clock-cells = <0>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/qcom,kpss-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,kpss-gcc.yaml new file mode 100644 index 000000000000..88b7672123a0 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,kpss-gcc.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,kpss-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Krait Processor Sub-system (KPSS) Global Clock Controller (GCC) + +maintainers: + - Christian Marangi <ansuelsmth@gmail.com> + +description: + Krait Processor Sub-system (KPSS) Global Clock Controller (GCC). Used + to control L2 mux (in the current implementation) and provide access + to the kpss-gcc registers. + +properties: + compatible: + items: + - enum: + - qcom,kpss-gcc-ipq8064 + - qcom,kpss-gcc-apq8064 + - qcom,kpss-gcc-msm8974 + - qcom,kpss-gcc-msm8960 + - qcom,kpss-gcc-msm8660 + - qcom,kpss-gcc-mdm9615 + - const: qcom,kpss-gcc + - const: syscon + + reg: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: pll8_vote + - const: pxo + + '#clock-cells': + const: 0 + +required: + - compatible + - reg + +if: + properties: + compatible: + contains: + enum: + - qcom,kpss-gcc-ipq8064 + - qcom,kpss-gcc-apq8064 + - qcom,kpss-gcc-msm8974 + - qcom,kpss-gcc-msm8960 +then: + required: + - clocks + - clock-names + - '#clock-cells' +else: + properties: + clock: false + clock-names: false + '#clock-cells': false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-ipq806x.h> + + clock-controller@2011000 { + compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc", "syscon"; + reg = <0x2011000 0x1000>; + clocks = <&gcc PLL8_VOTE>, <&pxo_board>; + clock-names = "pll8_vote", "pxo"; + #clock-cells = <0>; + }; + + - | + clock-controller@2011000 { + compatible = "qcom,kpss-gcc-mdm9615", "qcom,kpss-gcc", "syscon"; + reg = <0x02011000 0x1000>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml index 2a95bf8664f9..3665dd30604a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml @@ -31,6 +31,7 @@ properties: - qcom,rpmcc-msm8660 - qcom,rpmcc-msm8909 - qcom,rpmcc-msm8916 + - qcom,rpmcc-msm8917 - qcom,rpmcc-msm8936 - qcom,rpmcc-msm8953 - qcom,rpmcc-msm8974 @@ -107,6 +108,7 @@ allOf: - qcom,rpmcc-mdm9607 - qcom,rpmcc-msm8226 - qcom,rpmcc-msm8916 + - qcom,rpmcc-msm8917 - qcom,rpmcc-msm8936 - qcom,rpmcc-msm8953 - qcom,rpmcc-msm8974 diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml index 6151fdebbff8..97c6bd96e0cb 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscc.yaml @@ -41,6 +41,12 @@ properties: - const: qdsp6ss - const: top_cc + qcom,adsp-pil-mode: + description: + Indicates if the LPASS would be brought out of reset using + remoteproc peripheral loader. + type: boolean + required: - compatible - reg @@ -60,6 +66,7 @@ examples: reg-names = "qdsp6ss", "top_cc"; clocks = <&gcc GCC_CFG_NOC_LPASS_CLK>; clock-names = "iface"; + qcom,adsp-pil-mode; #clock-cells = <1>; }; ... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml new file mode 100644 index 000000000000..cf19f44af774 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm6115-gpucc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Graphics Clock & Reset Controller on SM6115 + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: | + Qualcomm graphics clock control module provides clocks, resets and power + domains on Qualcomm SoCs. + + See also:: include/dt-bindings/clock/qcom,sm6115-gpucc.h + +properties: + compatible: + enum: + - qcom,sm6115-gpucc + + clocks: + items: + - description: Board XO source + - description: GPLL0 main branch source + - description: GPLL0 main div source + +required: + - compatible + - clocks + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sm6115.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + + soc { + #address-cells = <1>; + #size-cells = <1>; + + clock-controller@5990000 { + compatible = "qcom,sm6115-gpucc"; + reg = <0x05990000 0x9000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml new file mode 100644 index 000000000000..374a1844a159 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.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/qcom,sm6125-gpucc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Graphics Clock & Reset Controller on SM6125 + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: | + Qualcomm graphics clock control module provides clocks and power domains on + Qualcomm SoCs. + + See also:: include/dt-bindings/clock/qcom,sm6125-gpucc.h + +properties: + compatible: + enum: + - qcom,sm6125-gpucc + + clocks: + items: + - description: Board XO source + - description: GPLL0 main branch source + + '#clock-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sm6125.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + + soc { + #address-cells = <1>; + #size-cells = <1>; + + clock-controller@5990000 { + compatible = "qcom,sm6125-gpucc"; + reg = <0x05990000 0x9000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_CLK_SRC>; + #clock-cells = <1>; + #power-domain-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml new file mode 100644 index 000000000000..b480ead5bd69 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm6375-gpucc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Graphics Clock & Reset Controller on SM6375 + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: | + Qualcomm graphics clock control module provides clocks, resets and power + domains on Qualcomm SoCs. + + See also:: include/dt-bindings/clock/qcom,sm6375-gpucc.h + +properties: + compatible: + enum: + - qcom,sm6375-gpucc + + clocks: + items: + - description: Board XO source + - description: GPLL0 main branch source + - description: GPLL0 div branch source + - description: SNoC DVM GFX source + +required: + - compatible + - clocks + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm6375-gcc.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + clock-controller@5990000 { + compatible = "qcom,sm6375-gpucc"; + reg = <0 0x05990000 0 0x9000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>, + <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm7150-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm7150-gcc.yaml new file mode 100644 index 000000000000..0eb76d9d51c4 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm7150-gcc.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm7150-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on SM7150 + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + - Danila Tikhonov <danila@jiaxyga.com> + - David Wronek <davidwronek@gmail.com> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on SM7150 + + See also:: include/dt-bindings/clock/qcom,sm7150-gcc.h + +properties: + compatible: + const: qcom,sm7150-gcc + + clocks: + items: + - description: Board XO source + - description: Board XO Active-Only source + - description: Sleep clock source + +required: + - compatible + - clocks + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@100000 { + compatible = "qcom,sm7150-gcc"; + reg = <0x00100000 0x001f0000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&rpmhcc RPMH_CXO_CLK_A>, + <&sleep_clk>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/renesas,9series.yaml b/Documentation/devicetree/bindings/clock/renesas,9series.yaml index 6b6cec3fba52..3afdebdb52ad 100644 --- a/Documentation/devicetree/bindings/clock/renesas,9series.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,9series.yaml @@ -16,6 +16,11 @@ description: | - 9FGV0241: 0 -- DIF0 1 -- DIF1 + - 9FGV0441: + 0 -- DIF0 + 1 -- DIF1 + 2 -- DIF2 + 3 -- DIF3 maintainers: - Marek Vasut <marex@denx.de> @@ -24,6 +29,7 @@ properties: compatible: enum: - renesas,9fgv0241 + - renesas,9fgv0441 reg: description: I2C device address diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml index e57bc40d307a..9c3dc6c4fa94 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/clock/renesas,cpg-mssr.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/clock/renesas,cpg-mssr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas Clock Pulse Generator / Module Standby and Software Reset diff --git a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml index 81f09df7147e..c84f29f1810f 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/clock/renesas,rcar-usb2-clock-sel.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/clock/renesas,rcar-usb2-clock-sel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas R-Car USB 2.0 clock selector diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml index 487f74cdc749..fe2fba18ae84 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas RZ/{G2L,V2L,V2M} Clock Pulse Generator / Module Standby Mode diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml index 141cf173f87d..c752c8985a53 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml @@ -37,6 +37,7 @@ properties: - samsung,exynos850-cmu-cmgp - samsung,exynos850-cmu-core - samsung,exynos850-cmu-dpu + - samsung,exynos850-cmu-g3d - samsung,exynos850-cmu-hsi - samsung,exynos850-cmu-is - samsung,exynos850-cmu-mfcmscl @@ -173,6 +174,24 @@ allOf: properties: compatible: contains: + const: samsung,exynos850-cmu-g3d + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: G3D clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: dout_g3d_switch + + - if: + properties: + compatible: + contains: const: samsung,exynos850-cmu-hsi then: @@ -183,7 +202,7 @@ allOf: - description: External RTC clock (32768 Hz) - description: CMU_HSI bus clock (from CMU_TOP) - description: SD card clock (from CMU_TOP) - - description: "USB 2.0 DRD clock (from CMU_TOP)" + - description: USB 2.0 DRD clock (from CMU_TOP) clock-names: items: diff --git a/Documentation/devicetree/bindings/clock/skyworks,si521xx.yaml b/Documentation/devicetree/bindings/clock/skyworks,si521xx.yaml new file mode 100644 index 000000000000..9e35e0e51ce8 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/skyworks,si521xx.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/skyworks,si521xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Skyworks Si521xx I2C PCIe clock generators + +description: | + The Skyworks Si521xx are I2C PCIe clock generators providing + from 4 to 9 output clocks. + +maintainers: + - Marek Vasut <marex@denx.de> + +properties: + compatible: + enum: + - skyworks,si52144 + - skyworks,si52146 + - skyworks,si52147 + + reg: + const: 0x6b + + '#clock-cells': + const: 1 + + clocks: + items: + - description: XTal input clock + + skyworks,out-amplitude-microvolt: + enum: [ 300000, 400000, 500000, 600000, 700000, 800000, 900000, 1000000 ] + description: Output clock signal amplitude + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + clock-generator@6b { + compatible = "skyworks,si52144"; + reg = <0x6b>; + #clock-cells = <1>; + clocks = <&ref25m>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml index 785a12797a42..1703e305e6d8 100644 --- a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml +++ b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Unisoc Inc. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/clock/sprd,sc9863a-clk.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/clock/sprd,sc9863a-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: SC9863A Clock Control Unit diff --git a/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml index 5f747b0471cf..43d2b6c31357 100644 --- a/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml +++ b/Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml @@ -2,8 +2,8 @@ # Copyright 2022 Unisoc Inc. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/clock/sprd,ums512-clk.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/clock/sprd,ums512-clk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: UMS512 Soc clock controller diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml new file mode 100644 index 000000000000..923680a44aef --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml @@ -0,0 +1,107 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/starfive,jh7110-aoncrg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 Always-On Clock and Reset Generator + +maintainers: + - Emil Renner Berthing <kernel@esmil.dk> + +properties: + compatible: + const: starfive,jh7110-aoncrg + + reg: + maxItems: 1 + + clocks: + oneOf: + - items: + - description: Main Oscillator (24 MHz) + - description: GMAC0 RMII reference or GMAC0 RGMII RX + - description: STG AXI/AHB + - description: APB Bus + - description: GMAC0 GTX + + - items: + - description: Main Oscillator (24 MHz) + - description: GMAC0 RMII reference or GMAC0 RGMII RX + - description: STG AXI/AHB or GMAC0 RGMII RX + - description: APB Bus or STG AXI/AHB + - description: GMAC0 GTX or APB Bus + - description: RTC Oscillator (32.768 kHz) or GMAC0 GTX + + - items: + - description: Main Oscillator (24 MHz) + - description: GMAC0 RMII reference + - description: GMAC0 RGMII RX + - description: STG AXI/AHB + - description: APB Bus + - description: GMAC0 GTX + - description: RTC Oscillator (32.768 kHz) + + clock-names: + oneOf: + - minItems: 5 + items: + - const: osc + - enum: + - gmac0_rmii_refin + - gmac0_rgmii_rxin + - const: stg_axiahb + - const: apb_bus + - const: gmac0_gtxclk + - const: rtc_osc + + - minItems: 6 + items: + - const: osc + - const: gmac0_rmii_refin + - const: gmac0_rgmii_rxin + - const: stg_axiahb + - const: apb_bus + - const: gmac0_gtxclk + - const: rtc_osc + + '#clock-cells': + const: 1 + description: + See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices. + + '#reset-cells': + const: 1 + description: + See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices. + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/starfive,jh7110-crg.h> + + clock-controller@17000000 { + compatible = "starfive,jh7110-aoncrg"; + reg = <0x17000000 0x10000>; + clocks = <&osc>, <&gmac0_rmii_refin>, + <&gmac0_rgmii_rxin>, + <&syscrg JH7110_SYSCLK_STG_AXIAHB>, + <&syscrg JH7110_SYSCLK_APB_BUS>, + <&syscrg JH7110_SYSCLK_GMAC0_GTXCLK>, + <&rtc_osc>; + clock-names = "osc", "gmac0_rmii_refin", + "gmac0_rgmii_rxin", "stg_axiahb", + "apb_bus", "gmac0_gtxclk", + "rtc_osc"; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml new file mode 100644 index 000000000000..84373ae31644 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/starfive,jh7110-syscrg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 System Clock and Reset Generator + +maintainers: + - Emil Renner Berthing <kernel@esmil.dk> + +properties: + compatible: + const: starfive,jh7110-syscrg + + reg: + maxItems: 1 + + clocks: + oneOf: + - items: + - description: Main Oscillator (24 MHz) + - description: GMAC1 RMII reference or GMAC1 RGMII RX + - description: External I2S TX bit clock + - description: External I2S TX left/right channel clock + - description: External I2S RX bit clock + - description: External I2S RX left/right channel clock + - description: External TDM clock + - description: External audio master clock + + - items: + - description: Main Oscillator (24 MHz) + - description: GMAC1 RMII reference + - description: GMAC1 RGMII RX + - description: External I2S TX bit clock + - description: External I2S TX left/right channel clock + - description: External I2S RX bit clock + - description: External I2S RX left/right channel clock + - description: External TDM clock + - description: External audio master clock + + clock-names: + oneOf: + - items: + - const: osc + - enum: + - gmac1_rmii_refin + - gmac1_rgmii_rxin + - const: i2stx_bclk_ext + - const: i2stx_lrck_ext + - const: i2srx_bclk_ext + - const: i2srx_lrck_ext + - const: tdm_ext + - const: mclk_ext + + - items: + - const: osc + - const: gmac1_rmii_refin + - const: gmac1_rgmii_rxin + - const: i2stx_bclk_ext + - const: i2stx_lrck_ext + - const: i2srx_bclk_ext + - const: i2srx_lrck_ext + - const: tdm_ext + - const: mclk_ext + + '#clock-cells': + const: 1 + description: + See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices. + + '#reset-cells': + const: 1 + description: + See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices. + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + clock-controller@13020000 { + compatible = "starfive,jh7110-syscrg"; + reg = <0x13020000 0x10000>; + clocks = <&osc>, <&gmac1_rmii_refin>, + <&gmac1_rgmii_rxin>, + <&i2stx_bclk_ext>, <&i2stx_lrck_ext>, + <&i2srx_bclk_ext>, <&i2srx_lrck_ext>, + <&tdm_ext>, <&mclk_ext>; + clock-names = "osc", "gmac1_rmii_refin", + "gmac1_rgmii_rxin", + "i2stx_bclk_ext", "i2stx_lrck_ext", + "i2srx_bclk_ext", "i2srx_lrck_ext", + "tdm_ext", "mclk_ext"; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml b/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml index 73d17830f165..13d7b3d03d84 100644 --- a/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml +++ b/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml @@ -160,7 +160,7 @@ examples: }; }; - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml index 634b7b964606..c1f04830a832 100644 --- a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml +++ b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/clock/xlnx,clocking-wizard.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/clock/xlnx,clocking-wizard.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx clocking wizard diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml index e4aa8c67d532..a6b3bb8fdf33 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -20,12 +20,20 @@ properties: oneOf: - description: v1 of CPUFREQ HW items: + - enum: + - qcom,qcm2290-cpufreq-hw + - qcom,sc7180-cpufreq-hw + - qcom,sdm845-cpufreq-hw + - qcom,sm6115-cpufreq-hw + - qcom,sm6350-cpufreq-hw + - qcom,sm8150-cpufreq-hw - const: qcom,cpufreq-hw - description: v2 of CPUFREQ HW (EPSS) items: - enum: - qcom,qdu1000-cpufreq-epss + - qcom,sa8775p-cpufreq-epss - qcom,sc7280-cpufreq-epss - qcom,sc8280xp-cpufreq-epss - qcom,sm6375-cpufreq-epss @@ -36,14 +44,14 @@ properties: - const: qcom,cpufreq-epss reg: - minItems: 2 + minItems: 1 items: - description: Frequency domain 0 register region - description: Frequency domain 1 register region - description: Frequency domain 2 register region reg-names: - minItems: 2 + minItems: 1 items: - const: freq-domain0 - const: freq-domain1 @@ -85,6 +93,111 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,qcm2290-cpufreq-hw + then: + properties: + reg: + minItems: 1 + maxItems: 1 + + reg-names: + minItems: 1 + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 1 + + interrupt-names: + minItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - qcom,qdu1000-cpufreq-epss + - qcom,sc7180-cpufreq-hw + - qcom,sc8280xp-cpufreq-epss + - qcom,sdm845-cpufreq-hw + - qcom,sm6115-cpufreq-hw + - qcom,sm6350-cpufreq-hw + - qcom,sm6375-cpufreq-epss + then: + properties: + reg: + minItems: 2 + maxItems: 2 + + reg-names: + minItems: 2 + maxItems: 2 + + interrupts: + minItems: 2 + maxItems: 2 + + interrupt-names: + minItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7280-cpufreq-epss + - qcom,sm8250-cpufreq-epss + - qcom,sm8350-cpufreq-epss + - qcom,sm8450-cpufreq-epss + - qcom,sm8550-cpufreq-epss + then: + properties: + reg: + minItems: 3 + maxItems: 3 + + reg-names: + minItems: 3 + maxItems: 3 + + interrupts: + minItems: 3 + maxItems: 3 + + interrupt-names: + minItems: 3 + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8150-cpufreq-hw + then: + properties: + reg: + minItems: 3 + maxItems: 3 + + reg-names: + minItems: 3 + maxItems: 3 + + # On some SoCs the Prime core shares the LMH irq with Big cores + interrupts: + minItems: 2 + maxItems: 2 + + interrupt-names: + minItems: 2 + + examples: - | #include <dt-bindings/clock/qcom,gcc-sdm845.h> @@ -235,7 +348,7 @@ examples: #size-cells = <1>; cpufreq@17d43000 { - compatible = "qcom,cpufreq-hw"; + compatible = "qcom,sdm845-cpufreq-hw", "qcom,cpufreq-hw"; reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>; reg-names = "freq-domain0", "freq-domain1"; diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml new file mode 100644 index 000000000000..286dffa0671b --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0-mon.yaml @@ -0,0 +1,156 @@ +# SPDX-License-Identifier: GPL-2.0 +# Copyright (C) 2008-2011 Freescale Semiconductor Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/fsl,sec-v4.0-mon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Secure Non-Volatile Storage (SNVS) + +maintainers: + - '"Horia Geantă" <horia.geanta@nxp.com>' + - Pankaj Gupta <pankaj.gupta@nxp.com> + - Gaurav Jain <gaurav.jain@nxp.com> + +description: + Node defines address range and the associated interrupt for the SNVS function. + This function monitors security state information & reports security + violations. This also included rtc, system power off and ON/OFF key. + +properties: + compatible: + oneOf: + - items: + - const: fsl,sec-v4.0-mon + - const: syscon + - const: simple-mfd + - items: + - const: fsl,sec-v5.0-mon + - const: fsl,sec-v4.0-mon + - items: + - enum: + - fsl,sec-v5.3-mon + - fsl,sec-v5.4-mon + - const: fsl,sec-v5.0-mon + - const: fsl,sec-v4.0-mon + + reg: + maxItems: 1 + + interrupts: + maxItems: 2 + + snvs-rtc-lp: + type: object + additionalProperties: false + description: + Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node + + properties: + compatible: + const: fsl,sec-v4.0-mon-rtc-lp + + clocks: + maxItems: 1 + + clock-names: + const: snvs-rtc + + interrupts: + # VFxxx has only one. What is the 2nd one? + minItems: 1 + maxItems: 2 + + regmap: + description: Parent node containing registers + $ref: /schemas/types.yaml#/definitions/phandle + + offset: + description: LP register offset + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0x34 + + required: + - compatible + - interrupts + - regmap + + snvs-powerkey: + type: object + additionalProperties: false + description: + The snvs-pwrkey is designed to enable POWER key function which controlled + by SNVS ONOFF, the driver can report the status of POWER key and wakeup + system if pressed after system suspend. + + properties: + compatible: + const: fsl,sec-v4.0-pwrkey + + clocks: + maxItems: 1 + + clock-names: + const: snvs-pwrkey + + interrupts: + maxItems: 1 + + regmap: + description: Parent node containing registers + $ref: /schemas/types.yaml#/definitions/phandle + + wakeup-source: true + + linux,keycode: + default: 116 + + required: + - compatible + - interrupts + - regmap + + snvs-lpgpr: + $ref: /schemas/nvmem/snvs-lpgpr.yaml# + + snvs-poweroff: + description: + The SNVS could drive signal to PMIC to turn off system power by setting + SNVS_LP LPCR register. + $ref: /schemas/power/reset/syscon-poweroff.yaml# + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx7d-clock.h> + + sec_mon: sec-mon@314000 { + compatible = "fsl,sec-v4.0-mon", "syscon", "simple-mfd"; + reg = <0x314000 0x1000>; + + snvs-rtc-lp { + compatible = "fsl,sec-v4.0-mon-rtc-lp"; + regmap = <&sec_mon>; + offset = <0x34>; + clocks = <&clks IMX7D_SNVS_CLK>; + clock-names = "snvs-rtc"; + interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>; + }; + + snvs-powerkey { + compatible = "fsl,sec-v4.0-pwrkey"; + regmap = <&sec_mon>; + clocks = <&clks IMX7D_SNVS_CLK>; + clock-names = "snvs-pwrkey"; + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>; + linux,keycode = <116>; /* KEY_POWER */ + wakeup-source; + }; + }; diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0.yaml b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0.yaml new file mode 100644 index 000000000000..0a9ed2848b7c --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/fsl,sec-v4.0.yaml @@ -0,0 +1,266 @@ +# SPDX-License-Identifier: GPL-2.0 +# Copyright (C) 2008-2011 Freescale Semiconductor Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/fsl,sec-v4.0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale SEC 4 + +maintainers: + - '"Horia Geantă" <horia.geanta@nxp.com>' + - Pankaj Gupta <pankaj.gupta@nxp.com> + - Gaurav Jain <gaurav.jain@nxp.com> + +description: | + NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator + Accelerator and Assurance Module (CAAM). + + SEC 4 h/w can process requests from 2 types of sources. + 1. DPAA Queue Interface (HW interface between Queue Manager & SEC 4). + 2. Job Rings (HW interface between cores & SEC 4 registers). + + High Speed Data Path Configuration: + + HW interface between QM & SEC 4 and also BM & SEC 4, on DPAA-enabled parts + such as the P4080. The number of simultaneous dequeues the QI can make is + equal to the number of Descriptor Controller (DECO) engines in a particular + SEC version. E.g., the SEC 4.0 in the P4080 has 5 DECOs and can thus + dequeue from 5 subportals simultaneously. + + Job Ring Data Path Configuration: + + Each JR is located on a separate 4k page, they may (or may not) be made visible + in the memory partition devoted to a particular core. The P4080 has 4 JRs, so + up to 4 JRs can be configured; and all 4 JRs process requests in parallel. + +properties: + compatible: + oneOf: + - items: + - const: fsl,sec-v5.4 + - const: fsl,sec-v5.0 + - const: fsl,sec-v4.0 + - items: + - enum: + - fsl,imx6ul-caam + - fsl,sec-v5.0 + - const: fsl,sec-v4.0 + - const: fsl,sec-v4.0 + + reg: + maxItems: 1 + + ranges: + maxItems: 1 + + '#address-cells': + enum: [1, 2] + + '#size-cells': + enum: [1, 2] + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + minItems: 1 + maxItems: 4 + items: + enum: [mem, aclk, ipg, emi_slow] + + dma-coherent: true + + interrupts: + maxItems: 1 + + fsl,sec-era: + description: Defines the 'ERA' of the SEC device. + $ref: /schemas/types.yaml#/definitions/uint32 + +patternProperties: + '^jr@[0-9a-f]+$': + type: object + additionalProperties: false + description: + Job Ring (JR) Node. Defines data processing interface to SEC 4 across the + peripheral bus for purposes of processing cryptographic descriptors. The + specified address range can be made visible to one (or more) cores. The + interrupt defined for this node is controlled within the address range of + this node. + + properties: + compatible: + oneOf: + - items: + - const: fsl,sec-v5.4-job-ring + - const: fsl,sec-v5.0-job-ring + - const: fsl,sec-v4.0-job-ring + - items: + - const: fsl,sec-v5.0-job-ring + - const: fsl,sec-v4.0-job-ring + - const: fsl,sec-v4.0-job-ring + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + fsl,liodn: + description: + Specifies the LIODN to be used in conjunction with the ppid-to-liodn + table that specifies the PPID to LIODN mapping. Needed if the PAMU is + used. Value is a 12 bit value where value is a LIODN ID for this JR. + This property is normally set by boot firmware. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 0xfff + + '^rtic@[0-9a-f]+$': + type: object + additionalProperties: false + description: + Run Time Integrity Check (RTIC) Node. Defines a register space that + contains up to 5 sets of addresses and their lengths (sizes) that will be + checked at run time. After an initial hash result is calculated, these + addresses are checked by HW to monitor any change. If any memory is + modified, a Security Violation is triggered (see SNVS definition). + + properties: + compatible: + oneOf: + - items: + - const: fsl,sec-v5.4-rtic + - const: fsl,sec-v5.0-rtic + - const: fsl,sec-v4.0-rtic + - const: fsl,sec-v4.0-rtic + + reg: + maxItems: 1 + + ranges: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + patternProperties: + '^rtic-[a-z]@[0-9a-f]+$': + type: object + additionalProperties: false + description: + Run Time Integrity Check (RTIC) Memory Node defines individual RTIC + memory regions that are used to perform run-time integrity check of + memory areas that should not modified. The node defines a register + that contains the memory address & length (combined) and a second + register that contains the hash result in big endian format. + + properties: + compatible: + oneOf: + - items: + - const: fsl,sec-v5.4-rtic-memory + - const: fsl,sec-v5.0-rtic-memory + - const: fsl,sec-v4.0-rtic-memory + - const: fsl,sec-v4.0-rtic-memory + + reg: + items: + - description: RTIC memory address + - description: RTIC hash result + + fsl,liodn: + description: + Specifies the LIODN to be used in conjunction with the + ppid-to-liodn table that specifies the PPID to LIODN mapping. + Needed if the PAMU is used. Value is a 12 bit value where value + is a LIODN ID for this JR. This property is normally set by boot + firmware. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 0xfff + + fsl,rtic-region: + description: + Specifies the HW address (36 bit address) for this region + followed by the length of the HW partition to be checked; + the address is represented as a 64 bit quantity followed + by a 32 bit length. + $ref: /schemas/types.yaml#/definitions/uint32-array + +required: + - compatible + - reg + - ranges + +additionalProperties: false + +examples: + - | + crypto@300000 { + compatible = "fsl,sec-v4.0"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x300000 0x10000>; + ranges = <0 0x300000 0x10000>; + interrupts = <92 2>; + + jr@1000 { + compatible = "fsl,sec-v4.0-job-ring"; + reg = <0x1000 0x1000>; + interrupts = <88 2>; + }; + + jr@2000 { + compatible = "fsl,sec-v4.0-job-ring"; + reg = <0x2000 0x1000>; + interrupts = <89 2>; + }; + + jr@3000 { + compatible = "fsl,sec-v4.0-job-ring"; + reg = <0x3000 0x1000>; + interrupts = <90 2>; + }; + + jr@4000 { + compatible = "fsl,sec-v4.0-job-ring"; + reg = <0x4000 0x1000>; + interrupts = <91 2>; + }; + + rtic@6000 { + compatible = "fsl,sec-v4.0-rtic"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x6000 0x100>; + ranges = <0x0 0x6100 0xe00>; + + rtic-a@0 { + compatible = "fsl,sec-v4.0-rtic-memory"; + reg = <0x00 0x20>, <0x100 0x80>; + }; + + rtic-b@20 { + compatible = "fsl,sec-v4.0-rtic-memory"; + reg = <0x20 0x20>, <0x200 0x80>; + }; + + rtic-c@40 { + compatible = "fsl,sec-v4.0-rtic-memory"; + reg = <0x40 0x20>, <0x300 0x80>; + }; + + rtic-d@60 { + compatible = "fsl,sec-v4.0-rtic-memory"; + reg = <0x60 0x20>, <0x500 0x80>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt deleted file mode 100644 index 8f359f473ada..000000000000 --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt +++ /dev/null @@ -1,553 +0,0 @@ -===================================================================== -SEC 4 Device Tree Binding -Copyright (C) 2008-2011 Freescale Semiconductor Inc. - - CONTENTS - -Overview - -SEC 4 Node - -Job Ring Node - -Run Time Integrity Check (RTIC) Node - -Run Time Integrity Check (RTIC) Memory Node - -Secure Non-Volatile Storage (SNVS) Node - -Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node - -Full Example - -NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator -Accelerator and Assurance Module (CAAM). - -===================================================================== -Overview - -DESCRIPTION - -SEC 4 h/w can process requests from 2 types of sources. -1. DPAA Queue Interface (HW interface between Queue Manager & SEC 4). -2. Job Rings (HW interface between cores & SEC 4 registers). - -High Speed Data Path Configuration: - -HW interface between QM & SEC 4 and also BM & SEC 4, on DPAA-enabled parts -such as the P4080. The number of simultaneous dequeues the QI can make is -equal to the number of Descriptor Controller (DECO) engines in a particular -SEC version. E.g., the SEC 4.0 in the P4080 has 5 DECOs and can thus -dequeue from 5 subportals simultaneously. - -Job Ring Data Path Configuration: - -Each JR is located on a separate 4k page, they may (or may not) be made visible -in the memory partition devoted to a particular core. The P4080 has 4 JRs, so -up to 4 JRs can be configured; and all 4 JRs process requests in parallel. - -===================================================================== -SEC 4 Node - -Description - - Node defines the base address of the SEC 4 block. - This block specifies the address range of all global - configuration registers for the SEC 4 block. It - also receives interrupts from the Run Time Integrity Check - (RTIC) function within the SEC 4 block. - -PROPERTIES - - - compatible - Usage: required - Value type: <string> - Definition: Must include "fsl,sec-v4.0" - - - fsl,sec-era - Usage: optional - Value type: <u32> - Definition: A standard property. Define the 'ERA' of the SEC - device. - - - #address-cells - Usage: required - Value type: <u32> - Definition: A standard property. Defines the number of cells - for representing physical addresses in child nodes. - - - #size-cells - Usage: required - Value type: <u32> - Definition: A standard property. Defines the number of cells - for representing the size of physical addresses in - child nodes. - - - reg - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. Specifies the physical - address and length of the SEC4 configuration registers. - registers - - - ranges - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. Specifies the physical address - range of the SEC 4.0 register space (-SNVS not included). A - triplet that includes the child address, parent address, & - length. - - - interrupts - Usage: required - Value type: <prop_encoded-array> - Definition: Specifies the interrupts generated by this - device. The value of the interrupts property - consists of one interrupt specifier. The format - of the specifier is defined by the binding document - describing the node's interrupt parent. - - - clocks - Usage: required if SEC 4.0 requires explicit enablement of clocks - Value type: <prop_encoded-array> - Definition: A list of phandle and clock specifier pairs describing - the clocks required for enabling and disabling SEC 4.0. - - - clock-names - Usage: required if SEC 4.0 requires explicit enablement of clocks - Value type: <string> - Definition: A list of clock name strings in the same order as the - clocks property. - - Note: All other standard properties (see the Devicetree Specification) - are allowed but are optional. - - -EXAMPLE - -iMX6QDL/SX requires four clocks - - crypto@300000 { - compatible = "fsl,sec-v4.0"; - fsl,sec-era = <2>; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x300000 0x10000>; - ranges = <0 0x300000 0x10000>; - interrupt-parent = <&mpic>; - interrupts = <92 2>; - clocks = <&clks IMX6QDL_CLK_CAAM_MEM>, - <&clks IMX6QDL_CLK_CAAM_ACLK>, - <&clks IMX6QDL_CLK_CAAM_IPG>, - <&clks IMX6QDL_CLK_EIM_SLOW>; - clock-names = "mem", "aclk", "ipg", "emi_slow"; - }; - - -iMX6UL does only require three clocks - - crypto: crypto@2140000 { - compatible = "fsl,sec-v4.0"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x2140000 0x3c000>; - ranges = <0 0x2140000 0x3c000>; - interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>; - - clocks = <&clks IMX6UL_CLK_CAAM_MEM>, - <&clks IMX6UL_CLK_CAAM_ACLK>, - <&clks IMX6UL_CLK_CAAM_IPG>; - clock-names = "mem", "aclk", "ipg"; - }; - -===================================================================== -Job Ring (JR) Node - - Child of the crypto node defines data processing interface to SEC 4 - across the peripheral bus for purposes of processing - cryptographic descriptors. The specified address - range can be made visible to one (or more) cores. - The interrupt defined for this node is controlled within - the address range of this node. - - - compatible - Usage: required - Value type: <string> - Definition: Must include "fsl,sec-v4.0-job-ring" - - - reg - Usage: required - Value type: <prop-encoded-array> - Definition: Specifies a two JR parameters: an offset from - the parent physical address and the length the JR registers. - - - fsl,liodn - Usage: optional-but-recommended - Value type: <prop-encoded-array> - Definition: - Specifies the LIODN to be used in conjunction with - the ppid-to-liodn table that specifies the PPID to LIODN mapping. - Needed if the PAMU is used. Value is a 12 bit value - where value is a LIODN ID for this JR. This property is - normally set by boot firmware. - - - interrupts - Usage: required - Value type: <prop_encoded-array> - Definition: Specifies the interrupts generated by this - device. The value of the interrupts property - consists of one interrupt specifier. The format - of the specifier is defined by the binding document - describing the node's interrupt parent. - -EXAMPLE - jr@1000 { - compatible = "fsl,sec-v4.0-job-ring"; - reg = <0x1000 0x1000>; - fsl,liodn = <0x081>; - interrupt-parent = <&mpic>; - interrupts = <88 2>; - }; - - -===================================================================== -Run Time Integrity Check (RTIC) Node - - Child node of the crypto node. Defines a register space that - contains up to 5 sets of addresses and their lengths (sizes) that - will be checked at run time. After an initial hash result is - calculated, these addresses are checked by HW to monitor any - change. If any memory is modified, a Security Violation is - triggered (see SNVS definition). - - - - compatible - Usage: required - Value type: <string> - Definition: Must include "fsl,sec-v4.0-rtic". - - - #address-cells - Usage: required - Value type: <u32> - Definition: A standard property. Defines the number of cells - for representing physical addresses in child nodes. Must - have a value of 1. - - - #size-cells - Usage: required - Value type: <u32> - Definition: A standard property. Defines the number of cells - for representing the size of physical addresses in - child nodes. Must have a value of 1. - - - reg - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. Specifies a two parameters: - an offset from the parent physical address and the length - the SEC4 registers. - - - ranges - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. Specifies the physical address - range of the SEC 4 register space (-SNVS not included). A - triplet that includes the child address, parent address, & - length. - -EXAMPLE - rtic@6000 { - compatible = "fsl,sec-v4.0-rtic"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x6000 0x100>; - ranges = <0x0 0x6100 0xe00>; - }; - -===================================================================== -Run Time Integrity Check (RTIC) Memory Node - A child node that defines individual RTIC memory regions that are used to - perform run-time integrity check of memory areas that should not modified. - The node defines a register that contains the memory address & - length (combined) and a second register that contains the hash result - in big endian format. - - - compatible - Usage: required - Value type: <string> - Definition: Must include "fsl,sec-v4.0-rtic-memory". - - - reg - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. Specifies two parameters: - an offset from the parent physical address and the length: - - 1. The location of the RTIC memory address & length registers. - 2. The location RTIC hash result. - - - fsl,rtic-region - Usage: optional-but-recommended - Value type: <prop-encoded-array> - Definition: - Specifies the HW address (36 bit address) for this region - followed by the length of the HW partition to be checked; - the address is represented as a 64 bit quantity followed - by a 32 bit length. - - - fsl,liodn - Usage: optional-but-recommended - Value type: <prop-encoded-array> - Definition: - Specifies the LIODN to be used in conjunction with - the ppid-to-liodn table that specifies the PPID to LIODN - mapping. Needed if the PAMU is used. Value is a 12 bit value - where value is a LIODN ID for this RTIC memory region. This - property is normally set by boot firmware. - -EXAMPLE - rtic-a@0 { - compatible = "fsl,sec-v4.0-rtic-memory"; - reg = <0x00 0x20 0x100 0x80>; - fsl,liodn = <0x03c>; - fsl,rtic-region = <0x12345678 0x12345678 0x12345678>; - }; - -===================================================================== -Secure Non-Volatile Storage (SNVS) Node - - Node defines address range and the associated - interrupt for the SNVS function. This function - monitors security state information & reports - security violations. This also included rtc, - system power off and ON/OFF key. - - - compatible - Usage: required - Value type: <string> - Definition: Must include "fsl,sec-v4.0-mon" and "syscon". - - - reg - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. Specifies the physical - address and length of the SEC4 configuration - registers. - - - #address-cells - Usage: required - Value type: <u32> - Definition: A standard property. Defines the number of cells - for representing physical addresses in child nodes. Must - have a value of 1. - - - #size-cells - Usage: required - Value type: <u32> - Definition: A standard property. Defines the number of cells - for representing the size of physical addresses in - child nodes. Must have a value of 1. - - - ranges - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. Specifies the physical address - range of the SNVS register space. A triplet that includes - the child address, parent address, & length. - - - interrupts - Usage: optional - Value type: <prop_encoded-array> - Definition: Specifies the interrupts generated by this - device. The value of the interrupts property - consists of one interrupt specifier. The format - of the specifier is defined by the binding document - describing the node's interrupt parent. - -EXAMPLE - sec_mon@314000 { - compatible = "fsl,sec-v4.0-mon", "syscon"; - reg = <0x314000 0x1000>; - ranges = <0 0x314000 0x1000>; - interrupt-parent = <&mpic>; - interrupts = <93 2>; - }; - -===================================================================== -Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node - - A SNVS child node that defines SNVS LP RTC. - - - compatible - Usage: required - Value type: <string> - Definition: Must include "fsl,sec-v4.0-mon-rtc-lp". - - - interrupts - Usage: required - Value type: <prop_encoded-array> - Definition: Specifies the interrupts generated by this - device. The value of the interrupts property - consists of one interrupt specifier. The format - of the specifier is defined by the binding document - describing the node's interrupt parent. - - - regmap - Usage: required - Value type: <phandle> - Definition: this is phandle to the register map node. - - - offset - Usage: option - value type: <u32> - Definition: LP register offset. default it is 0x34. - - - clocks - Usage: optional, required if SNVS LP RTC requires explicit - enablement of clocks - Value type: <prop_encoded-array> - Definition: a clock specifier describing the clock required for - enabling and disabling SNVS LP RTC. - - - clock-names - Usage: optional, required if SNVS LP RTC requires explicit - enablement of clocks - Value type: <string> - Definition: clock name string should be "snvs-rtc". - -EXAMPLE - sec_mon_rtc_lp@1 { - compatible = "fsl,sec-v4.0-mon-rtc-lp"; - interrupts = <93 2>; - regmap = <&snvs>; - offset = <0x34>; - clocks = <&clks IMX7D_SNVS_CLK>; - clock-names = "snvs-rtc"; - }; - -===================================================================== -System ON/OFF key driver - - The snvs-pwrkey is designed to enable POWER key function which controlled - by SNVS ONOFF, the driver can report the status of POWER key and wakeup - system if pressed after system suspend. - - - compatible: - Usage: required - Value type: <string> - Definition: Mush include "fsl,sec-v4.0-pwrkey". - - - interrupts: - Usage: required - Value type: <prop_encoded-array> - Definition: The SNVS ON/OFF interrupt number to the CPU(s). - - - linux,keycode: - Usage: option - Value type: <int> - Definition: Keycode to emit, KEY_POWER by default. - - - wakeup-source: - Usage: option - Value type: <boo> - Definition: Button can wake-up the system. - - - regmap: - Usage: required: - Value type: <phandle> - Definition: this is phandle to the register map node. - -EXAMPLE: - snvs-pwrkey@020cc000 { - compatible = "fsl,sec-v4.0-pwrkey"; - regmap = <&snvs>; - interrupts = <0 4 0x4> - linux,keycode = <116>; /* KEY_POWER */ - wakeup-source; - }; - -===================================================================== -FULL EXAMPLE - - crypto: crypto@300000 { - compatible = "fsl,sec-v4.0"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x300000 0x10000>; - ranges = <0 0x300000 0x10000>; - interrupt-parent = <&mpic>; - interrupts = <92 2>; - - sec_jr0: jr@1000 { - compatible = "fsl,sec-v4.0-job-ring"; - reg = <0x1000 0x1000>; - interrupt-parent = <&mpic>; - interrupts = <88 2>; - }; - - sec_jr1: jr@2000 { - compatible = "fsl,sec-v4.0-job-ring"; - reg = <0x2000 0x1000>; - interrupt-parent = <&mpic>; - interrupts = <89 2>; - }; - - sec_jr2: jr@3000 { - compatible = "fsl,sec-v4.0-job-ring"; - reg = <0x3000 0x1000>; - interrupt-parent = <&mpic>; - interrupts = <90 2>; - }; - - sec_jr3: jr@4000 { - compatible = "fsl,sec-v4.0-job-ring"; - reg = <0x4000 0x1000>; - interrupt-parent = <&mpic>; - interrupts = <91 2>; - }; - - rtic@6000 { - compatible = "fsl,sec-v4.0-rtic"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x6000 0x100>; - ranges = <0x0 0x6100 0xe00>; - - rtic_a: rtic-a@0 { - compatible = "fsl,sec-v4.0-rtic-memory"; - reg = <0x00 0x20 0x100 0x80>; - }; - - rtic_b: rtic-b@20 { - compatible = "fsl,sec-v4.0-rtic-memory"; - reg = <0x20 0x20 0x200 0x80>; - }; - - rtic_c: rtic-c@40 { - compatible = "fsl,sec-v4.0-rtic-memory"; - reg = <0x40 0x20 0x300 0x80>; - }; - - rtic_d: rtic-d@60 { - compatible = "fsl,sec-v4.0-rtic-memory"; - reg = <0x60 0x20 0x500 0x80>; - }; - }; - }; - - sec_mon: sec_mon@314000 { - compatible = "fsl,sec-v4.0-mon"; - reg = <0x314000 0x1000>; - ranges = <0 0x314000 0x1000>; - - sec_mon_rtc_lp@34 { - compatible = "fsl,sec-v4.0-mon-rtc-lp"; - regmap = <&sec_mon>; - offset = <0x34>; - interrupts = <93 2>; - clocks = <&clks IMX7D_SNVS_CLK>; - clock-names = "snvs-rtc"; - }; - - snvs-pwrkey@020cc000 { - compatible = "fsl,sec-v4.0-pwrkey"; - regmap = <&sec_mon>; - interrupts = <0 4 0x4>; - linux,keycode = <116>; /* KEY_POWER */ - wakeup-source; - }; - }; - -===================================================================== diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml new file mode 100644 index 000000000000..92e1d76e29ee --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/qcom,inline-crypto-engine.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. (QTI) Inline Crypto Engine + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + +properties: + compatible: + items: + - enum: + - qcom,sm8550-inline-crypto-engine + - const: qcom,inline-crypto-engine + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm8550-gcc.h> + + crypto@1d88000 { + compatible = "qcom,sm8550-inline-crypto-engine", + "qcom,inline-crypto-engine"; + reg = <0x01d88000 0x8000>; + clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>; + }; +... diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.txt b/Documentation/devicetree/bindings/crypto/qcom-qce.txt deleted file mode 100644 index fdd53b184ba8..000000000000 --- a/Documentation/devicetree/bindings/crypto/qcom-qce.txt +++ /dev/null @@ -1,25 +0,0 @@ -Qualcomm crypto engine driver - -Required properties: - -- compatible : should be "qcom,crypto-v5.1" -- reg : specifies base physical address and size of the registers map -- clocks : phandle to clock-controller plus clock-specifier pair -- clock-names : "iface" clocks register interface - "bus" clocks data transfer interface - "core" clocks rest of the crypto block -- dmas : DMA specifiers for tx and rx dma channels. For more see - Documentation/devicetree/bindings/dma/dma.txt -- dma-names : DMA request names should be "rx" and "tx" - -Example: - crypto@fd45a000 { - compatible = "qcom,crypto-v5.1"; - reg = <0xfd45a000 0x6000>; - clocks = <&gcc GCC_CE2_AHB_CLK>, - <&gcc GCC_CE2_AXI_CLK>, - <&gcc GCC_CE2_CLK>; - clock-names = "iface", "bus", "core"; - dmas = <&cryptobam 2>, <&cryptobam 3>; - dma-names = "rx", "tx"; - }; diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml new file mode 100644 index 000000000000..e375bd981300 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml @@ -0,0 +1,123 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/qcom-qce.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm crypto engine driver + +maintainers: + - Bhupesh Sharma <bhupesh.sharma@linaro.org> + +description: + This document defines the binding for the QCE crypto + controller found on Qualcomm parts. + +properties: + compatible: + oneOf: + - const: qcom,crypto-v5.1 + deprecated: true + description: Kept only for ABI backward compatibility + + - const: qcom,crypto-v5.4 + deprecated: true + description: Kept only for ABI backward compatibility + + - items: + - enum: + - qcom,ipq6018-qce + - qcom,ipq8074-qce + - qcom,msm8996-qce + - qcom,sdm845-qce + - const: qcom,ipq4019-qce + - const: qcom,qce + + - items: + - enum: + - qcom,sm8250-qce + - qcom,sm8350-qce + - qcom,sm8450-qce + - qcom,sm8550-qce + - const: qcom,sm8150-qce + - const: qcom,qce + + reg: + maxItems: 1 + + clocks: + items: + - description: iface clocks register interface. + - description: bus clocks data transfer interface. + - description: core clocks rest of the crypto block. + + clock-names: + items: + - const: iface + - const: bus + - const: core + + iommus: + minItems: 1 + maxItems: 8 + description: + phandle to apps_smmu node with sid mask. + + interconnects: + maxItems: 1 + description: + Interconnect path between qce crypto and main memory. + + interconnect-names: + const: memory + + dmas: + items: + - description: DMA specifiers for rx dma channel. + - description: DMA specifiers for tx dma channel. + + dma-names: + items: + - const: rx + - const: tx + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,crypto-v5.1 + - qcom,crypto-v5.4 + - qcom,ipq4019-qce + + then: + required: + - clocks + - clock-names + +required: + - compatible + - reg + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-apq8084.h> + crypto-engine@fd45a000 { + compatible = "qcom,ipq6018-qce", "qcom,ipq4019-qce", "qcom,qce"; + reg = <0xfd45a000 0x6000>; + clocks = <&gcc GCC_CE2_AHB_CLK>, + <&gcc GCC_CE2_AXI_CLK>, + <&gcc GCC_CE2_CLK>; + clock-names = "iface", "bus", "core"; + dmas = <&cryptobam 2>, <&cryptobam 3>; + dma-names = "rx", "tx"; + iommus = <&apps_smmu 0x584 0x0011>, + <&apps_smmu 0x586 0x0011>, + <&apps_smmu 0x594 0x0011>, + <&apps_smmu 0x596 0x0011>; + }; diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml index 0c15fefb6671..77ec8bc70bf7 100644 --- a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml +++ b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml @@ -26,8 +26,8 @@ properties: dmas: items: - description: TX DMA Channel - - description: RX DMA Channel #1 - - description: RX DMA Channel #2 + - description: 'RX DMA Channel #1' + - description: 'RX DMA Channel #2' dma-names: items: diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml index 74cefdf1b843..0c85894648d8 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic specific extensions to the Synopsys Designware HDMI Controller diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml index 6655a93b1874..0c72120acc4f 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson Display Controller diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index 4590186c4a0b..a1ed1004651b 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Analogix Semiconductor, Inc. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter) @@ -16,8 +16,7 @@ description: | properties: compatible: - items: - - const: analogix,anx7625 + const: analogix,anx7625 reg: maxItems: 1 @@ -134,7 +133,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml new file mode 100644 index 000000000000..c9b06885cc63 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/analogix,dp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analogix Display Port bridge + +maintainers: + - Rob Herring <robh@kernel.org> + +properties: + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: true + + clock-names: true + + phys: true + + phy-names: + const: dp + + force-hpd: + description: + Indicate driver need force hpd when hpd detect failed, this + is used for some eDP screen which don not have a hpd signal. + + hpd-gpios: + description: + Hotplug detect GPIO. + Indicates which GPIO should be used for hotplug detection + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Input node to receive pixel data. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Port node with one endpoint connected to a dp-connector node. + + required: + - port@0 + - port@1 + +required: + - reg + - interrupts + - clock-names + - clocks + - ports + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt deleted file mode 100644 index 027d76c27a41..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt +++ /dev/null @@ -1,51 +0,0 @@ -Analogix Display Port bridge bindings - -Required properties for dp-controller: - -compatible: - platform specific such as: - * "samsung,exynos5-dp" - * "rockchip,rk3288-dp" - * "rockchip,rk3399-edp" - -reg: - physical base address of the controller and length - of memory mapped region. - -interrupts: - interrupt combiner values. - -clocks: - from common clock binding: handle to dp clock. - -clock-names: - from common clock binding: Shall be "dp". - -phys: - from general PHY binding: the phandle for the PHY device. - -phy-names: - from general PHY binding: Should be "dp". - -Optional properties for dp-controller: - -force-hpd: - Indicate driver need force hpd when hpd detect failed, this - is used for some eDP screen which don't have hpd signal. - -hpd-gpios: - Hotplug detect GPIO. - Indicates which GPIO should be used for hotplug detection - -port@[X]: SoC specific port nodes with endpoint definitions as defined - in Documentation/devicetree/bindings/media/video-interfaces.txt, - please refer to the SoC specific binding document: - * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt - * Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt -------------------------------------------------------------------------------- - -Example: - - dp-controller { - compatible = "samsung,exynos5-dp"; - reg = <0x145b0000 0x10000>; - interrupts = <10 3>; - interrupt-parent = <&combiner>; - clocks = <&clock 342>; - clock-names = "dp"; - - phys = <&dp_phy>; - phy-names = "dp"; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml index 9bf2cbcea69f..514f58852990 100644 --- a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml @@ -61,7 +61,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index b2e8bc6da9d0..c2b369456e4e 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp8546.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8546.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence MHDP8546 bridge diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml index 674891ee2f8e..f201ae4af4fb 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml @@ -67,7 +67,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> - i2c4 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml index 107dd138e6c6..70ec70922c13 100644 --- a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml +++ b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml @@ -18,7 +18,7 @@ properties: maxItems: 1 edid-emulation: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: The EDID emulation entry to use Value Resolution Description @@ -71,7 +71,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/bridge/parade,ps8622.yaml b/Documentation/devicetree/bindings/display/bridge/parade,ps8622.yaml new file mode 100644 index 000000000000..e6397ac2048b --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/parade,ps8622.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/parade,ps8622.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Parade PS8622/PS8625 DisplayPort to LVDS Converter + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + +properties: + compatible: + enum: + - parade,ps8622 + - parade,ps8625 + + reg: + maxItems: 1 + + lane-count: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2] + description: Number of DP lanes to use. + + use-external-pwm: + type: boolean + description: Backlight will be controlled by an external PWM. + + reset-gpios: + maxItems: 1 + description: GPIO connected to RST_ pin. + + sleep-gpios: + maxItems: 1 + description: GPIO connected to PD_ pin. + + vdd12-supply: true + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for LVDS output. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for DisplayPort input. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - reset-gpios + - sleep-gpios + - ports + +allOf: + - if: + properties: + compatible: + const: parade,ps8622 + then: + properties: + lane-count: + const: 1 + else: + properties: + lane-count: + const: 2 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + lvds-bridge@48 { + compatible = "parade,ps8625"; + reg = <0x48>; + sleep-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpy7 7 GPIO_ACTIVE_HIGH>; + lane-count = <2>; + use-external-pwm; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + bridge_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + + port@1 { + reg = <1>; + + bridge_in: endpoint { + remote-endpoint = <&dp_out>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/ps8622.txt b/Documentation/devicetree/bindings/display/bridge/ps8622.txt deleted file mode 100644 index c989c3807f2b..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/ps8622.txt +++ /dev/null @@ -1,31 +0,0 @@ -ps8622-bridge bindings - -Required properties: - - compatible: "parade,ps8622" or "parade,ps8625" - - reg: first i2c address of the bridge - - sleep-gpios: OF device-tree gpio specification for PD_ pin. - - reset-gpios: OF device-tree gpio specification for RST_ pin. - -Optional properties: - - lane-count: number of DP lanes to use - - use-external-pwm: backlight will be controlled by an external PWM - - video interfaces: Device node can contain video interface port - nodes for panel according to [1]. - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - lvds-bridge@48 { - compatible = "parade,ps8622"; - reg = <0x48>; - sleep-gpios = <&gpc3 6 1 0 0>; - reset-gpios = <&gpc3 1 1 0 0>; - lane-count = <1>; - ports { - port@0 { - bridge_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml index 28811aff2c5a..5856450c5da7 100644 --- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml @@ -73,7 +73,7 @@ additionalProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml new file mode 100644 index 000000000000..e841659e20cd --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -0,0 +1,255 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/samsung,mipi-dsim.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung MIPI DSIM bridge controller + +maintainers: + - Inki Dae <inki.dae@samsung.com> + - Jagan Teki <jagan@amarulasolutions.com> + - Marek Szyprowski <m.szyprowski@samsung.com> + +description: | + Samsung MIPI DSIM bridge controller can be found it on Exynos + and i.MX8M Mini/Nano/Plus SoC's. + +properties: + compatible: + oneOf: + - enum: + - samsung,exynos3250-mipi-dsi + - samsung,exynos4210-mipi-dsi + - samsung,exynos5410-mipi-dsi + - samsung,exynos5422-mipi-dsi + - samsung,exynos5433-mipi-dsi + - fsl,imx8mm-mipi-dsim + - fsl,imx8mp-mipi-dsim + - items: + - const: fsl,imx8mn-mipi-dsim + - const: fsl,imx8mm-mipi-dsim + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + clocks: + minItems: 2 + maxItems: 5 + + clock-names: + minItems: 2 + maxItems: 5 + + samsung,phy-type: + $ref: /schemas/types.yaml#/definitions/uint32 + description: phandle to the samsung phy-type + + power-domains: + maxItems: 1 + + samsung,power-domain: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the associated samsung power domain + + vddcore-supply: + description: MIPI DSIM Core voltage supply (e.g. 1.1V) + + vddio-supply: + description: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) + + samsung,burst-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + DSIM high speed burst mode frequency. + + samsung,esc-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + DSIM escape mode frequency. + + samsung,pll-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + DSIM oscillator clock frequency. + + phys: + maxItems: 1 + + phy-names: + const: dsim + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Input port node to receive pixel data from the + display controller. Exactly one endpoint must be + specified. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + DSI output port node to the panel or the next bridge + in the chain. + +required: + - clock-names + - clocks + - compatible + - interrupts + - reg + - samsung,burst-clock-frequency + - samsung,esc-clock-frequency + - samsung,pll-clock-frequency + +allOf: + - $ref: ../dsi-controller.yaml# + - if: + properties: + compatible: + contains: + const: samsung,exynos5433-mipi-dsi + + then: + properties: + clocks: + minItems: 5 + + clock-names: + items: + - const: bus_clk + - const: phyclk_mipidphy0_bitclkdiv8 + - const: phyclk_mipidphy0_rxclkesc0 + - const: sclk_rgb_vclk_to_dsim0 + - const: sclk_mipi + + ports: + required: + - port@0 + + required: + - ports + - vddcore-supply + - vddio-supply + + - if: + properties: + compatible: + contains: + const: samsung,exynos5410-mipi-dsi + + then: + properties: + clocks: + minItems: 2 + + clock-names: + items: + - const: bus_clk + - const: pll_clk + + required: + - vddcore-supply + - vddio-supply + + - if: + properties: + compatible: + contains: + const: samsung,exynos4210-mipi-dsi + + then: + properties: + clocks: + minItems: 2 + + clock-names: + items: + - const: bus_clk + - const: sclk_mipi + + required: + - vddcore-supply + - vddio-supply + + - if: + properties: + compatible: + contains: + const: samsung,exynos3250-mipi-dsi + + then: + properties: + clocks: + minItems: 2 + + clock-names: + items: + - const: bus_clk + - const: pll_clk + + required: + - vddcore-supply + - vddio-supply + - samsung,phy-type + +additionalProperties: + type: object + +examples: + - | + #include <dt-bindings/clock/exynos5433.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + dsi@13900000 { + compatible = "samsung,exynos5433-mipi-dsi"; + reg = <0x13900000 0xC0>; + interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>; + phys = <&mipi_phy 1>; + phy-names = "dsim"; + clocks = <&cmu_disp CLK_PCLK_DSIM0>, + <&cmu_disp CLK_PHYCLK_MIPIDPHY0_BITCLKDIV8>, + <&cmu_disp CLK_PHYCLK_MIPIDPHY0_RXCLKESC0>, + <&cmu_disp CLK_SCLK_RGB_VCLK_TO_DSIM0>, + <&cmu_disp CLK_SCLK_DSIM0>; + clock-names = "bus_clk", + "phyclk_mipidphy0_bitclkdiv8", + "phyclk_mipidphy0_rxclkesc0", + "sclk_rgb_vclk_to_dsim0", + "sclk_mipi"; + power-domains = <&pd_disp>; + vddcore-supply = <&ldo6_reg>; + vddio-supply = <&ldo7_reg>; + samsung,burst-clock-frequency = <512000000>; + samsung,esc-clock-frequency = <16000000>; + samsung,pll-clock-frequency = <24000000>; + pinctrl-names = "default"; + pinctrl-0 = <&te_irq>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + dsi_to_mic: endpoint { + remote-endpoint = <&mic_to_dsi>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii9234.yaml b/Documentation/devicetree/bindings/display/bridge/sil,sii9234.yaml index f88ddfe4818b..176181d25530 100644 --- a/Documentation/devicetree/bindings/display/bridge/sil,sii9234.yaml +++ b/Documentation/devicetree/bindings/display/bridge/sil,sii9234.yaml @@ -71,7 +71,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml index 11fd68a70dca..0b51c64f141a 100644 --- a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml @@ -26,19 +26,9 @@ properties: reg: maxItems: 1 - clocks: - items: - - description: Module clock - - description: DSI bus clock for either AHB and APB - - description: Pixel clock for the DPI/RGB input - minItems: 2 - - clock-names: - items: - - const: ref - - const: pclk - - const: px_clk - minItems: 2 + clocks: true + + clock-names: true resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml b/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml index 542193d77cdf..d3f84d220723 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml @@ -83,7 +83,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 911564468c5e..6ec6d287bff4 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -90,7 +90,7 @@ properties: properties: endpoint: - $ref: /schemas/graph.yaml#/$defs/endpoint-base + $ref: /schemas/media/video-interfaces.yaml# unevaluatedProperties: false properties: @@ -106,7 +106,6 @@ properties: description: If you have 1 logical lane the bridge supports routing to either port 0 or port 1. Port 0 is suggested. - See ../../media/video-interface.txt for details. - minItems: 2 maxItems: 2 @@ -118,7 +117,6 @@ properties: description: If you have 2 logical lanes the bridge supports reordering but only on physical ports 0 and 1. - See ../../media/video-interface.txt for details. - minItems: 4 maxItems: 4 @@ -132,7 +130,6 @@ properties: description: If you have 4 logical lanes the bridge supports reordering in any way. - See ../../media/video-interface.txt for details. lane-polarities: minItems: 1 @@ -141,7 +138,6 @@ properties: enum: - 0 - 1 - description: See ../../media/video-interface.txt dependencies: lane-polarities: [data-lanes] diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml index a412a1da950f..81ca3cbc7abe 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml @@ -51,7 +51,7 @@ additionalProperties: false examples: - | - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt deleted file mode 100644 index 8f9abf28a8fa..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt +++ /dev/null @@ -1,35 +0,0 @@ -TC358764 MIPI-DSI to LVDS panel bridge - -Required properties: - - compatible: "toshiba,tc358764" - - reg: the virtual channel number of a DSI peripheral - - vddc-supply: core voltage supply, 1.2V - - vddio-supply: I/O voltage supply, 1.8V or 3.3V - - vddlvds-supply: LVDS1/2 voltage supply, 3.3V - - reset-gpios: a GPIO spec for the reset pin - -The device node can contain following 'port' child nodes, -according to the OF graph bindings defined in [1]: - 0: DSI Input, not required, if the bridge is DSI controlled - 1: LVDS Output, mandatory - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - bridge@0 { - reg = <0>; - compatible = "toshiba,tc358764"; - vddc-supply = <&vcc_1v2_reg>; - vddio-supply = <&vcc_1v8_reg>; - vddlvds-supply = <&vcc_3v3_reg>; - reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>; - #address-cells = <1>; - #size-cells = <0>; - port@1 { - reg = <1>; - lvds_ep: endpoint { - remote-endpoint = <&panel_ep>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml new file mode 100644 index 000000000000..866607400514 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358764.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toshiba TC358764 MIPI-DSI to LVDS bridge + +maintainers: + - Andrzej Hajda <andrzej.hajda@intel.com> + +properties: + compatible: + const: toshiba,tc358764 + + reg: + description: Virtual channel number of a DSI peripheral + maxItems: 1 + + reset-gpios: + maxItems: 1 + + vddc-supply: + description: Core voltage supply, 1.2V + + vddio-supply: + description: I/O voltage supply, 1.8V or 3.3V + + vddlvds-supply: + description: LVDS1/2 voltage supply, 3.3V + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Video port for MIPI DSI input, if the bridge DSI controlled + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Video port for LVDS output (panel or connector). + + required: + - port@1 + +required: + - compatible + - reg + - reset-gpios + - vddc-supply + - vddio-supply + - vddlvds-supply + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@0 { + compatible = "toshiba,tc358764"; + reg = <0>; + + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>; + vddc-supply = <&vcc_1v2_reg>; + vddio-supply = <&vcc_1v8_reg>; + vddlvds-supply = <&vcc_3v3_reg>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + lvds_ep: endpoint { + remote-endpoint = <&panel_ep>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml index 140927884418..e1494b5007cb 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml @@ -23,7 +23,7 @@ properties: i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins clock-names: - const: "ref" + const: ref clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml index 0b6f5bef120f..779d8c57f854 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml @@ -87,7 +87,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml index 5e4afe9f98fb..0ece7b01790b 100644 --- a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml +++ b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml @@ -26,7 +26,7 @@ description: properties: $nodename: - const: "aux-bus" + const: aux-bus panel: $ref: panel/panel-common.yaml# diff --git a/Documentation/devicetree/bindings/display/dsi-controller.yaml b/Documentation/devicetree/bindings/display/dsi-controller.yaml index ca21671f6bdd..67ce10307ee0 100644 --- a/Documentation/devicetree/bindings/display/dsi-controller.yaml +++ b/Documentation/devicetree/bindings/display/dsi-controller.yaml @@ -30,6 +30,15 @@ properties: $nodename: pattern: "^dsi(@.*)?$" + clock-master: + type: boolean + description: + Should be enabled if the host is being used in conjunction with + another DSI host to drive the same peripheral. Hardware supporting + such a configuration generally requires the data on both the busses + to be driven by the same clock. Only the DSI host instance + controlling this clock should contain this property. + "#address-cells": const: 1 @@ -52,15 +61,6 @@ patternProperties: case the reg property can take multiple entries, one for each virtual channel that the peripheral responds to. - clock-master: - type: boolean - description: - Should be enabled if the host is being used in conjunction with - another DSI host to drive the same peripheral. Hardware supporting - such a configuration generally requires the data on both the busses - to be driven by the same clock. Only the DSI host instance - controlling this clock should contain this property. - enforce-video-mode: type: boolean description: diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt index 9b6cba3f82af..3a401590320f 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt @@ -50,7 +50,7 @@ Optional properties for dp-controller: Documentation/devicetree/bindings/display/panel/display-timing.txt For the below properties, please refer to Analogix DP binding document: - * Documentation/devicetree/bindings/display/bridge/analogix_dp.txt + * Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml -phys (required) -phy-names (required) -hpd-gpios (optional) diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt deleted file mode 100644 index be377786e8cd..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt +++ /dev/null @@ -1,90 +0,0 @@ -Exynos MIPI DSI Master - -Required properties: - - compatible: value should be one of the following - "samsung,exynos3250-mipi-dsi" /* for Exynos3250/3472 SoCs */ - "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */ - "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */ - "samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */ - "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */ - - reg: physical base address and length of the registers set for the device - - interrupts: should contain DSI interrupt - - clocks: list of clock specifiers, must contain an entry for each required - entry in clock-names - - clock-names: should include "bus_clk"and "sclk_mipi" entries - the use of "pll_clk" is deprecated - - phys: list of phy specifiers, must contain an entry for each required - entry in phy-names - - phy-names: should include "dsim" entry - - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V) - - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) - - samsung,pll-clock-frequency: specifies frequency of the oscillator clock - - #address-cells, #size-cells: should be set respectively to <1> and <0> - according to DSI host bindings (see MIPI DSI bindings [1]) - - samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst - mode - - samsung,esc-clock-frequency: specifies DSI frequency in escape mode - -Optional properties: - - power-domains: a phandle to DSIM power domain node - -Child nodes: - Should contain DSI peripheral nodes (see MIPI DSI bindings [1]). - -Video interfaces: - Device node can contain following video interface port nodes according to [2]: - 0: RGB input, - 1: DSI output - -[1]: Documentation/devicetree/bindings/display/mipi-dsi-bus.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - dsi@11c80000 { - compatible = "samsung,exynos4210-mipi-dsi"; - reg = <0x11C80000 0x10000>; - interrupts = <0 79 0>; - clocks = <&clock 286>, <&clock 143>; - clock-names = "bus_clk", "sclk_mipi"; - phys = <&mipi_phy 1>; - phy-names = "dsim"; - vddcore-supply = <&vusb_reg>; - vddio-supply = <&vmipi_reg>; - power-domains = <&pd_lcd0>; - #address-cells = <1>; - #size-cells = <0>; - samsung,pll-clock-frequency = <24000000>; - - panel@1 { - reg = <0>; - ... - port { - panel_ep: endpoint { - remote-endpoint = <&dsi_ep>; - }; - }; - }; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - decon_to_mic: endpoint { - remote-endpoint = <&mic_to_decon>; - }; - }; - - port@1 { - reg = <1>; - dsi_ep: endpoint { - reg = <0>; - samsung,burst-clock-frequency = <500000000>; - samsung,esc-clock-frequency = <20000000>; - remote-endpoint = <&panel_ep>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml index 35a8fff036ca..c2b29622bceb 100644 --- a/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml @@ -21,6 +21,9 @@ properties: - fsl,imx25-fb - fsl,imx27-fb - const: fsl,imx21-fb + - items: + - const: fsl,imx25-lcdc + - const: fsl,imx21-lcdc clocks: maxItems: 3 @@ -31,6 +34,9 @@ properties: - const: ahb - const: per + port: + $ref: /schemas/graph.yaml#/properties/port + display: $ref: /schemas/types.yaml#/definitions/phandle @@ -59,11 +65,35 @@ properties: description: LCDC Sharp Configuration Register value. +allOf: + - if: + properties: + compatible: + contains: + enum: + - fsl,imx1-lcdc + - fsl,imx21-lcdc + then: + properties: + display: false + fsl,dmacr: false + fsl,lpccr: false + fsl,lscr1: false + + required: + - port + + else: + properties: + port: false + + required: + - display + required: - compatible - clocks - clock-names - - display - interrupts - reg @@ -71,6 +101,20 @@ additionalProperties: false examples: - | + lcdc@53fbc000 { + compatible = "fsl,imx25-lcdc", "fsl,imx21-lcdc"; + reg = <0x53fbc000 0x4000>; + interrupts = <39>; + clocks = <&clks 103>, <&clks 66>, <&clks 49>; + clock-names = "ipg", "ahb", "per"; + + port { + parallel_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + - | imxfb: fb@10021000 { compatible = "fsl,imx21-fb"; interrupts = <61>; diff --git a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml index 989ab312c1f4..4ae6328cde64 100644 --- a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml @@ -2,8 +2,8 @@ # Copyright 2019 NXP %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: iMX8MQ Display Controller Subsystem (DCSS) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index b04820c95b22..8c2a737237f2 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -21,19 +21,15 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-ccorr - - items: - - const: mediatek,mt8192-disp-ccorr + - enum: + - mediatek,mt8183-disp-ccorr + - mediatek,mt8192-disp-ccorr - items: - enum: + - mediatek,mt8186-disp-ccorr - mediatek,mt8188-disp-ccorr - mediatek,mt8195-disp-ccorr - const: mediatek,mt8192-disp-ccorr - - items: - - enum: - - mediatek,mt8186-disp-ccorr - - const: mediatek,mt8192-disp-ccorr reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index 62306c88f485..d0ea77fc4b06 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -22,12 +22,10 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt2701-disp-color - - items: - - const: mediatek,mt8167-disp-color - - items: - - const: mediatek,mt8173-disp-color + - enum: + - mediatek,mt2701-disp-color + - mediatek,mt8167-disp-color + - mediatek,mt8173-disp-color - items: - enum: - mediatek,mt7623-disp-color diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 5c7445c174e5..1588b3f7cec7 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -22,8 +22,8 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-dither + - enum: + - mediatek,mt8183-disp-dither - items: - enum: - mediatek,mt8186-disp-dither diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml index 49248864514b..2cbdd9ee449d 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -20,8 +20,8 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8195-disp-dsc + - enum: + - mediatek,mt8195-disp-dsc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml new file mode 100644 index 000000000000..801fa66ae615 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml @@ -0,0 +1,182 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Ethdr Device + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: + ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and is + designed for HDR video and graphics conversion in the external display path. + It handles multiple HDR input types and performs tone mapping, color + space/color format conversion, and then combine different layers, + output the required HDR or SDR signal to the subsequent display path. + This engine is composed of two video frontends, two graphic frontends, + one video backend and a mixer. ETHDR has two DMA function blocks, DS and ADL. + These two function blocks read the pre-programmed registers from DRAM and + set them to HW in the v-blanking period. + +properties: + compatible: + const: mediatek,mt8195-disp-ethdr + + reg: + maxItems: 7 + + reg-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + + interrupts: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 2 + + clocks: + items: + - description: mixer clock + - description: video frontend 0 clock + - description: video frontend 1 clock + - description: graphic frontend 0 clock + - description: graphic frontend 1 clock + - description: video backend clock + - description: autodownload and menuload clock + - description: video frontend 0 async clock + - description: video frontend 1 async clock + - description: graphic frontend 0 async clock + - description: graphic frontend 1 async clock + - description: video backend async clock + - description: ethdr top clock + + clock-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + - const: ethdr_top + + power-domains: + maxItems: 1 + + resets: + items: + - description: video frontend 0 async reset + - description: video frontend 1 async reset + - description: graphic frontend 0 async reset + - description: graphic frontend 1 async reset + - description: video backend async reset + + reset-names: + items: + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + + mediatek,gce-client-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 7 + description: The register of display function block to be set by gce. + There are 4 arguments in this property, gce node, subsys id, offset and + register size. The subsys id is defined in the gce header of each chips + include/dt-bindings/gce/<chip>-gce.h, mapping to the register of display + function block. + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - power-domains + - resets + - mediatek,gce-client-reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8195-clk.h> + #include <dt-bindings/gce/mt8195-gce.h> + #include <dt-bindings/memory/mt8195-memory-port.h> + #include <dt-bindings/power/mt8195-power.h> + #include <dt-bindings/reset/mt8195-resets.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + hdr-engine@1c114000 { + compatible = "mediatek,mt8195-disp-ethdr"; + reg = <0 0x1c114000 0 0x1000>, + <0 0x1c115000 0 0x1000>, + <0 0x1c117000 0 0x1000>, + <0 0x1c119000 0 0x1000>, + <0 0x1c11a000 0 0x1000>, + <0 0x1c11b000 0 0x1000>, + <0 0x1c11c000 0 0x1000>; + reg-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds"; + mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0x4000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x5000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x7000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x9000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xa000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xb000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xc000 0x1000>; + clocks = <&vdosys1 CLK_VDO1_DISP_MIXER>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE>, + <&vdosys1 CLK_VDO1_26M_SLOW>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE_DL_ASYNC>, + <&topckgen CLK_TOP_ETHDR>; + clock-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds", "vdo_fe0_async", "vdo_fe1_async", + "gfx_fe0_async", "gfx_fe1_async","vdo_be_async", + "ethdr_top"; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; + iommus = <&iommu_vpp M4U_PORT_L3_HDR_DS>, + <&iommu_vpp M4U_PORT_L3_HDR_ADL>; + interrupts = <GIC_SPI 517 IRQ_TYPE_LEVEL_HIGH 0>; /* disp mixer */ + resets = <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC>; + reset-names = "vdo_fe0_async", "vdo_fe1_async", "gfx_fe0_async", + "gfx_fe1_async", "vdo_be_async"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index a5c6a91fac71..6c2be9d6840b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8173-disp-gamma - - items: - - const: mediatek,mt8183-disp-gamma + - enum: + - mediatek,mt8173-disp-gamma + - mediatek,mt8183-disp-gamma - items: - enum: - mediatek,mt8186-disp-gamma diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml index 8afdd67d6780..b90b6d18a828 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml @@ -50,7 +50,7 @@ properties: - const: hdmi mediatek,syscon-hdmi: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to system configuration registers diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index 69ba75777dac..2f8e2f4dc3b8 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8173-disp-merge - - items: - - const: mediatek,mt8195-disp-merge + - enum: + - mediatek,mt8173-disp-merge + - mediatek,mt8195-disp-merge reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml index 853fcb9db2be..29f9fa8f8219 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt2712-disp-od - - items: - - const: mediatek,mt8173-disp-od + - enum: + - mediatek,mt2712-disp-od + - mediatek,mt8173-disp-od reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml index 4e94f4e947ad..c7dd0ef02dcf 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml @@ -21,10 +21,9 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8183-disp-ovl-2l - - items: - - const: mediatek,mt8192-disp-ovl-2l + - enum: + - mediatek,mt8183-disp-ovl-2l + - mediatek,mt8192-disp-ovl-2l - items: - enum: - mediatek,mt8186-disp-ovl-2l diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index 065e526f950e..92e320d54ba2 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -21,14 +21,11 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt2701-disp-ovl - - items: - - const: mediatek,mt8173-disp-ovl - - items: - - const: mediatek,mt8183-disp-ovl - - items: - - const: mediatek,mt8192-disp-ovl + - enum: + - mediatek,mt2701-disp-ovl + - mediatek,mt8173-disp-ovl + - mediatek,mt8183-disp-ovl + - mediatek,mt8192-disp-ovl - items: - enum: - mediatek,mt7623-disp-ovl diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml index 27de64495401..11fe32e50a59 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml @@ -21,8 +21,8 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8192-disp-postmask + - enum: + - mediatek,mt8192-disp-postmask - items: - enum: - mediatek,mt8186-disp-postmask diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml index 3ade2ece3fed..42059efad45d 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml @@ -23,14 +23,11 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt2701-disp-rdma - - items: - - const: mediatek,mt8173-disp-rdma - - items: - - const: mediatek,mt8183-disp-rdma - - items: - - const: mediatek,mt8195-disp-rdma + - enum: + - mediatek,mt2701-disp-rdma + - mediatek,mt8173-disp-rdma + - mediatek,mt8183-disp-rdma + - mediatek,mt8195-disp-rdma - items: - enum: - mediatek,mt8188-disp-rdma diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml index 35ace1f322e8..21a4e96ecd93 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml @@ -21,8 +21,8 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8173-disp-split + - enum: + - mediatek,mt8173-disp-split reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml index b8bb135fe96b..62fad23a26f5 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml @@ -22,8 +22,8 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8173-disp-ufoe + - enum: + - mediatek,mt8173-disp-ufoe reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml index 7d7cc1ab526b..991183165d29 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml @@ -21,8 +21,8 @@ description: | properties: compatible: oneOf: - - items: - - const: mediatek,mt8173-disp-wdma + - enum: + - mediatek,mt8173-disp-wdma reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 0e8d8df686dc..f0c2237d5f82 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -15,16 +15,21 @@ description: | properties: compatible: - enum: - - qcom,sc7180-dp - - qcom,sc7280-dp - - qcom,sc7280-edp - - qcom,sc8180x-dp - - qcom,sc8180x-edp - - qcom,sc8280xp-dp - - qcom,sc8280xp-edp - - qcom,sdm845-dp - - qcom,sm8350-dp + oneOf: + - enum: + - qcom,sc7180-dp + - qcom,sc7280-dp + - qcom,sc7280-edp + - qcom,sc8180x-dp + - qcom,sc8180x-edp + - qcom,sc8280xp-dp + - qcom,sc8280xp-edp + - qcom,sdm845-dp + - qcom,sm8350-dp + - items: + - enum: + - qcom,sm8450-dp + - const: qcom,sm8350-dp reg: minItems: 4 diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index e75a3efe4dac..e6c1ebfe8a32 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -25,16 +25,16 @@ properties: - qcom,sc7280-dsi-ctrl - qcom,sdm660-dsi-ctrl - qcom,sdm845-dsi-ctrl + - qcom,sm6115-dsi-ctrl - qcom,sm8150-dsi-ctrl - qcom,sm8250-dsi-ctrl - qcom,sm8350-dsi-ctrl - qcom,sm8450-dsi-ctrl - qcom,sm8550-dsi-ctrl - const: qcom,mdss-dsi-ctrl - - items: - - enum: - - dsi-ctrl-6g-qcm2290 - - const: qcom,mdss-dsi-ctrl + - enum: + - qcom,dsi-ctrl-6g-qcm2290 + - qcom,mdss-dsi-ctrl # This should always come with an SoC-specific compatible deprecated: true reg: @@ -74,7 +74,7 @@ properties: syscon-sfpb: description: A phandle to mmss_sfpb syscon node (only for DSIv2). - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle qcom,dual-dsi-mode: type: boolean @@ -105,14 +105,14 @@ properties: type: object ports: - $ref: "/schemas/graph.yaml#/properties/ports" + $ref: /schemas/graph.yaml#/properties/ports description: | Contains DSI controller input and output ports as children, each containing one endpoint subnode. properties: port@0: - $ref: "/schemas/graph.yaml#/$defs/port-base" + $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false description: | Input endpoints of the controller. @@ -128,7 +128,7 @@ properties: enum: [ 0, 1, 2, 3 ] port@1: - $ref: "/schemas/graph.yaml#/$defs/port-base" + $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false description: | Output endpoints of the controller. @@ -351,6 +351,7 @@ allOf: contains: enum: - qcom,sdm845-dsi-ctrl + - qcom,sm6115-dsi-ctrl then: properties: clocks: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml index 3ec466c3ab38..e6b00d7387ce 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -58,7 +58,7 @@ properties: maximum: 31 qcom,phy-drive-ldo-level: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: The PHY LDO has an amplitude tuning feature to adjust the LDO output for the HSTX drive. Use supported levels (mV) to offset the drive level diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml index ab14e81cb050..029d72822d8b 100644 --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml @@ -3,8 +3,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/msm/gmu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/msm/gmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: GMU attached to certain Adreno GPUs diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml index d4191cca71fb..5dabe7b6794b 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/msm/gpu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/msm/gpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Adreno or Snapdragon GPUs diff --git a/Documentation/devicetree/bindings/display/msm/mdp4.yaml b/Documentation/devicetree/bindings/display/msm/mdp4.yaml index 58c13f5277b6..35204a287579 100644 --- a/Documentation/devicetree/bindings/display/msm/mdp4.yaml +++ b/Documentation/devicetree/bindings/display/msm/mdp4.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/msm/mdp4.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/msm/mdp4.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Adreno/Snapdragon MDP4 display controller diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml index ef461ad6ce4a..a763cf8da122 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdp5.yaml @@ -61,7 +61,7 @@ properties: - const: lut - const: tbu - const: tbu_rt - #MSM8996 has additional iommu clock + # MSM8996 has additional iommu clock - items: - const: iface - const: bus diff --git a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml index 20889e409430..b0100105e428 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,mdss.yaml @@ -101,6 +101,7 @@ required: patternProperties: "^display-controller@[1-9a-f][0-9a-f]*$": type: object + additionalProperties: true properties: compatible: contains: @@ -108,6 +109,7 @@ patternProperties: "^dsi@[1-9a-f][0-9a-f]*$": type: object + additionalProperties: true properties: compatible: contains: @@ -115,6 +117,7 @@ patternProperties: "^phy@[1-9a-f][0-9a-f]*$": type: object + additionalProperties: true properties: compatible: enum: @@ -132,6 +135,7 @@ patternProperties: "^hdmi-tx@[1-9a-f][0-9a-f]*$": type: object + additionalProperties: true properties: compatible: enum: diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml index 2491cb100b33..b9f83088f370 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml @@ -40,7 +40,13 @@ patternProperties: type: object properties: compatible: - const: qcom,dsi-ctrl-6g-qcm2290 + oneOf: + - items: + - const: qcom,sm6115-dsi-ctrl + - const: qcom,mdss-dsi-ctrl + - description: Old binding, please don't use + deprecated: true + const: qcom,dsi-ctrl-6g-qcm2290 "^phy@[0-9a-f]+$": type: object @@ -114,7 +120,7 @@ examples: }; dsi@5e94000 { - compatible = "qcom,dsi-ctrl-6g-qcm2290"; + compatible = "qcom,sm6115-dsi-ctrl", "qcom,mdss-dsi-ctrl"; reg = <0x05e94000 0x400>; reg-names = "dsi_ctrl"; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml index 4c6929e2534c..f26eb5643aed 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml @@ -54,7 +54,7 @@ patternProperties: type: object properties: compatible: - const: qcom,dsi-phy-5nm-8450 + const: qcom,sm8450-dsi-phy-5nm required: - compatible @@ -254,7 +254,7 @@ examples: }; dsi0_phy: phy@ae94400 { - compatible = "qcom,dsi-phy-5nm-8450"; + compatible = "qcom,sm8450-dsi-phy-5nm"; reg = <0x0ae94400 0x200>, <0x0ae94600 0x280>, <0x0ae94900 0x260>; @@ -325,7 +325,7 @@ examples: }; dsi1_phy: phy@ae96400 { - compatible = "qcom,dsi-phy-5nm-8450"; + compatible = "qcom,sm8450-dsi-phy-5nm"; reg = <0x0ae96400 0x200>, <0x0ae96600 0x280>, <0x0ae96900 0x260>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml new file mode 100644 index 000000000000..ff58a747bb6f --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,sm8550-dpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM8550 Display DPU + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +$ref: /schemas/display/msm/dpu-common.yaml# + +properties: + compatible: + const: qcom,sm8550-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display AHB + - description: Display hf axi + - description: Display MDSS ahb + - description: Display lut + - description: Display core + - description: Display vsync + + clock-names: + items: + - const: bus + - const: nrt_bus + - const: iface + - const: lut + - const: core + - const: vsync + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm8550-dispcc.h> + #include <dt-bindings/clock/qcom,sm8550-gcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-controller@ae01000 { + compatible = "qcom,sm8550-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", + "nrt_bus", + "iface", + "lut", + "core", + "vsync"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmhpd SM8550_MMCX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + dpu_intf2_out: endpoint { + remote-endpoint = <&dsi1_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-325000000 { + opp-hz = /bits/ 64 <325000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-375000000 { + opp-hz = /bits/ 64 <375000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-514000000 { + opp-hz = /bits/ 64 <514000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml new file mode 100644 index 000000000000..887be33ba108 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml @@ -0,0 +1,333 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,sm8550-mdss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM8550 Display MDSS + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +description: + SM8550 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like + DPU display controller, DSI and DP interfaces etc. + +$ref: /schemas/display/msm/mdss-common.yaml# + +properties: + compatible: + const: qcom,sm8550-mdss + + clocks: + items: + - description: Display MDSS AHB + - description: Display AHB + - description: Display hf AXI + - description: Display core + + iommus: + maxItems: 1 + + interconnects: + maxItems: 2 + + interconnect-names: + maxItems: 2 + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + properties: + compatible: + const: qcom,sm8550-dpu + + "^dsi@[0-9a-f]+$": + type: object + properties: + compatible: + items: + - const: qcom,sm8550-dsi-ctrl + - const: qcom,mdss-dsi-ctrl + + "^phy@[0-9a-f]+$": + type: object + properties: + compatible: + const: qcom,sm8550-dsi-phy-4nm + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm8550-dispcc.h> + #include <dt-bindings/clock/qcom,sm8550-gcc.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-subsystem@ae00000 { + compatible = "qcom,sm8550-mdss"; + 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"; + + resets = <&dispcc DISP_CC_MDSS_CORE_BCR>; + + power-domains = <&dispcc MDSS_GDSC>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "bus", "nrt_bus", "core"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + iommus = <&apps_smmu 0x1c00 0x2>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,sm8550-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", + "nrt_bus", + "iface", + "lut", + "core", + "vsync"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmhpd SM8550_MMCX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + dpu_intf2_out: endpoint { + remote-endpoint = <&dsi1_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-325000000 { + opp-hz = /bits/ 64 <325000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-375000000 { + opp-hz = /bits/ 64 <375000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-514000000 { + opp-hz = /bits/ 64 <514000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + }; + + dsi@ae94000 { + compatible = "qcom,sm8550-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x0ae94000 0x400>; + reg-names = "dsi_ctrl"; + + interrupt-parent = <&mdss>; + interrupts = <4>; + + clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>, + <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK>, + <&dispcc DISP_CC_MDSS_ESC0_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>; + assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>; + + operating-points-v2 = <&dsi_opp_table>; + power-domains = <&rpmhpd SM8550_MMCX>; + + phys = <&dsi0_phy>; + phy-names = "dsi"; + + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi0_in: endpoint { + remote-endpoint = <&dpu_intf1_out>; + }; + }; + + port@1 { + reg = <1>; + dsi0_out: endpoint { + }; + }; + }; + + dsi_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-187500000 { + opp-hz = /bits/ 64 <187500000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-300000000 { + opp-hz = /bits/ 64 <300000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-358000000 { + opp-hz = /bits/ 64 <358000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + }; + }; + + dsi0_phy: phy@ae94400 { + compatible = "qcom,sm8550-dsi-phy-4nm"; + reg = <0x0ae95000 0x200>, + <0x0ae95200 0x280>, + <0x0ae95500 0x400>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; + + dsi@ae96000 { + compatible = "qcom,sm8550-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x0ae96000 0x400>; + reg-names = "dsi_ctrl"; + + interrupt-parent = <&mdss>; + interrupts = <5>; + + clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>, + <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>, + <&dispcc DISP_CC_MDSS_PCLK1_CLK>, + <&dispcc DISP_CC_MDSS_ESC1_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>, + <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>; + assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>; + + operating-points-v2 = <&dsi_opp_table>; + power-domains = <&rpmhpd SM8550_MMCX>; + + phys = <&dsi1_phy>; + phy-names = "dsi"; + + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi1_in: endpoint { + remote-endpoint = <&dpu_intf2_out>; + }; + }; + + port@1 { + reg = <1>; + dsi1_out: endpoint { + }; + }; + }; + }; + + dsi1_phy: phy@ae96400 { + compatible = "qcom,sm8550-dsi-phy-4nm"; + reg = <0x0ae97000 0x200>, + <0x0ae97200 0x280>, + <0x0ae97500 0x400>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml index 3a8c2c11f9bd..f6fea9085aab 100644 --- a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml @@ -12,7 +12,7 @@ maintainers: allOf: - $ref: panel-common.yaml# - - $ref: /schemas/display/lvds.yaml/# + - $ref: /schemas/display/lvds.yaml# select: properties: diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index a2384bd74cf2..aed55608ebf6 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml @@ -30,6 +30,8 @@ properties: - boe,tv110c9m-ll3 # INX HJ110IZ-01A 10.95" WUXGA TFT LCD panel - innolux,hj110iz-01a + # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel + - starry,2081101qfh032011-53g reg: description: the virtual channel number of a DSI peripheral @@ -53,6 +55,7 @@ properties: description: phandle of the backlight device attached to the panel port: true + rotation: true required: - compatible diff --git a/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml b/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml index 7adb83e2e8d9..265ab6d30572 100644 --- a/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml +++ b/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml @@ -17,7 +17,9 @@ properties: const: elida,kd35t133 reg: true backlight: true + port: true reset-gpios: true + rotation: true iovcc-supply: description: regulator that supplies the iovcc voltage vdd-supply: @@ -27,6 +29,7 @@ required: - compatible - reg - backlight + - port - iovcc-supply - vdd-supply @@ -43,6 +46,12 @@ examples: backlight = <&backlight>; iovcc-supply = <&vcc_1v8>; vdd-supply = <&vcc3v3_lcd>; + + port { + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml index 1cf84c8dd85e..92df69e80a82 100644 --- a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml +++ b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml @@ -26,6 +26,7 @@ properties: dvdd-supply: description: 3v3 digital regulator + port: true reset-gpios: true backlight: true @@ -35,6 +36,7 @@ required: - reg - avdd-supply - dvdd-supply + - port additionalProperties: false @@ -53,5 +55,11 @@ examples: dvdd-supply = <®_dldo2>; reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ backlight = <&backlight>; + + port { + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml index 566e11f6bfc0..ab6b7be88341 100644 --- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml +++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml @@ -12,7 +12,7 @@ maintainers: allOf: - $ref: panel-common.yaml# - - $ref: /schemas/display/lvds.yaml/# + - $ref: /schemas/display/lvds.yaml# select: properties: diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml deleted file mode 100644 index 243dac2416f3..000000000000 --- a/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml +++ /dev/null @@ -1,43 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/display/panel/innolux,p120zdg-bf1.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel - -maintainers: - - Sandeep Panda <spanda@codeaurora.org> - - Douglas Anderson <dianders@chromium.org> - -allOf: - - $ref: panel-common.yaml# - -properties: - compatible: - const: innolux,p120zdg-bf1 - - enable-gpios: true - power-supply: true - backlight: true - no-hpd: true - -required: - - compatible - - power-supply - -additionalProperties: false - -examples: - - | - #include <dt-bindings/gpio/gpio.h> - - panel_edp: panel-edp { - compatible = "innolux,p120zdg-bf1"; - enable-gpios = <&msmgpio 31 GPIO_ACTIVE_LOW>; - power-supply = <&pm8916_l2>; - backlight = <&backlight>; - no-hpd; - }; - -... diff --git a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml index c06902e4fe70..41eb7fbf7715 100644 --- a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml +++ b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml @@ -17,6 +17,8 @@ properties: items: - enum: - chongzhou,cz101b4001 + - radxa,display-10hd-ad001 + - radxa,display-8hd-ad002 - const: jadard,jd9365da-h3 reg: true diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml index 5cf3c588f46d..3623ffa6518d 100644 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml @@ -12,7 +12,7 @@ maintainers: allOf: - $ref: panel-common.yaml# - - $ref: /schemas/display/lvds.yaml/# + - $ref: /schemas/display/lvds.yaml# select: properties: diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml index 54750cc5440d..37f01d847aac 100644 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml @@ -12,7 +12,7 @@ maintainers: allOf: - $ref: panel-common.yaml# - - $ref: /schemas/display/lvds.yaml/# + - $ref: /schemas/display/lvds.yaml# select: properties: diff --git a/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml index 3b09b359023e..accf933d6e46 100644 --- a/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml +++ b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml @@ -41,7 +41,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml new file mode 100644 index 000000000000..0039561ef04c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/novatek,nt36523.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Novatek NT36523 based DSI display Panels + +maintainers: + - Jianhua Lu <lujianhua000@gmail.com> + +description: | + The Novatek NT36523 is a generic DSI Panel IC used to drive dsi + panels. Support video mode panels from China Star Optoelectronics + Technology (CSOT) and BOE Technology. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + - xiaomi,elish-boe-nt36523 + - xiaomi,elish-csot-nt36523 + - const: novatek,nt36523 + + reset-gpios: + maxItems: 1 + description: phandle of gpio for reset line - This should be 8mA + + vddio-supply: + description: regulator that supplies the I/O voltage + + reg: true + ports: true + backlight: true + +required: + - compatible + - reg + - vddio-supply + - reset-gpios + - ports + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "xiaomi,elish-csot-nt36523", "novatek,nt36523"; + reg = <0>; + + vddio-supply = <&vreg_l14a_1p88>; + reset-gpios = <&tlmm 75 GPIO_ACTIVE_LOW>; + backlight = <&backlight>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + panel_in_0: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1{ + reg = <1>; + panel_in_1: endpoint { + remote-endpoint = <&dsi1_out>; + }; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml index 41ee3157a1cd..ae821f465e1c 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml @@ -34,7 +34,7 @@ properties: description: phandle of gpio for reset line - This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names (active high) - vddi0-supply: + vddio-supply: description: phandle of the regulator that provides the supply voltage Power IC supply @@ -51,7 +51,7 @@ properties: required: - compatible - reg - - vddi0-supply + - vddio-supply - vddpos-supply - vddneg-supply - reset-gpios @@ -70,7 +70,7 @@ examples: panel@0 { compatible = "tianma,fhd-video", "novatek,nt36672a"; reg = <0>; - vddi0-supply = <&vreg_l14a_1p88>; + vddio-supply = <&vreg_l14a_1p88>; vddpos-supply = <&lab>; vddneg-supply = <&ibb>; diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml index c77ee034310a..929fe046d1e7 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -12,7 +12,7 @@ maintainers: allOf: - $ref: panel-common.yaml# - - $ref: /schemas/display/lvds.yaml/# + - $ref: /schemas/display/lvds.yaml# select: properties: diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index 2c00813f5d20..90c04cff8281 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -19,9 +19,6 @@ description: | If the panel is more advanced a dedicated binding file is required. -allOf: - - $ref: panel-common.yaml# - properties: compatible: @@ -67,12 +64,31 @@ properties: reset-gpios: true port: true power-supply: true + vddio-supply: true + +allOf: + - $ref: panel-common.yaml# + - if: + properties: + compatible: + enum: + - samsung,s6e3fc2x01 + - samsung,sofef00 + then: + properties: + power-supply: false + required: + - vddio-supply + else: + properties: + vddio-supply: false + required: + - power-supply additionalProperties: false required: - compatible - - power-supply - reg examples: diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 18241f4051d2..01560fe226dd 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -192,6 +192,8 @@ properties: - innolux,n125hce-gn1 # InnoLux 15.6" WXGA TFT LCD panel - innolux,n156bge-l21 + # Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel + - innolux,p120zdg-bf1 # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel - innolux,zj070na-01p # King & Display KD116N21-30NV-A010 eDP TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml index 0d317e61edd8..aea69b84ca5d 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml @@ -17,29 +17,29 @@ description: | The parameters are defined as seen in the following illustration. - +----------+-------------------------------------+----------+-------+ - | | ^ | | | - | | |vback_porch | | | - | | v | | | - +----------#######################################----------+-------+ - | # ^ # | | - | # | # | | - | hback # | # hfront | hsync | - | porch # | hactive # porch | len | - |<-------->#<-------+--------------------------->#<-------->|<----->| - | # | # | | - | # |vactive # | | - | # | # | | - | # v # | | - +----------#######################################----------+-------+ - | | ^ | | | - | | |vfront_porch | | | - | | v | | | - +----------+-------------------------------------+----------+-------+ - | | ^ | | | - | | |vsync_len | | | - | | v | | | - +----------+-------------------------------------+----------+-------+ + +-------+----------+-------------------------------------+----------+ + | | | ^ | | + | | | |vsync_len | | + | | | v | | + +-------+----------+-------------------------------------+----------+ + | | | ^ | | + | | | |vback_porch | | + | | | v | | + +-------+----------#######################################----------+ + | | # ^ # | + | | # | # | + | hsync | hback # | # hfront | + | len | porch # | hactive # porch | + |<----->|<-------->#<-------+--------------------------->#<-------->| + | | # | # | + | | # |vactive # | + | | # | # | + | | # v # | + +-------+----------#######################################----------+ + | | | ^ | | + | | | |vfront_porch | | + | | | v | | + +-------+----------+-------------------------------------+----------+ The following is the panel timings shown with time on the x-axis. diff --git a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml index d67617f6f74a..95ce22c6787a 100644 --- a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml +++ b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml @@ -37,7 +37,7 @@ properties: backlight: description: Backlight used by the panel - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle required: - compatible diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml new file mode 100644 index 000000000000..58fa073ce258 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,ams495qa01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung AMS495QA01 panel with Magnachip D53E6EA8966 controller + +maintainers: + - Chris Morgan <macromorgan@hotmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,ams495qa01 + + reg: true + reset-gpios: + description: reset gpio, must be GPIO_ACTIVE_LOW + elvdd-supply: + description: regulator that supplies voltage to the panel display + enable-gpios: true + port: true + vdd-supply: + description: regulator that supplies voltage to panel logic + +required: + - compatible + - reg + - reset-gpios + - vdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "samsung,ams495qa01"; + reg = <0>; + reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; + vdd-supply = <&vcc_3v3>; + + port { + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml index 44ce98f68705..b749e9e906b7 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml @@ -16,6 +16,7 @@ properties: compatible: const: samsung,s6e88a0-ams452ef01 reg: true + port: true reset-gpios: true vdd3-supply: description: core voltage supply @@ -25,6 +26,7 @@ properties: required: - compatible - reg + - port - vdd3-supply - vci-supply - reset-gpios @@ -46,5 +48,11 @@ examples: vdd3-supply = <&pm8916_l17>; vci-supply = <®_vlcd_vci>; reset-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml index cfaa50cf5f5d..1df3cbb51ff9 100644 --- a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml +++ b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel maintainers: - - Marco Franchi <marco.franchi@nxp.com> + - Fabio Estevam <festevam@gmail.com> allOf: - $ref: panel-common.yaml# @@ -25,6 +25,8 @@ properties: avdd-supply: description: 5v analog regulator + enable-gpios: true + required: - compatible - dvdd-supply diff --git a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml index 2e75e3738ff0..e32d9188a3e0 100644 --- a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml +++ b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml @@ -12,7 +12,7 @@ maintainers: allOf: - $ref: panel-common.yaml# - - $ref: /schemas/display/lvds.yaml/# + - $ref: /schemas/display/lvds.yaml# select: properties: diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml index 9ec0e8aae4c6..57b44a0e763d 100644 --- a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml @@ -34,8 +34,8 @@ properties: - items: - const: sharp,lq101r1sx03 - const: sharp,lq101r1sx01 - - items: - - const: sharp,lq101r1sx01 + - enum: + - sharp,lq101r1sx01 reg: true power-supply: true diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml index 34d5e20c6cb3..4dc0cd4a6a77 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml @@ -28,6 +28,7 @@ properties: items: - enum: - densitron,dmt028vghmcmi-1a + - elida,kd50t048a - techstar,ts8550b - const: sitronix,st7701 @@ -41,7 +42,9 @@ properties: IOVCC-supply: description: I/O system regulator + port: true reset-gpios: true + rotation: true backlight: true @@ -50,6 +53,7 @@ required: - reg - VCC-supply - IOVCC-supply + - port - reset-gpios additionalProperties: false @@ -69,5 +73,11 @@ examples: IOVCC-supply = <®_dldo2>; reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ backlight = <&backlight>; + + port { + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml index d984b59daa4a..fa6556363cca 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml @@ -26,6 +26,10 @@ properties: spi-cpha: true spi-cpol: true + dc-gpios: + maxItems: 1 + description: DCX pin, Display data/command selection pin in parallel interface + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml b/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml new file mode 100644 index 000000000000..b6b885b4c22d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sony,td4353-jdi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sony TD4353 JDI 5 / 5.7" 2160x1080 MIPI-DSI Panel + +maintainers: + - Konrad Dybcio <konrad.dybcio@somainline.org> + +description: | + The Sony TD4353 JDI is a 5 (XZ2c) / 5.7 (XZ2) inch 2160x1080 + MIPI-DSI panel, used in Xperia XZ2 and XZ2 Compact smartphones. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sony,td4353-jdi-tama + + reg: true + + backlight: true + + vddio-supply: + description: VDDIO 1.8V supply + + vsp-supply: + description: Positive 5.5V supply + + vsn-supply: + description: Negative 5.5V supply + + panel-reset-gpios: + description: Display panel reset pin + + touch-reset-gpios: + description: Touch panel reset pin + + port: true + +required: + - compatible + - reg + - vddio-supply + - vsp-supply + - vsn-supply + - panel-reset-gpios + - touch-reset-gpios + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel: panel@0 { + compatible = "sony,td4353-jdi-tama"; + reg = <0>; + + backlight = <&pmi8998_wled>; + vddio-supply = <&vreg_l14a_1p8>; + vsp-supply = <&lab>; + vsn-supply = <&ibb>; + panel-reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>; + touch-reset-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml index 481ef051df1e..444ac2a4772d 100644 --- a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml +++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml @@ -19,6 +19,8 @@ properties: compatible: const: visionox,rm69299-1080p-display + reg: true + vdda-supply: description: | Phandle of the regulator that provides the vdda supply voltage. @@ -34,6 +36,7 @@ additionalProperties: false required: - compatible + - reg - vdda-supply - vdd3p3-supply - reset-gpios @@ -41,16 +44,22 @@ required: examples: - | - panel { - compatible = "visionox,rm69299-1080p-display"; + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "visionox,rm69299-1080p-display"; + reg = <0>; - vdda-supply = <&src_pp1800_l8c>; - vdd3p3-supply = <&src_pp2800_l18a>; + vdda-supply = <&src_pp1800_l8c>; + vdd3p3-supply = <&src_pp2800_l18a>; - reset-gpios = <&pm6150l_gpio 3 0>; - port { - panel0_in: endpoint { - remote-endpoint = <&dsi0_out>; + reset-gpios = <&pm6150l_gpio 3 0>; + port { + panel0_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml index d5c46a3cc2b0..c407deb6afb1 100644 --- a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml +++ b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml @@ -17,6 +17,7 @@ properties: const: xinpeng,xpp055c272 reg: true backlight: true + port: true reset-gpios: true iovcc-supply: description: regulator that supplies the iovcc voltage @@ -27,6 +28,7 @@ required: - compatible - reg - backlight + - port - iovcc-supply - vci-supply @@ -44,6 +46,12 @@ examples: backlight = <&backlight>; iovcc-supply = <&vcc_1v8>; vci-supply = <&vcc3v3_lcd>; + + port { + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index d4830f52c512..c5b9e6812bce 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -76,7 +76,7 @@ properties: unevaluatedProperties: false renesas,cmms: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: maxItems: 1 description: @@ -84,7 +84,7 @@ properties: available DU channel. renesas,vsps: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: items: - description: phandle to VSP instance that serves the DU channel diff --git a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt deleted file mode 100644 index 43561584c13a..000000000000 --- a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt +++ /dev/null @@ -1,98 +0,0 @@ -Rockchip RK3288 specific extensions to the Analogix Display Port -================================ - -Required properties: -- compatible: "rockchip,rk3288-dp", - "rockchip,rk3399-edp"; - -- reg: physical base address of the controller and length - -- clocks: from common clock binding: handle to dp clock. - of memory mapped region. - -- clock-names: from common clock binding: - Required elements: "dp" "pclk" - -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - -- pinctrl-names: Names corresponding to the chip hotplug pinctrl states. -- pinctrl-0: pin-control mode. should be <&edp_hpd> - -- reset-names: Must include the name "dp" - -- rockchip,grf: this soc should set GRF regs, so need get grf here. - -- ports: there are 2 port nodes with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. - Port 0: contained 2 endpoints, connecting to the output of vop. - Port 1: contained 1 endpoint, connecting to the input of panel. - -Optional property for different chips: -- clocks: from common clock binding: handle to grf_vio clock. - -- clock-names: from common clock binding: - Required elements: "grf" - -For the below properties, please refer to Analogix DP binding document: - * Documentation/devicetree/bindings/display/bridge/analogix_dp.txt -- phys (required) -- phy-names (required) -- hpd-gpios (optional) -- force-hpd (optional) -------------------------------------------------------------------------------- - -Example: - dp-controller: dp@ff970000 { - compatible = "rockchip,rk3288-dp"; - reg = <0xff970000 0x4000>; - interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>; - clock-names = "dp", "pclk"; - phys = <&dp_phy>; - phy-names = "dp"; - - rockchip,grf = <&grf>; - resets = <&cru 111>; - reset-names = "dp"; - - pinctrl-names = "default"; - pinctrl-0 = <&edp_hpd>; - - - ports { - #address-cells = <1>; - #size-cells = <0>; - edp_in: port@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - edp_in_vopb: endpoint@0 { - reg = <0>; - remote-endpoint = <&vopb_out_edp>; - }; - edp_in_vopl: endpoint@1 { - reg = <1>; - remote-endpoint = <&vopl_out_edp>; - }; - }; - - edp_out: port@1 { - reg = <1>; - #address-cells = <1>; - #size-cells = <0>; - edp_out_panel: endpoint { - reg = <0>; - remote-endpoint = <&panel_in_edp> - }; - }; - }; - }; - - pinctrl { - edp { - edp_hpd: edp-hpd { - rockchip,pins = <7 11 RK_FUNC_2 &pcfg_pull_none>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt deleted file mode 100644 index 9a223df8530c..000000000000 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ /dev/null @@ -1,94 +0,0 @@ -Rockchip specific extensions to the Synopsys Designware MIPI DSI -================================ - -Required properties: -- #address-cells: Should be <1>. -- #size-cells: Should be <0>. -- compatible: one of - "rockchip,px30-mipi-dsi", "snps,dw-mipi-dsi" - "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi" - "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi" - "rockchip,rk3568-mipi-dsi", "snps,dw-mipi-dsi" -- reg: Represent the physical address range of the controller. -- interrupts: Represent the controller's interrupt to the CPU(s). -- clocks, clock-names: Phandles to the controller's pll reference - clock(ref) when using an internal dphy and APB clock(pclk). - For RK3399, a phy config clock (phy_cfg) and a grf clock(grf) - are required. As described in [1]. -- rockchip,grf: this soc should set GRF regs to mux vopl/vopb. -- ports: contain a port node with endpoint definitions as defined in [2]. - For vopb,set the reg = <0> and set the reg = <1> for vopl. -- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl -- video port 1 for either a panel or subsequent encoder - -Optional properties: -- phys: from general PHY binding: the phandle for the PHY device. -- phy-names: Should be "dphy" if phys references an external phy. -- #phy-cells: Defined when used as ISP phy, should be 0. -- power-domains: a phandle to mipi dsi power domain node. -- resets: list of phandle + reset specifier pairs, as described in [3]. -- reset-names: string reset name, must be "apb". - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/media/video-interfaces.txt -[3] Documentation/devicetree/bindings/reset/reset.txt - -Example: - mipi_dsi: mipi@ff960000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi"; - reg = <0xff960000 0x4000>; - interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru SCLK_MIPI_24M>, <&cru PCLK_MIPI_DSI0>; - clock-names = "ref", "pclk"; - resets = <&cru SRST_MIPIDSI0>; - reset-names = "apb"; - rockchip,grf = <&grf>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - mipi_in: port@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - mipi_in_vopb: endpoint@0 { - reg = <0>; - remote-endpoint = <&vopb_out_mipi>; - }; - mipi_in_vopl: endpoint@1 { - reg = <1>; - remote-endpoint = <&vopl_out_mipi>; - }; - }; - - mipi_out: port@1 { - reg = <1>; - #address-cells = <1>; - #size-cells = <0>; - - mipi_out_panel: endpoint { - remote-endpoint = <&panel_in_mipi>; - }; - }; - }; - - panel { - compatible ="boe,tv080wum-nl0"; - reg = <0>; - - enable-gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>; - pinctrl-names = "default"; - pinctrl-0 = <&lcd_en>; - backlight = <&backlight>; - - port { - panel_in_mipi: endpoint { - remote-endpoint = <&mipi_out_panel>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml new file mode 100644 index 000000000000..60dedf9b2be7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip specific extensions to the Analogix Display Port + +maintainers: + - Sandy Huang <hjc@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + enum: + - rockchip,rk3288-dp + - rockchip,rk3399-edp + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + items: + - const: dp + - const: pclk + - const: grf + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: dp + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + This SoC makes use of GRF regs. + +required: + - compatible + - clocks + - clock-names + - resets + - reset-names + - rockchip,grf + +allOf: + - $ref: /schemas/display/bridge/analogix,dp.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3288-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + dp@ff970000 { + compatible = "rockchip,rk3288-dp"; + reg = <0xff970000 0x4000>; + interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>; + clock-names = "dp", "pclk"; + phys = <&dp_phy>; + phy-names = "dp"; + resets = <&cru 111>; + reset-names = "dp"; + rockchip,grf = <&grf>; + pinctrl-0 = <&edp_hpd>; + pinctrl-names = "default"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + edp_in: port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + edp_in_vopb: endpoint@0 { + reg = <0>; + remote-endpoint = <&vopb_out_edp>; + }; + edp_in_vopl: endpoint@1 { + reg = <1>; + remote-endpoint = <&vopl_out_edp>; + }; + }; + + edp_out: port@1 { + reg = <1>; + + edp_out_panel: endpoint { + remote-endpoint = <&panel_in_edp>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml new file mode 100644 index 000000000000..8e8a40879140 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml @@ -0,0 +1,166 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-mipi-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip specific extensions to the Synopsys Designware MIPI DSI + +maintainers: + - Sandy Huang <hjc@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + items: + - enum: + - rockchip,px30-mipi-dsi + - rockchip,rk3288-mipi-dsi + - rockchip,rk3399-mipi-dsi + - rockchip,rk3568-mipi-dsi + - const: snps,dw-mipi-dsi + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + oneOf: + - minItems: 2 + items: + - const: ref + - const: pclk + - const: phy_cfg + - const: grf + - const: pclk + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + This SoC uses GRF regs to switch between vopl/vopb. + + phys: + maxItems: 1 + + phy-names: + const: dphy + + "#phy-cells": + const: 0 + description: + Defined when in use as ISP phy. + + power-domains: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +required: + - compatible + - clocks + - clock-names + - rockchip,grf + +allOf: + - $ref: /schemas/display/bridge/snps,dw-mipi-dsi.yaml# + - if: + properties: + compatible: + contains: + enum: + - rockchip,px30-mipi-dsi + - rockchip,rk3568-mipi-dsi + + then: + properties: + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + required: + - phys + - phy-names + + - if: + properties: + compatible: + contains: + const: rockchip,rk3288-mipi-dsi + + then: + properties: + clocks: + maxItems: 2 + + clock-names: + maxItems: 2 + + - if: + properties: + compatible: + contains: + const: rockchip,rk3399-mipi-dsi + + then: + properties: + clocks: + minItems: 4 + + clock-names: + minItems: 4 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3288-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + mipi_dsi: dsi@ff960000 { + compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi"; + reg = <0xff960000 0x4000>; + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_MIPIDSI_24M>, <&cru PCLK_MIPI_DSI0>; + clock-names = "ref", "pclk"; + resets = <&cru SRST_MIPIDSI0>; + reset-names = "apb"; + rockchip,grf = <&grf>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + mipi_in: port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + mipi_in_vopb: endpoint@0 { + reg = <0>; + remote-endpoint = <&vopb_out_mipi>; + }; + mipi_in_vopl: endpoint@1 { + reg = <1>; + remote-endpoint = <&vopl_out_mipi>; + }; + }; + + mipi_out: port@1 { + reg = <1>; + + mipi_out_panel: endpoint { + remote-endpoint = <&panel_in_mipi>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml new file mode 100644 index 000000000000..03b002a05c47 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml @@ -0,0 +1,170 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip low-voltage differential signal (LVDS) transmitter + +maintainers: + - Sandy Huang <hjc@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + enum: + - rockchip,px30-lvds + - rockchip,rk3288-lvds + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: pclk_lvds + + avdd1v0-supply: + description: 1.0V analog power. + + avdd1v8-supply: + description: 1.8V analog power. + + avdd3v3-supply: + description: 3.3V analog power. + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the general register files syscon. + + rockchip,output: + $ref: /schemas/types.yaml#/definitions/string + enum: [rgb, lvds, duallvds] + description: This describes the output interface. + + phys: + maxItems: 1 + + phy-names: + const: dphy + + pinctrl-names: + const: lcdc + + pinctrl-0: true + + power-domains: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Video port 0 for the VOP input. + The remote endpoint maybe vopb or vopl. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Video port 1 for either a panel or subsequent encoder. + + required: + - port@0 + - port@1 + +required: + - compatible + - rockchip,grf + - rockchip,output + - ports + +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,px30-lvds + + then: + properties: + reg: false + clocks: false + clock-names: false + avdd1v0-supply: false + avdd1v8-supply: false + avdd3v3-supply: false + + required: + - phys + - phy-names + + - if: + properties: + compatible: + contains: + const: rockchip,rk3288-lvds + + then: + properties: + phys: false + phy-names: false + + required: + - reg + - clocks + - clock-names + - avdd1v0-supply + - avdd1v8-supply + - avdd3v3-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3288-cru.h> + + lvds: lvds@ff96c000 { + compatible = "rockchip,rk3288-lvds"; + reg = <0xff96c000 0x4000>; + clocks = <&cru PCLK_LVDS_PHY>; + clock-names = "pclk_lvds"; + avdd1v0-supply = <&vdd10_lcd>; + avdd1v8-supply = <&vcc18_lcd>; + avdd3v3-supply = <&vcca_33>; + pinctrl-names = "lcdc"; + pinctrl-0 = <&lcdc_ctl>; + rockchip,grf = <&grf>; + rockchip,output = "rgb"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + lvds_in: port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + lvds_in_vopb: endpoint@0 { + reg = <0>; + remote-endpoint = <&vopb_out_lvds>; + }; + lvds_in_vopl: endpoint@1 { + reg = <1>; + remote-endpoint = <&vopl_out_lvds>; + }; + }; + + lvds_out: port@1 { + reg = <1>; + + lvds_out_panel: endpoint { + remote-endpoint = <&panel_in_lvds>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt deleted file mode 100644 index aaf8c44cf90f..000000000000 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt +++ /dev/null @@ -1,92 +0,0 @@ -Rockchip RK3288 LVDS interface -================================ - -Required properties: -- compatible: matching the soc type, one of - - "rockchip,rk3288-lvds"; - - "rockchip,px30-lvds"; - -- reg: physical base address of the controller and length - of memory mapped region. -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. -- clock-names: must contain "pclk_lvds" - -- avdd1v0-supply: regulator phandle for 1.0V analog power -- avdd1v8-supply: regulator phandle for 1.8V analog power -- avdd3v3-supply: regulator phandle for 3.3V analog power - -- rockchip,grf: phandle to the general register files syscon -- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output interface - -- phys: LVDS/DSI DPHY (px30 only) -- phy-names: name of the PHY, must be "dphy" (px30 only) - -Optional properties: -- pinctrl-names: must contain a "lcdc" entry. -- pinctrl-0: pin control group to be used for this controller. - -Required nodes: - -The lvds has two video ports as described by - Documentation/devicetree/bindings/media/video-interfaces.txt -Their connections are modeled using the OF graph bindings specified in - Documentation/devicetree/bindings/graph.txt. - -- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl -- video port 1 for either a panel or subsequent encoder - -Example: - -lvds_panel: lvds-panel { - compatible = "auo,b101ean01"; - enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>; - data-mapping = "jeida-24"; - - ports { - panel_in_lvds: endpoint { - remote-endpoint = <&lvds_out_panel>; - }; - }; -}; - -For Rockchip RK3288: - - lvds: lvds@ff96c000 { - compatible = "rockchip,rk3288-lvds"; - rockchip,grf = <&grf>; - reg = <0xff96c000 0x4000>; - clocks = <&cru PCLK_LVDS_PHY>; - clock-names = "pclk_lvds"; - pinctrl-names = "lcdc"; - pinctrl-0 = <&lcdc_ctl>; - avdd1v0-supply = <&vdd10_lcd>; - avdd1v8-supply = <&vcc18_lcd>; - avdd3v3-supply = <&vcca_33>; - rockchip,output = "rgb"; - ports { - #address-cells = <1>; - #size-cells = <0>; - - lvds_in: port@0 { - reg = <0>; - - lvds_in_vopb: endpoint@0 { - reg = <0>; - remote-endpoint = <&vopb_out_lvds>; - }; - lvds_in_vopl: endpoint@1 { - reg = <1>; - remote-endpoint = <&vopl_out_lvds>; - }; - }; - - lvds_out: port@1 { - reg = <1>; - - lvds_out_panel: endpoint { - remote-endpoint = <&panel_in_lvds>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml index 3c9f29e428a4..296500f9da05 100644 --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml @@ -26,6 +26,11 @@ description: |+ over control to a driver for the real hardware. The bindings for the hw nodes must specify which node is considered the primary node. + If a panel node is given, then the driver uses this to configure the + physical width and height of the display. If no panel node is given, + then the driver uses the width and height properties of the simplefb + node to estimate it. + It is advised to add display# aliases to help the OS determine how to number things. If display# aliases are used, then if the simplefb node contains a display property then the /aliases/display# path @@ -117,6 +122,10 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle description: Primary display hardware node + panel: + $ref: /schemas/types.yaml#/definitions/phandle + description: Display panel node + allwinner,pipeline: description: Pipeline used by the framebuffer on Allwinner SoCs enum: diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 669f70b1b4c4..94bb5ef567c6 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -14,20 +14,18 @@ properties: compatible: oneOf: # Deprecated compatible strings - - items: - - enum: - - solomon,ssd1305fb-i2c - - solomon,ssd1306fb-i2c - - solomon,ssd1307fb-i2c - - solomon,ssd1309fb-i2c + - enum: + - solomon,ssd1305fb-i2c + - solomon,ssd1306fb-i2c + - solomon,ssd1307fb-i2c + - solomon,ssd1309fb-i2c deprecated: true - - items: - - enum: - - sinowealth,sh1106 - - solomon,ssd1305 - - solomon,ssd1306 - - solomon,ssd1307 - - solomon,ssd1309 + - enum: + - sinowealth,sh1106 + - solomon,ssd1305 + - solomon,ssd1306 + - solomon,ssd1307 + - solomon,ssd1309 reg: maxItems: 1 @@ -226,7 +224,7 @@ unevaluatedProperties: false examples: - | - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -239,7 +237,7 @@ examples: ssd1306_i2c: oled@3d { compatible = "solomon,ssd1306"; - reg = <0x3c>; + reg = <0x3d>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7>; solomon,com-lrremap; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml index d5ca8cf86e8e..f448624dd779 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml @@ -38,7 +38,7 @@ properties: description: The number of cells in a MIPI calibration specifier. Should be 1. The single cell specifies a bitmask of the pads that need to be calibrated for a given device. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 const: 1 additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml index 907fb0baccae..70f0e45c71d6 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml @@ -69,12 +69,12 @@ properties: # Tegra186 and later nvidia,interface: description: index of the SOR interface - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 nvidia,ddc-i2c-bus: description: phandle of an I2C controller used for DDC EDID probing - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle nvidia,hpd-gpio: description: specifies a GPIO used for hotplug detection @@ -82,23 +82,23 @@ properties: nvidia,edid: description: supplies a binary EDID blob - $ref: "/schemas/types.yaml#/definitions/uint8-array" + $ref: /schemas/types.yaml#/definitions/uint8-array nvidia,panel: description: phandle of a display panel, required for eDP - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle nvidia,xbar-cfg: description: 5 cells containing the crossbar configuration. Each lane of the SOR, identified by the cell's index, is mapped via the crossbar to the pad specified by the cell's value. - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array # optional when driving an eDP output nvidia,dpaux: description: phandle to a DispayPort AUX interface - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle allOf: - if: diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml index 265a60d79d89..ce4589466a18 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml @@ -60,13 +60,13 @@ properties: nvidia,outputs: description: A list of phandles of outputs that this display controller can drive. - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array nvidia,head: description: The number of the display controller head. This is used to setup the various types of output to receive video data from the given head. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml index e5a6145c8c53..da75b71e8ece 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml @@ -29,7 +29,7 @@ properties: - const: dsi allOf: - - $ref: "/schemas/reset/reset.yaml" + - $ref: /schemas/reset/reset.yaml additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml index 511cbe74e729..59e1dc0813e7 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml @@ -59,12 +59,12 @@ properties: description: Should contain a phandle and a specifier specifying which pads are used by this DSI output and need to be calibrated. See nvidia,tegra114-mipi.yaml for details. - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array nvidia,ddc-i2c-bus: description: phandle of an I2C controller used for DDC EDID probing - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle nvidia,hpd-gpio: description: specifies a GPIO used for hotplug detection @@ -72,19 +72,19 @@ properties: nvidia,edid: description: supplies a binary EDID blob - $ref: "/schemas/types.yaml#/definitions/uint8-array" + $ref: /schemas/types.yaml#/definitions/uint8-array nvidia,panel: description: phandle of a display panel - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle nvidia,ganged-mode: description: contains a phandle to a second DSI controller to gang up with in order to support up to 8 data lanes - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle allOf: - - $ref: "../dsi-controller.yaml#" + - $ref: ../dsi-controller.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml index f65e59cfffa7..f77197e4869f 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml @@ -68,7 +68,7 @@ properties: nvidia,ddc-i2c-bus: description: phandle of an I2C controller used for DDC EDID probing - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle nvidia,hpd-gpio: description: specifies a GPIO used for hotplug detection @@ -76,11 +76,11 @@ properties: nvidia,edid: description: supplies a binary EDID blob - $ref: "/schemas/types.yaml#/definitions/uint8-array" + $ref: /schemas/types.yaml#/definitions/uint8-array nvidia,panel: description: phandle of a display panel - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle "#sound-dai-cells": const: 0 diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index 5c7d2cbc4aac..b6b402f16161 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/ti/ti,am65x-dss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/ti/ti,am65x-dss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments AM65x Display Subsystem @@ -88,7 +88,7 @@ properties: The DSS DPI output port node from video port 2 ti,am65x-oldi-io-ctrl: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: phandle to syscon device node mapping OLDI IO_CTRL registers. The mapped range should point to OLDI_DAT0_IO_CTRL, map it and diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml index 2986f9acc9f0..fad7cba58d39 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments J721E Display Subsystem diff --git a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml index 7ce7bbad5780..96b1439f88e3 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/ti/ti,k2g-dss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/ti/ti,k2g-dss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments K2G Display Subsystem diff --git a/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml index fc02c5d50ce4..76b804b7c880 100644 --- a/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml +++ b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Bootlin %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/xylon,logicvc-display.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/xylon,logicvc-display.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Xylon LogiCVC display controller @@ -89,25 +89,25 @@ properties: description: Display output colorspace (C_DISPLAY_COLOR_SPACE). xylon,display-depth: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: Display output depth (C_PIXEL_DATA_WIDTH). xylon,row-stride: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: Fixed number of pixels in a framebuffer row (C_ROW_STRIDE). xylon,dithering: - $ref: "/schemas/types.yaml#/definitions/flag" + $ref: /schemas/types.yaml#/definitions/flag description: Dithering module is enabled (C_XCOLOR) xylon,background-layer: - $ref: "/schemas/types.yaml#/definitions/flag" + $ref: /schemas/types.yaml#/definitions/flag description: | The last layer is used to display a black background (C_USE_BACKGROUND). The layer must still be registered. xylon,layers-configurable: - $ref: "/schemas/types.yaml#/definitions/flag" + $ref: /schemas/types.yaml#/definitions/flag description: | Configuration of layers' size, position and offset is enabled (C_USE_SIZE_POSITION). @@ -131,7 +131,7 @@ properties: maxItems: 1 xylon,layer-depth: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: Layer depth (C_LAYER_X_DATA_WIDTH). xylon,layer-colorspace: @@ -151,19 +151,19 @@ properties: description: Alpha mode for the layer (C_LAYER_X_ALPHA_MODE). xylon,layer-base-offset: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: | Offset in number of lines (C_LAYER_X_OFFSET) starting from the video RAM base (C_VMEM_BASEADDR), only for version 3. xylon,layer-buffer-offset: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: | Offset in number of lines (C_BUFFER_*_OFFSET) starting from the layer base offset for the second buffer used in double-buffering. xylon,layer-primary: - $ref: "/schemas/types.yaml#/definitions/flag" + $ref: /schemas/types.yaml#/definitions/flag description: | Layer should be registered as a primary plane (exactly one is required). diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml index 0f5a8ef996d3..11e2a95a7bcb 100644 --- a/Documentation/devicetree/bindings/eeprom/at25.yaml +++ b/Documentation/devicetree/bindings/eeprom/at25.yaml @@ -122,7 +122,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index dfcf4c27d44a..f4eec4c42fb3 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -176,6 +176,8 @@ properties: description: Child nodes are just another property from a json-schema perspective. type: object # DT nodes are json objects + # Child nodes also need additionalProperties or unevaluatedProperties + additionalProperties: false properties: vendor,a-child-node-property: description: Child node properties have all the same schema diff --git a/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml b/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml index 2e5b39881449..e00c8072bae9 100644 --- a/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml +++ b/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml @@ -34,7 +34,7 @@ additionalProperties: false examples: - | - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; cros-ec@0 { diff --git a/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml b/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml index 71a9f2e5d0dc..126107dd57b1 100644 --- a/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml +++ b/Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml @@ -30,7 +30,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; tusb320@61 { diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 2f7c51c75e85..5824c43e9893 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -56,17 +56,38 @@ properties: description: Specifies the mailboxes used to communicate with SCMI compliant firmware. - items: - - const: tx - - const: rx + oneOf: + - items: + - const: tx + - const: rx + minItems: 1 + - items: + - const: tx + - const: tx_reply + - const: rx + minItems: 2 mboxes: description: List of phandle and mailbox channel specifiers. It should contain - exactly one or two mailboxes, one for transmitting messages("tx") - and another optional for receiving the notifications("rx") if supported. + exactly one, two or three mailboxes; the first one or two for transmitting + messages ("tx") and another optional ("rx") for receiving notifications + and delayed responses, if supported by the platform. + The number of mailboxes needed for transmitting messages depends on the + type of channels exposed by the specific underlying mailbox controller; + one single channel descriptor is enough if such channel is bidirectional, + while two channel descriptors are needed to represent the SCMI ("tx") + channel if the underlying mailbox channels are of unidirectional type. + The effective combination in numbers of mboxes and shmem descriptors let + the SCMI subsystem determine unambiguosly which type of SCMI channels are + made available by the underlying mailbox controller and how to use them. + 1 mbox / 1 shmem => SCMI TX over 1 mailbox bidirectional channel + 2 mbox / 2 shmem => SCMI TX and RX over 2 mailbox bidirectional channels + 2 mbox / 1 shmem => SCMI TX over 2 mailbox unidirectional channels + 3 mbox / 2 shmem => SCMI TX and RX over 3 mailbox unidirectional channels + Any other combination of mboxes and shmem is invalid. minItems: 1 - maxItems: 2 + maxItems: 3 shmem: description: @@ -228,13 +249,20 @@ $defs: maxItems: 1 mbox-names: - items: - - const: tx - - const: rx + oneOf: + - items: + - const: tx + - const: rx + minItems: 1 + - items: + - const: tx + - const: tx_reply + - const: rx + minItems: 2 mboxes: minItems: 1 - maxItems: 2 + maxItems: 3 shmem: minItems: 1 diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml index a66e99812b1f..367d04ad1923 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml @@ -24,9 +24,11 @@ properties: - qcom,scm-apq8064 - qcom,scm-apq8084 - qcom,scm-ipq4019 + - qcom,scm-ipq5332 - qcom,scm-ipq6018 - qcom,scm-ipq806x - qcom,scm-ipq8074 + - qcom,scm-ipq9574 - qcom,scm-mdm9607 - qcom,scm-msm8226 - qcom,scm-msm8660 @@ -38,10 +40,12 @@ properties: - qcom,scm-msm8994 - qcom,scm-msm8996 - qcom,scm-msm8998 + - qcom,scm-qcm2290 - qcom,scm-qdu1000 - qcom,scm-sa8775p - qcom,scm-sc7180 - qcom,scm-sc7280 + - qcom,scm-sc8180x - qcom,scm-sc8280xp - qcom,scm-sdm670 - qcom,scm-sdm845 @@ -107,6 +111,7 @@ allOf: - qcom,scm-msm8960 - qcom,scm-msm8974 - qcom,scm-msm8976 + - qcom,scm-qcm2290 - qcom,scm-sm6375 then: required: @@ -125,6 +130,7 @@ allOf: - qcom,scm-apq8064 - qcom,scm-msm8660 - qcom,scm-msm8960 + - qcom,scm-qcm2290 - qcom,scm-sm6375 then: properties: @@ -166,6 +172,7 @@ allOf: compatible: contains: enum: + - qcom,scm-qdu1000 - qcom,scm-sm8450 - qcom,scm-sm8550 then: diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt deleted file mode 100644 index 0acdfa6d62a4..000000000000 --- a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt +++ /dev/null @@ -1,54 +0,0 @@ -Xilinx LogiCORE Partial Reconfig Decoupler Softcore - -The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more -decouplers / fpga bridges. -The controller can decouple/disable the bridges which prevents signal -changes from passing through the bridge. The controller can also -couple / enable the bridges which allows traffic to pass through the -bridge normally. - -Xilinx LogiCORE Dynamic Function eXchange(DFX) AXI shutdown manager -Softcore is compatible with the Xilinx LogiCORE pr-decoupler. - -The Dynamic Function eXchange AXI shutdown manager prevents AXI traffic -from passing through the bridge. The controller safely handles AXI4MM -and AXI4-Lite interfaces on a Reconfigurable Partition when it is -undergoing dynamic reconfiguration, preventing the system deadlock -that can occur if AXI transactions are interrupted by DFX - -The Driver supports only MMIO handling. A PR region can have multiple -PR Decouplers which can be handled independently or chained via decouple/ -decouple_status signals. - -Required properties: -- compatible : Should contain "xlnx,pr-decoupler-1.00" followed by - "xlnx,pr-decoupler" or - "xlnx,dfx-axi-shutdown-manager-1.00" followed by - "xlnx,dfx-axi-shutdown-manager" -- regs : base address and size for decoupler module -- clocks : input clock to IP -- clock-names : should contain "aclk" - -See Documentation/devicetree/bindings/fpga/fpga-region.txt and -Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings. - -Example: -Partial Reconfig Decoupler: - fpga-bridge@100000450 { - compatible = "xlnx,pr-decoupler-1.00", - "xlnx-pr-decoupler"; - regs = <0x10000045 0x10>; - clocks = <&clkc 15>; - clock-names = "aclk"; - bridge-enable = <0>; - }; - -Dynamic Function eXchange AXI shutdown manager: - fpga-bridge@100000450 { - compatible = "xlnx,dfx-axi-shutdown-manager-1.00", - "xlnx,dfx-axi-shutdown-manager"; - regs = <0x10000045 0x10>; - clocks = <&clkc 15>; - clock-names = "aclk"; - bridge-enable = <0>; - }; diff --git a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt b/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt deleted file mode 100644 index 5ef659c1394d..000000000000 --- a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt +++ /dev/null @@ -1,51 +0,0 @@ -Xilinx Slave Serial SPI FPGA Manager - -Xilinx Spartan-6 and 7 Series FPGAs support a method of loading the -bitstream over what is referred to as "slave serial" interface. -The slave serial link is not technically SPI, and might require extra -circuits in order to play nicely with other SPI slaves on the same bus. - -See: -- https://www.xilinx.com/support/documentation/user_guides/ug380.pdf -- https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf -- https://www.xilinx.com/support/documentation/application_notes/xapp583-fpga-configuration.pdf - -Required properties: -- compatible: should contain "xlnx,fpga-slave-serial" -- reg: spi chip select of the FPGA -- prog_b-gpios: config pin (referred to as PROGRAM_B in the manual) -- done-gpios: config status pin (referred to as DONE in the manual) - -Optional properties: -- init-b-gpios: initialization status and configuration error pin - (referred to as INIT_B in the manual) - -Example for full FPGA configuration: - - fpga-region0 { - compatible = "fpga-region"; - fpga-mgr = <&fpga_mgr_spi>; - #address-cells = <0x1>; - #size-cells = <0x1>; - }; - - spi1: spi@10680 { - compatible = "marvell,armada-xp-spi", "marvell,orion-spi"; - pinctrl-0 = <&spi0_pins>; - pinctrl-names = "default"; - #address-cells = <1>; - #size-cells = <0>; - cell-index = <1>; - interrupts = <92>; - clocks = <&coreclk 0>; - - fpga_mgr_spi: fpga-mgr@0 { - compatible = "xlnx,fpga-slave-serial"; - spi-max-frequency = <60000000>; - spi-cpha; - reg = <0>; - prog_b-gpios = <&gpio0 29 GPIO_ACTIVE_LOW>; - init-b-gpios = <&gpio0 28 GPIO_ACTIVE_LOW>; - done-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>; - }; - }; diff --git a/Documentation/devicetree/bindings/fpga/xlnx,fpga-slave-serial.yaml b/Documentation/devicetree/bindings/fpga/xlnx,fpga-slave-serial.yaml new file mode 100644 index 000000000000..614d86ad825f --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xlnx,fpga-slave-serial.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/xlnx,fpga-slave-serial.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Slave Serial SPI FPGA + +maintainers: + - Nava kishore Manne <nava.kishore.manne@amd.com> + +description: | + Xilinx Spartan-6 and 7 Series FPGAs support a method of loading the bitstream + over what is referred to as slave serial interface.The slave serial link is + not technically SPI, and might require extra circuits in order to play nicely + with other SPI slaves on the same bus. + + Datasheets: + https://www.xilinx.com/support/documentation/user_guides/ug380.pdf + https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf + https://www.xilinx.com/support/documentation/application_notes/xapp583-fpga-configuration.pdf + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + enum: + - xlnx,fpga-slave-serial + + spi-cpha: true + + spi-max-frequency: + maximum: 60000000 + + reg: + maxItems: 1 + + prog_b-gpios: + description: + config pin (referred to as PROGRAM_B in the manual) + maxItems: 1 + + done-gpios: + description: + config status pin (referred to as DONE in the manual) + maxItems: 1 + + init-b-gpios: + description: + initialization status and configuration error pin + (referred to as INIT_B in the manual) + maxItems: 1 + +required: + - compatible + - reg + - prog_b-gpios + - done-gpios + - init-b-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + fpga_mgr_spi: fpga-mgr@0 { + compatible = "xlnx,fpga-slave-serial"; + spi-max-frequency = <60000000>; + spi-cpha; + reg = <0>; + prog_b-gpios = <&gpio0 29 GPIO_ACTIVE_LOW>; + init-b-gpios = <&gpio0 28 GPIO_ACTIVE_LOW>; + done-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/fpga/xlnx,pr-decoupler.yaml b/Documentation/devicetree/bindings/fpga/xlnx,pr-decoupler.yaml new file mode 100644 index 000000000000..a7d4b8e59e19 --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xlnx,pr-decoupler.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/xlnx,pr-decoupler.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx LogiCORE Partial Reconfig Decoupler/AXI shutdown manager Softcore + +maintainers: + - Nava kishore Manne <nava.kishore.manne@amd.com> + +description: | + The Xilinx LogiCORE Partial Reconfig(PR) Decoupler manages one or more + decouplers/fpga bridges. The controller can decouple/disable the bridges + which prevents signal changes from passing through the bridge. The controller + can also couple / enable the bridges which allows traffic to pass through the + bridge normally. + Xilinx LogiCORE Dynamic Function eXchange(DFX) AXI shutdown manager Softcore + is compatible with the Xilinx LogiCORE pr-decoupler. The Dynamic Function + eXchange AXI shutdown manager prevents AXI traffic from passing through the + bridge. The controller safely handles AXI4MM and AXI4-Lite interfaces on a + Reconfigurable Partition when it is undergoing dynamic reconfiguration, + preventing the system deadlock that can occur if AXI transactions are + interrupted by DFX. + Please refer to fpga-region.txt and fpga-bridge.txt in this directory for + common binding part and usage. + +properties: + compatible: + oneOf: + - items: + - const: xlnx,pr-decoupler-1.00 + - const: xlnx,pr-decoupler + - items: + - const: xlnx,dfx-axi-shutdown-manager-1.00 + - const: xlnx,dfx-axi-shutdown-manager + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: aclk + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + fpga-bridge@100000450 { + compatible = "xlnx,pr-decoupler-1.00", "xlnx,pr-decoupler"; + reg = <0x10000045 0x10>; + clocks = <&clkc 15>; + clock-names = "aclk"; + }; +... diff --git a/Documentation/devicetree/bindings/gpio/fcs,fxl6408.yaml b/Documentation/devicetree/bindings/gpio/fcs,fxl6408.yaml new file mode 100644 index 000000000000..65b6970e42fb --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/fcs,fxl6408.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/fcs,fxl6408.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Fairchild FXL6408 I2C GPIO Expander + +maintainers: + - Emanuele Ghidoli <emanuele.ghidoli@toradex.com> + +properties: + compatible: + enum: + - fcs,fxl6408 + + reg: + maxItems: 1 + + "#gpio-cells": + const: 2 + + gpio-controller: true + + gpio-line-names: + minItems: 1 + maxItems: 8 + +patternProperties: + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + gpio_expander_43: gpio-expander@43 { + compatible = "fcs,fxl6408"; + reg = <0x43>; + gpio-controller; + #gpio-cells = <2>; + gpio-line-names = "Wi-Fi_W_DISABLE", "Wi-Fi_WKUP_WLAN", + "PWR_EN_+V3.3_WiFi_N", "PCIe_REF_CLK_EN", + "USB_RESET_N", "USB_BYPASS_N", "Wi-Fi_PDn", + "Wi-Fi_WKUP_BT"; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml index 48bf414aa50e..5b0134304e51 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml @@ -34,7 +34,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml index 1b70e9f308f3..fa116148ee90 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml @@ -151,7 +151,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -177,7 +177,7 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -203,7 +203,7 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c2 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -221,7 +221,7 @@ examples: }; - | - i2c3 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index 5663e71b751f..d82c32217fff 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -154,18 +154,35 @@ of the GPIOs that can't be used. Optionally, a GPIO controller may have a "gpio-line-names" property. This is an array of strings defining the names of the GPIO lines going out of the -GPIO controller. This name should be the most meaningful producer name -for the system, such as a rail name indicating the usage. Package names -such as pin name are discouraged: such lines have opaque names (since they -are by definition generic purpose) and such names are usually not very -helpful. For example "MMC-CD", "Red LED Vdd" and "ethernet reset" are -reasonable line names as they describe what the line is used for. "GPIO0" -is not a good name to give to a GPIO line. Placeholders are discouraged: -rather use the "" (blank string) if the use of the GPIO line is undefined -in your design. The names are assigned starting from line offset 0 from -left to right from the passed array. An incomplete array (where the number -of passed named are less than ngpios) will still be used up until the last -provided valid line index. +GPIO controller. + +For lines which are routed to on-board devices, this name should be +the most meaningful producer name for the system, such as a rail name +indicating the usage. Package names, such as a pin name, are discouraged: +such lines have opaque names (since they are by definition general-purpose) +and such names are usually not very helpful. For example "MMC-CD", "Red LED +Vdd" and "ethernet reset" are reasonable line names as they describe what +the line is used for. "GPIO0" is not a good name to give to a GPIO line +that is hard-wired to a specific device. + +However, in the case of lines that are routed to a general purpose header +(e.g. the Raspberry Pi 40-pin header), and therefore are not hard-wired to +specific devices, using a pin number or the names on the header is fine +provided these are real (preferably unique) names. Using an SoC's pad name +or package name, or names made up from kernel-internal software constructs, +are strongly discouraged. For example "pin8 [gpio14/uart0_txd]" is fine +if the board's documentation labels pin 8 as such. However "PortB_24" (an +example of a name from an SoC's reference manual) would not be desirable. + +In either case placeholders are discouraged: rather use the "" (blank +string) if the use of the GPIO line is undefined in your design. Ideally, +try to add comments to the dts file describing the naming the convention +you have chosen, and specifying from where the names are derived. + +The names are assigned starting from line offset 0, from left to right, +from the passed array. An incomplete array (where the number of passed +names is less than ngpios) will be used up until the last provided valid +line index. Example: diff --git a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml new file mode 100644 index 000000000000..fb86e8ce6349 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/loongson,ls-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson GPIO controller. + +maintainers: + - Yinbo Zhu <zhuyinbo@loongson.cn> + +properties: + compatible: + enum: + - loongson,ls2k-gpio + - loongson,ls7a-gpio + + reg: + maxItems: 1 + + ngpios: + minimum: 1 + maximum: 64 + + "#gpio-cells": + const: 2 + + gpio-controller: true + + gpio-ranges: true + + interrupts: + minItems: 1 + maxItems: 64 + +required: + - compatible + - reg + - ngpios + - "#gpio-cells" + - gpio-controller + - gpio-ranges + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + gpio0: gpio@1fe00500 { + compatible = "loongson,ls2k-gpio"; + reg = <0x1fe00500 0x38>; + ngpios = <64>; + #gpio-cells = <2>; + gpio-controller; + gpio-ranges = <&pctrl 0 0 15>, + <&pctrl 16 16 15>, + <&pctrl 32 32 10>, + <&pctrl 44 44 20>; + interrupt-parent = <&liointc1>; + interrupts = <28 IRQ_TYPE_LEVEL_LOW>, + <29 IRQ_TYPE_LEVEL_LOW>, + <30 IRQ_TYPE_LEVEL_LOW>, + <30 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <>, + <>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>; + }; diff --git a/Documentation/devicetree/bindings/gpio/loongson,ls1x-gpio.yaml b/Documentation/devicetree/bindings/gpio/loongson,ls1x-gpio.yaml new file mode 100644 index 000000000000..1a472c05697c --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/loongson,ls1x-gpio.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/loongson,ls1x-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson-1 GPIO controller + +maintainers: + - Keguang Zhang <keguang.zhang@gmail.com> + +properties: + compatible: + const: loongson,ls1x-gpio + + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + const: 2 + + ngpios: + minimum: 1 + maximum: 32 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - ngpios + +additionalProperties: false + +examples: + - | + gpio0: gpio@1fd010c0 { + compatible = "loongson,ls1x-gpio"; + reg = <0x1fd010c0 0x4>; + + gpio-controller; + #gpio-cells = <2>; + + ngpios = <32>; + }; + +... diff --git a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml index 7f26f6b1eea1..31906c253940 100644 --- a/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml @@ -35,6 +35,7 @@ properties: patternProperties: "^.*-pins?$": $ref: /schemas/pinctrl/pinmux-node.yaml# + additionalProperties: false properties: pins: diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 78964c140b46..0400a361875d 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -19,6 +19,8 @@ properties: - enum: - amlogic,meson-g12a-mali - mediatek,mt8183-mali + - mediatek,mt8183b-mali + - mediatek,mt8186-mali - realtek,rtd1619-mali - renesas,r9a07g044-mali - renesas,r9a07g054-mali @@ -27,6 +29,11 @@ properties: - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable - items: - enum: + - mediatek,mt8195-mali + - const: mediatek,mt8192-mali + - const: arm,mali-valhall-jm # Mali Valhall GPU model/revision is fully discoverable + - items: + - enum: - mediatek,mt8192-mali - const: arm,mali-valhall-jm # Mali Valhall GPU model/revision is fully discoverable @@ -63,7 +70,11 @@ properties: power-domains: minItems: 1 - maxItems: 3 + maxItems: 5 + + power-domain-names: + minItems: 2 + maxItems: 5 resets: minItems: 1 @@ -93,6 +104,13 @@ properties: dma-coherent: true + nvmem-cell-names: + items: + - const: speed-bin + + nvmem-cells: + maxItems: 1 + required: - compatible - reg @@ -109,6 +127,10 @@ allOf: contains: const: amlogic,meson-g12a-mali then: + properties: + power-domains: + maxItems: 1 + power-domain-names: false required: - resets - if: @@ -131,6 +153,9 @@ allOf: - const: gpu - const: bus - const: bus_ace + power-domains: + maxItems: 1 + power-domain-names: false resets: minItems: 3 reset-names: @@ -152,6 +177,7 @@ allOf: properties: power-domains: minItems: 3 + maxItems: 3 power-domain-names: items: - const: core0 @@ -164,13 +190,65 @@ allOf: - power-domain-names else: properties: - power-domains: - maxItems: 1 sram-supply: false - if: properties: compatible: contains: + const: mediatek,mt8183b-mali + then: + properties: + power-domains: + minItems: 3 + maxItems: 3 + power-domain-names: + items: + - const: core0 + - const: core1 + - const: core2 + required: + - power-domains + - power-domain-names + - if: + properties: + compatible: + contains: + const: mediatek,mt8186-mali + then: + properties: + power-domains: + minItems: 2 + maxItems: 2 + power-domain-names: + items: + - const: core0 + - const: core1 + required: + - power-domains + - power-domain-names + - if: + properties: + compatible: + contains: + const: mediatek,mt8192-mali + then: + properties: + power-domains: + minItems: 5 + power-domain-names: + items: + - const: core0 + - const: core1 + - const: core2 + - const: core3 + - const: core4 + required: + - power-domains + - power-domain-names + - if: + properties: + compatible: + contains: const: rockchip,rk3568-mali then: properties: @@ -180,6 +258,9 @@ allOf: items: - const: gpu - const: bus + power-domains: + maxItems: 1 + power-domain-names: false required: - clock-names diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml index ed9554c837ef..ba4c6473ff92 100644 --- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra NVDEC diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml index 8199e5fa8211..c23dae713eb8 100644 --- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvenc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvenc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra NVENC diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml index 895fb346ac72..99a33a5eac3f 100644 --- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvjpg.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvjpg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra NVJPG diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml index 4bdc19a2bccf..0b7561c8b9bb 100644 --- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra234 NVDEC diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml index dba74f400bc2..b39c632956e8 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2992.yaml @@ -32,6 +32,7 @@ properties: patternProperties: "^channel@([0-1])$": type: object + additionalProperties: false description: | Represents the two supplies to be monitored. diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt index 4509e688623a..48886f0ce415 100644 --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt @@ -1,67 +1 @@ -Bindings for a fan connected to the PWM lines - -Required properties: -- compatible : "pwm-fan" -- pwms : the PWM that is used to control the PWM fan -- cooling-levels : PWM duty cycle values in a range from 0 to 255 - which correspond to thermal cooling states - -Optional properties: -- fan-supply : phandle to the regulator that provides power to the fan -- interrupts : This contains an interrupt specifier for each fan - tachometer output connected to an interrupt source. - The output signal must generate a defined number of - interrupts per fan revolution, which require that - it must be self resetting edge interrupts. See - interrupt-controller/interrupts.txt for the format. -- pulses-per-revolution : define the number of pulses per fan revolution for - each tachometer input as an integer (default is 2 - interrupts per revolution). The value must be - greater than zero. - -Example: - fan0: pwm-fan { - compatible = "pwm-fan"; - #cooling-cells = <2>; - pwms = <&pwm 0 10000 0>; - cooling-levels = <0 102 170 230>; - }; - - thermal-zones { - cpu_thermal: cpu-thermal { - thermal-sensors = <&tmu 0>; - polling-delay-passive = <0>; - polling-delay = <0>; - trips { - cpu_alert1: cpu-alert1 { - temperature = <100000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - }; - cooling-maps { - map0 { - trip = <&cpu_alert1>; - cooling-device = <&fan0 0 1>; - }; - }; - }; - -Example 2: - fan0: pwm-fan { - compatible = "pwm-fan"; - pwms = <&pwm 0 40000 0>; - fan-supply = <®_fan>; - interrupt-parent = <&gpio5>; - interrupts = <1 IRQ_TYPE_EDGE_FALLING>; - pulses-per-revolution = <2>; - }; - -Example 3: - fan0: pwm-fan { - compatible = "pwm-fan"; - pwms = <&pwm1 0 25000 0>; - interrupts-extended = <&gpio1 1 IRQ_TYPE_EDGE_FALLING>, - <&gpio2 5 IRQ_TYPE_EDGE_FALLING>; - pulses-per-revolution = <2>, <1>; - }; +This file has moved to pwm-fan.yaml. diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.yaml b/Documentation/devicetree/bindings/hwmon/pwm-fan.yaml new file mode 100644 index 000000000000..4e5abf7580cc --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/pwm-fan.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Fan connected to PWM lines + +maintainers: + - Jean Delvare <jdelvare@suse.com> + - Guenter Roeck <linux@roeck-us.net> + +properties: + compatible: + const: pwm-fan + + cooling-levels: + description: PWM duty cycle values corresponding to thermal cooling states. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + maximum: 255 + + fan-supply: + description: Phandle to the regulator that provides power to the fan. + + interrupts: + description: + This contains an interrupt specifier for each fan tachometer output + connected to an interrupt source. The output signal must generate a + defined number of interrupts per fan revolution, which require that + it must be self resetting edge interrupts. + maxItems: 1 + + pulses-per-revolution: + description: + Define the number of pulses per fan revolution for each tachometer + input as an integer. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4 + default: 2 + + pwms: + description: The PWM that is used to control the fan. + maxItems: 1 + + "#cooling-cells": true + +required: + - compatible + - pwms + +additionalProperties: false + +examples: + - | + pwm-fan { + compatible = "pwm-fan"; + cooling-levels = <0 102 170 230>; + pwms = <&pwm 0 10000 0>; + #cooling-cells = <2>; + }; + + thermal-zones { + cpu_thermal: cpu-thermal { + thermal-sensors = <&tmu 0>; + polling-delay-passive = <0>; + polling-delay = <0>; + + trips { + cpu_alert1: cpu-alert1 { + temperature = <100000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + }; + + cooling-maps { + map0 { + trip = <&cpu_alert1>; + cooling-device = <&fan0 0 1>; + }; + }; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + + pwm-fan { + compatible = "pwm-fan"; + pwms = <&pwm 0 40000 0>; + fan-supply = <®_fan>; + interrupt-parent = <&gpio5>; + interrupts = <1 IRQ_TYPE_EDGE_FALLING>; + pulses-per-revolution = <2>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml b/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml new file mode 100644 index 000000000000..f5b34528928d --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/starfive,jh71x0-temp.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/starfive,jh71x0-temp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH71x0 Temperature Sensor + +maintainers: + - Emil Renner Berthing <kernel@esmil.dk> + +description: | + StarFive Technology Co. JH71x0 embedded temperature sensor + +properties: + compatible: + enum: + - starfive,jh7100-temp + - starfive,jh7110-temp + + reg: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: "sense" + - const: "bus" + + '#thermal-sensor-cells': + const: 0 + + resets: + minItems: 2 + maxItems: 2 + + reset-names: + items: + - const: "sense" + - const: "bus" + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/starfive-jh7100.h> + #include <dt-bindings/reset/starfive-jh7100.h> + + temperature-sensor@124a0000 { + compatible = "starfive,jh7100-temp"; + reg = <0x124a0000 0x10000>; + clocks = <&clkgen JH7100_CLK_TEMP_SENSE>, + <&clkgen JH7100_CLK_TEMP_APB>; + clock-names = "sense", "bus"; + #thermal-sensor-cells = <0>; + resets = <&rstgen JH7100_RSTN_TEMP_SENSE>, + <&rstgen JH7100_RSTN_TEMP_APB>; + reset-names = "sense", "bus"; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml index 47af97bb4ced..8648877d2d01 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml @@ -57,6 +57,10 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 2, 4, 8] + vs-supply: + description: phandle to the regulator that provides the VS supply typically + in range from 2.7 V to 5.5 V. + required: - compatible - reg @@ -73,5 +77,6 @@ examples: compatible = "ti,ina220"; reg = <0x44>; shunt-resistor = <1000>; + vs-supply = <&vdd_3v0>; }; }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml index e7493e25a7d2..f9c00cbb2806 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TMP464 and TMP468 temperature sensors maintainers: - - Agathe Porte <agathe.porte@nokia.com> + - Guenter Roeck <linux@roeck-us.net> description: | ±0.0625°C Remote and Local temperature sensor diff --git a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml index 199a354ccb97..26bed558c6b8 100644 --- a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/i2c/amlogic,meson6-i2c.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/i2c/amlogic,meson6-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson I2C Controller diff --git a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml index 4ac61fec90e2..077d2a539c83 100644 --- a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/i2c/apple,i2c.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/i2c/apple,i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Apple/PASemi I2C controller @@ -23,6 +23,7 @@ properties: items: - enum: - apple,t8103-i2c + - apple,t8112-i2c - apple,t6000-i2c - const: apple,i2c diff --git a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml index 869b4d633353..6df27b47b922 100644 --- a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml @@ -60,7 +60,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/clock/aspeed-clock.h> - i2c0: i2c-bus@40 { + i2c@40 { #address-cells = <1>; #size-cells = <0>; compatible = "aspeed,ast2500-i2c-bus"; diff --git a/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml b/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml index ea2303c0e143..6adedd3ec399 100644 --- a/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml @@ -75,7 +75,7 @@ required: - clocks allOf: - - $ref: "i2c-controller.yaml" + - $ref: i2c-controller.yaml - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml index 2e95cda7262a..cb24d7b3221c 100644 --- a/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml +++ b/Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/i2c/cdns,i2c-r1p10.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/i2c/cdns,i2c-r1p10.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence I2C controller @@ -24,6 +24,9 @@ properties: clocks: minItems: 1 + resets: + maxItems: 1 + interrupts: maxItems: 1 @@ -38,6 +41,13 @@ properties: description: | Input clock name. + fifo-depth: + description: + Size of the data FIFO in bytes. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 16 + enum: [2, 4, 8, 16, 32, 64, 128, 256] + required: - compatible - reg @@ -52,9 +62,11 @@ examples: i2c@e0004000 { compatible = "cdns,i2c-r1p10"; clocks = <&clkc 38>; + resets = <&rstc 288>; interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; reg = <0xe0004000 0x1000>; clock-frequency = <400000>; #address-cells = <1>; #size-cells = <0>; + fifo-depth = <8>; }; diff --git a/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml b/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml index cf523615f5e3..ab151c9db219 100644 --- a/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml +++ b/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml @@ -39,7 +39,7 @@ unevaluatedProperties: false examples: - | - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml index 018e1b944424..70fb69b923c4 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml @@ -43,6 +43,7 @@ properties: fsl,timeout: $ref: /schemas/types.yaml#/definitions/uint32 + deprecated: true description: | I2C bus timeout in microseconds @@ -95,6 +96,6 @@ examples: interrupts = <43 2>; interrupt-parent = <&mpic>; clock-frequency = <400000>; - fsl,timeout = <10000>; + i2c-scl-clk-low-timeout-us = <10000>; }; ... diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml index 72ae2e01cf22..fda0467cdd95 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.yaml @@ -23,6 +23,7 @@ properties: - const: mediatek,mt6577-i2c - const: mediatek,mt6589-i2c - const: mediatek,mt7622-i2c + - const: mediatek,mt7981-i2c - const: mediatek,mt7986-i2c - const: mediatek,mt8168-i2c - const: mediatek,mt8173-i2c @@ -47,6 +48,10 @@ properties: - const: mediatek,mt8168-i2c - items: - enum: + - mediatek,mt6795-i2c + - const: mediatek,mt8173-i2c + - items: + - enum: - mediatek,mt8195-i2c - const: mediatek,mt8192-i2c diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml index 6e0a5686af04..f34cc7ad5a00 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml @@ -45,7 +45,7 @@ properties: i2c-parent: description: phandle of the I2C bus that this multiplexer's master-side port is connected to - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle mux-gpios: description: list of GPIOs used to control the muxer @@ -55,7 +55,7 @@ properties: idle-state: description: Value to set the muxer to when idle. When no value is given, it defaults to the last value used. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 allOf: - $ref: i2c-mux.yaml diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml index 0e88c85985b5..9f66a3bb1f80 100644 --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/i2c/qcom,i2c-geni-qcom.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/i2c/qcom,i2c-geni-qcom.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Geni based QUP I2C Controller diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml index 3d5782deb97d..b204e35e4f8d 100644 --- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml @@ -37,7 +37,7 @@ properties: for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are permanently wired to the respective client. This property is deprecated. Use "pinctrl-0" and "pinctrl-names" instead. - deprecated: yes + deprecated: true interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml index bf396e9466aa..94b75d9f66cd 100644 --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml @@ -90,7 +90,7 @@ properties: st,syscfg-fmp: description: Use to set Fast Mode Plus bit within SYSCFG when Fast Mode Plus speed is selected by slave. - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to syscfg diff --git a/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml b/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml index 1b598638d457..658ae92fa86d 100644 --- a/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml +++ b/Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/i2c/xlnx,xps-iic-2.00.a.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/i2c/xlnx,xps-iic-2.00.a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx IIC controller diff --git a/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c.yaml b/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c.yaml new file mode 100644 index 000000000000..fcc3dbff9c9a --- /dev/null +++ b/Documentation/devicetree/bindings/i3c/aspeed,ast2600-i3c.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i3c/aspeed,ast2600-i3c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED AST2600 i3c controller + +maintainers: + - Jeremy Kerr <jk@codeconstruct.com.au> + +allOf: + - $ref: i3c.yaml# + +properties: + compatible: + const: aspeed,ast2600-i3c + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + interrupts: + maxItems: 1 + + sda-pullup-ohms: + enum: [545, 750, 2000] + default: 2000 + description: | + Value to configure SDA pullup resistor, in Ohms. + + aspeed,global-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to i3c global register syscon node + - description: index of this i3c controller in the global register set + description: | + A (phandle, controller index) reference to the i3c global register set + used for this device. + +required: + - compatible + - reg + - clocks + - interrupts + - aspeed,global-regs + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i3c-master@2000 { + compatible = "aspeed,ast2600-i3c"; + reg = <0x2000 0x1000>; + #address-cells = <3>; + #size-cells = <0>; + clocks = <&syscon 0>; + resets = <&syscon 0>; + aspeed,global-regs = <&i3c_global 0>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i3c1_default>; + interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml index c115e2e99bd9..1c7aee5ed3e0 100644 --- a/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/renesas,rcar-gyroadc.yaml @@ -34,9 +34,11 @@ properties: clock-names: const: fck - power-domains: true + power-domains: + maxItems: 1 - resets: true + resets: + maxItems: 1 "#address-cells": const: 1 @@ -51,6 +53,8 @@ required: - reg - clocks - clock-names + - power-domains + - resets - "#address-cells" - "#size-cells" @@ -108,36 +112,30 @@ patternProperties: examples: - | - #include <dt-bindings/clock/r8a7791-clock.h> + #include <dt-bindings/clock/r8a7791-cpg-mssr.h> #include <dt-bindings/power/r8a7791-sysc.h> - soc { - #address-cells = <2>; - #size-cells = <2>; - - adc@e6e54000 { - compatible = "renesas,r8a7791-gyroadc", "renesas,rcar-gyroadc"; - reg = <0 0xe6e54000 0 64>; - clocks = <&mstp9_clks R8A7791_CLK_GYROADC>; - clock-names = "fck"; - power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; - - pinctrl-0 = <&adc_pins>; - pinctrl-names = "default"; - - #address-cells = <1>; - #size-cells = <0>; - - adc@0 { - reg = <0>; - compatible = "maxim,max1162"; - vref-supply = <&vref_max1162>; - }; - - adc@1 { - reg = <1>; - compatible = "maxim,max1162"; - vref-supply = <&vref_max1162>; - }; + + adc@e6e54000 { + compatible = "renesas,r8a7791-gyroadc", "renesas,rcar-gyroadc"; + reg = <0xe6e54000 64>; + clocks = <&cpg CPG_MOD 901>; + clock-names = "fck"; + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; + resets = <&cpg 901>; + + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + reg = <0>; + compatible = "maxim,max1162"; + vref-supply = <&vref_max1162>; + }; + + adc@1 { + reg = <1>; + compatible = "maxim,max1162"; + vref-supply = <&vref_max1162>; }; }; ... diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml new file mode 100644 index 000000000000..970ccab15e1e --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/ti,ads1100.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI ADS1100/ADS1000 single channel I2C analog to digital converter + +maintainers: + - Mike Looijmans <mike.looijmans@topic.nl> + +description: | + Datasheet at: https://www.ti.com/lit/gpn/ads1100 + +properties: + compatible: + enum: + - ti,ads1100 + - ti,ads1000 + + reg: + maxItems: 1 + + vdd-supply: true + + "#io-channel-cells": + const: 0 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + adc@49 { + compatible = "ti,ads1100"; + reg = <0x49>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml b/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml index 9eb3ecc8bbc8..590ea7936ad7 100644 --- a/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml +++ b/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml @@ -101,6 +101,15 @@ patternProperties: When not configured as a comparator, the GPO will be treated as an output-only GPIO. + drive-strength-microamp: + description: | + For channels configured as digital input, this configures the sink + current. + minimum: 0 + maximum: 1800 + default: 0 + multipleOf: 120 + required: - reg diff --git a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml index decf022335d8..b39f5217d8ff 100644 --- a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml +++ b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml @@ -46,6 +46,9 @@ properties: - items: - const: st,ism330is - const: st,lsm6dso16is + - items: + - const: st,asm330lhb + - const: st,asm330lhh reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml b/Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml new file mode 100644 index 000000000000..30a109a1bf3b --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/rohm,bu27034.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BU27034 ambient light sensor + +maintainers: + - Matti Vaittinen <mazziesaccount@gmail.com> + +description: | + ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes + capable of detecting a very wide range of illuminance. Typical application + is adjusting LCD and backlight power of TVs and mobile phones. + https://fscdn.rohm.com/en/products/databook/datasheet/ic/sensor/light/bu27034nuc-e.pdf + +properties: + compatible: + const: rohm,bu27034 + + reg: + maxItems: 1 + + vdd-supply: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + light-sensor@38 { + compatible = "rohm,bu27034"; + reg = <0x38>; + vdd-supply = <&vdd>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml index 63885af6a74b..6fda887ee9d4 100644 --- a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml +++ b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml @@ -17,6 +17,7 @@ description: | https://www.bosch-sensortec.com/bst/products/all_products/bmp280 https://www.bosch-sensortec.com/bst/products/all_products/bme280 https://www.bosch-sensortec.com/bst/products/all_products/bmp380 + https://www.bosch-sensortec.com/bst/products/all_products/bmp580 properties: compatible: @@ -26,6 +27,7 @@ properties: - bosch,bmp280 - bosch,bme280 - bosch,bmp380 + - bosch,bmp580 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index c6201976378f..1ff3afca9149 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -11,9 +11,6 @@ description: The STMicroelectronics sensor devices are pretty straight-forward what type of sensor it is. Note that whilst this covers many STMicro MEMs sensors, some more complex IMUs need their own bindings. - The STMicroelectronics sensor devices are pretty straight-forward I2C or - SPI devices, all sharing the same device tree descriptions no matter what - type of sensor it is. maintainers: - Denis Ciocca <denis.ciocca@st.com> @@ -48,6 +45,9 @@ properties: - st,lsm330d-accel - st,lsm330dl-accel - st,lsm330dlc-accel + - items: + - const: st,iis328dq + - const: st,h3lis331dl-accel - description: Silan Accelerometers enum: - silan,sc7a20 diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml index f44fc32ce87e..dbb85135fd66 100644 --- a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml +++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml @@ -18,6 +18,28 @@ description: | https://www.analog.com/media/en/technical-documentation/data-sheets/29861fa.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/ltm2985.pdf +$defs: + sensor-node: + type: object + description: Sensor node common constraints + + properties: + reg: + description: + Channel number. Connects the sensor to the channel with this number + of the device. + minimum: 1 + maximum: 20 + + adi,sensor-type: + description: Type of sensor connected to the device. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - reg + - adi,sensor-type + + properties: compatible: oneOf: @@ -64,28 +86,10 @@ properties: const: 0 patternProperties: - "@([0-9a-f]+)$": - type: object - description: Sensor. - - properties: - reg: - description: - Channel number. Connects the sensor to the channel with this number - of the device. - minimum: 1 - maximum: 20 - - adi,sensor-type: - description: Type of sensor connected to the device. - $ref: /schemas/types.yaml#/definitions/uint32 - - required: - - reg - - adi,sensor-type - "^thermocouple@": - type: object + $ref: '#/$defs/sensor-node' + unevaluatedProperties: false + description: Thermocouple sensor. properties: @@ -123,7 +127,7 @@ patternProperties: description: Used for digitizing custom thermocouples. See Page 59 of the datasheet. - $ref: /schemas/types.yaml#/definitions/uint64-matrix + $ref: /schemas/types.yaml#/definitions/int64-matrix minItems: 3 maxItems: 64 items: @@ -141,7 +145,9 @@ patternProperties: - adi,custom-thermocouple "^diode@": - type: object + $ref: '#/$defs/sensor-node' + unevaluatedProperties: false + description: Diode sensor. properties: @@ -184,7 +190,8 @@ patternProperties: default: 0 "^rtd@": - type: object + $ref: '#/$defs/sensor-node' + unevaluatedProperties: false description: RTD sensor. properties: @@ -282,7 +289,8 @@ patternProperties: - adi,custom-rtd "^thermistor@": - type: object + $ref: '#/$defs/sensor-node' + unevaluatedProperties: false description: Thermistor sensor. properties: @@ -383,7 +391,8 @@ patternProperties: - adi,custom-thermistor "^adc@": - type: object + $ref: '#/$defs/sensor-node' + unevaluatedProperties: false description: Direct ADC sensor. properties: @@ -397,7 +406,8 @@ patternProperties: type: boolean "^temp@": - type: object + $ref: '#/$defs/sensor-node' + unevaluatedProperties: false description: Active analog temperature sensor. properties: @@ -426,7 +436,8 @@ patternProperties: - adi,custom-temp "^rsense@": - type: object + $ref: '#/$defs/sensor-node' + unevaluatedProperties: false description: Sense resistor sensor. properties: diff --git a/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml index c4f1c69f9330..8c6d7735e875 100644 --- a/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml +++ b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml @@ -7,9 +7,10 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TI TMP117 - Digital temperature sensor with integrated NV memory description: | - TI TMP117 - Digital temperature sensor with integrated NV memory that supports - I2C interface. - https://www.ti.com/lit/gpn/tmp1 + TI TMP116/117 - Digital temperature sensor with integrated NV memory that + supports I2C interface. + https://www.ti.com/lit/gpn/tmp116 + https://www.ti.com/lit/gpn/tmp117 maintainers: - Puranjay Mohan <puranjay12@gmail.com> @@ -17,6 +18,7 @@ maintainers: properties: compatible: enum: + - ti,tmp116 - ti,tmp117 reg: diff --git a/Documentation/devicetree/bindings/input/adc-joystick.yaml b/Documentation/devicetree/bindings/input/adc-joystick.yaml index da0f8dfca8bf..6c244d66f8ce 100644 --- a/Documentation/devicetree/bindings/input/adc-joystick.yaml +++ b/Documentation/devicetree/bindings/input/adc-joystick.yaml @@ -2,8 +2,8 @@ # Copyright 2019-2020 Artur Rojek %YAML 1.2 --- -$id: "http://devicetree.org/schemas/input/adc-joystick.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/input/adc-joystick.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: ADC attached joystick diff --git a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml index e05690b3e963..fefaaf46a240 100644 --- a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml +++ b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml @@ -45,7 +45,7 @@ properties: when the keyboard has a custom design for the top row keys. dependencies: - function-row-phsymap: [ 'linux,keymap' ] + function-row-physmap: [ 'linux,keymap' ] google,needs-ghost-filter: [ 'linux,keymap' ] required: @@ -57,7 +57,7 @@ if: contains: const: google,cros-ec-keyb then: - $ref: "/schemas/input/matrix-keymap.yaml#" + $ref: /schemas/input/matrix-keymap.yaml# required: - keypad,num-rows - keypad,num-columns diff --git a/Documentation/devicetree/bindings/input/imx-keypad.yaml b/Documentation/devicetree/bindings/input/imx-keypad.yaml index 7514df62b592..b110eb1f3358 100644 --- a/Documentation/devicetree/bindings/input/imx-keypad.yaml +++ b/Documentation/devicetree/bindings/input/imx-keypad.yaml @@ -10,7 +10,7 @@ maintainers: - Liu Ying <gnuiyl@gmail.com> allOf: - - $ref: "/schemas/input/matrix-keymap.yaml#" + - $ref: /schemas/input/matrix-keymap.yaml# description: | The KPP is designed to interface with a keypad matrix with 2-point contact diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.yaml b/Documentation/devicetree/bindings/input/matrix-keymap.yaml index 4d6dbe91646d..a715c2a773fe 100644 --- a/Documentation/devicetree/bindings/input/matrix-keymap.yaml +++ b/Documentation/devicetree/bindings/input/matrix-keymap.yaml @@ -21,7 +21,7 @@ description: | properties: linux,keymap: - $ref: '/schemas/types.yaml#/definitions/uint32-array' + $ref: /schemas/types.yaml#/definitions/uint32-array description: | An array of packed 1-cell entries containing the equivalent of row, column and linux key-code. The 32-bit big endian cell is packed as: diff --git a/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml b/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml index d768c30f48fb..47aac8794b68 100644 --- a/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml +++ b/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml @@ -10,7 +10,7 @@ maintainers: - Mattijs Korpershoek <mkorpershoek@baylibre.com> allOf: - - $ref: "/schemas/input/matrix-keymap.yaml#" + - $ref: /schemas/input/matrix-keymap.yaml# description: | Mediatek's Keypad controller is used to interface a SoC with a matrix-type diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml index 5fa625b5c5fb..5b5d4f7d3482 100644 --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/input/microchip,cap11xx.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/input/microchip,cap11xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Microchip CAP11xx based capacitive touch sensors diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt b/Documentation/devicetree/bindings/input/pwm-beeper.txt deleted file mode 100644 index 8fc0e48c20db..000000000000 --- a/Documentation/devicetree/bindings/input/pwm-beeper.txt +++ /dev/null @@ -1,24 +0,0 @@ -* PWM beeper device tree bindings - -Registers a PWM device as beeper. - -Required properties: -- compatible: should be "pwm-beeper" -- pwms: phandle to the physical PWM device - -Optional properties: -- amp-supply: phandle to a regulator that acts as an amplifier for the beeper -- beeper-hz: bell frequency in Hz - -Example: - -beeper_amp: amplifier { - compatible = "fixed-regulator"; - gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>; -}; - -beeper { - compatible = "pwm-beeper"; - pwms = <&pwm0>; - amp-supply = <&beeper_amp>; -}; diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.yaml b/Documentation/devicetree/bindings/input/pwm-beeper.yaml new file mode 100644 index 000000000000..a7611c206989 --- /dev/null +++ b/Documentation/devicetree/bindings/input/pwm-beeper.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/pwm-beeper.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PWM beeper + +maintainers: + - Sascha Hauer <s.hauer@pengutronix.de> + +properties: + compatible: + const: pwm-beeper + + pwms: + maxItems: 1 + + amp-supply: + description: an amplifier for the beeper + + beeper-hz: + description: bell frequency in Hz + minimum: 10 + maximum: 10000 + +required: + - compatible + - pwms + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + beeper { + compatible = "pwm-beeper"; + pwms = <&pwm0>; + amp-supply = <&beeper_amp>; + beeper-hz = <1000>; + }; diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.yaml b/Documentation/devicetree/bindings/input/pwm-vibrator.yaml index a70a636ee112..d32716c604fe 100644 --- a/Documentation/devicetree/bindings/input/pwm-vibrator.yaml +++ b/Documentation/devicetree/bindings/input/pwm-vibrator.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/input/pwm-vibrator.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/input/pwm-vibrator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: PWM vibrator diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.yaml b/Documentation/devicetree/bindings/input/regulator-haptic.yaml index 627891e1ef55..cf63f834dd7d 100644 --- a/Documentation/devicetree/bindings/input/regulator-haptic.yaml +++ b/Documentation/devicetree/bindings/input/regulator-haptic.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/input/regulator-haptic.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/input/regulator-haptic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Regulator Haptic diff --git a/Documentation/devicetree/bindings/input/snvs-pwrkey.txt b/Documentation/devicetree/bindings/input/snvs-pwrkey.txt deleted file mode 100644 index 70c14250323b..000000000000 --- a/Documentation/devicetree/bindings/input/snvs-pwrkey.txt +++ /dev/null @@ -1 +0,0 @@ -See Documentation/devicetree/bindings/crypto/fsl-sec4.txt diff --git a/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml b/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml index f9053e5e9b24..3255c2c8951a 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/input/touchscreen/elan,elants_i2c.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/input/touchscreen/elan,elants_i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Elantech I2C Touchscreen diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml index 12a0d3ecbabb..5d17bdcfdf70 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml @@ -22,14 +22,14 @@ description: | properties: compatible: oneOf: + - const: qcom,msm8998-bwmon # BWMON v4 - items: - enum: - qcom,sc7280-cpu-bwmon - qcom,sc8280xp-cpu-bwmon - - qcom,sdm845-bwmon + - qcom,sdm845-cpu-bwmon - qcom,sm8550-cpu-bwmon - - const: qcom,msm8998-bwmon - - const: qcom,msm8998-bwmon # BWMON v4 + - const: qcom,sdm845-bwmon # BWMON v4, unified register space - items: - enum: - qcom,sc8280xp-llcc-bwmon @@ -49,9 +49,13 @@ properties: type: object reg: - # BWMON v4 (currently described) and BWMON v5 use one register address - # space. BWMON v2 uses two register spaces - not yet described. - maxItems: 1 + # BWMON v5 uses one register address space, v1-v4 use one or two. + minItems: 1 + maxItems: 2 + + reg-names: + minItems: 1 + maxItems: 2 required: - compatible @@ -63,13 +67,36 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + const: qcom,msm8998-bwmon + then: + properties: + reg: + minItems: 2 + + reg-names: + items: + - const: monitor + - const: global + + else: + properties: + reg: + maxItems: 1 + + reg-names: + maxItems: 1 + examples: - | #include <dt-bindings/interconnect/qcom,sdm845.h> #include <dt-bindings/interrupt-controller/arm-gic.h> pmu@1436400 { - compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon"; + compatible = "qcom,sdm845-cpu-bwmon", "qcom,sdm845-bwmon"; reg = <0x01436400 0x600>; interrupts = <GIC_SPI 581 IRQ_TYPE_LEVEL_HIGH>; interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_LLCC 3>; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index 576992a6dc5a..9d0a98d77ae9 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -29,6 +29,7 @@ properties: - enum: - qcom,sc7280-epss-l3 - qcom,sc8280xp-epss-l3 + - qcom,sm6375-cpucp-l3 - qcom,sm8250-epss-l3 - qcom,sm8350-epss-l3 - const: qcom,epss-l3 diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml index d9d243c5514b..4f95d512012a 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml @@ -66,6 +66,7 @@ properties: patternProperties: '^interconnect-[a-z0-9]+$': type: object + additionalProperties: false description: snoc-mm is a child of snoc, sharing snoc's register address space. diff --git a/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml index 5da333c644c9..27756d0c5419 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml @@ -32,7 +32,7 @@ properties: The first cell is the input IRQ number, between 0 and 2, while the second cell is the trigger type as defined in interrupt.txt in this directory. - 'interrupts': + interrupts: description: | Contains the GIC SPI IRQs mapped to the external interrupt lines. They shall be specified sequentially from output 0 to 2. @@ -44,7 +44,7 @@ required: - reg - interrupt-controller - '#interrupt-cells' - - 'interrupts' + - interrupts additionalProperties: false diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml index 06948c0e36a5..2bde6cc6fe0a 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml @@ -31,19 +31,22 @@ description: | properties: compatible: items: - - const: apple,t6000-aic + - enum: + - apple,t8112-aic + - apple,t6000-aic - const: apple,aic2 interrupt-controller: true '#interrupt-cells': - const: 4 + minimum: 3 + maximum: 4 description: | The 1st cell contains the interrupt type: - 0: Hardware IRQ - 1: FIQ - The 2nd cell contains the die ID. + The 2nd cell contains the die ID (only present on apple,t6000-aic). The next cell contains the interrupt number. - HW IRQs: interrupt number @@ -109,6 +112,19 @@ additionalProperties: false allOf: - $ref: /schemas/interrupt-controller.yaml# + - if: + properties: + compatible: + contains: + const: apple,t8112-aic + then: + properties: + '#interrupt-cells': + const: 3 + else: + properties: + '#interrupt-cells': + const: 4 examples: - | diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index 8449e14af9f3..92117261e1e1 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml @@ -133,12 +133,14 @@ properties: ppi-partitions: type: object + additionalProperties: false description: PPI affinity can be expressed as a single "ppi-partitions" node, containing a set of sub-nodes. patternProperties: "^interrupt-partition-[0-9]+$": type: object + additionalProperties: false properties: affinity: $ref: /schemas/types.yaml#/definitions/phandle-array diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml index 220256907461..a2846e493497 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml @@ -133,8 +133,8 @@ properties: - items: # for "arm,cortex-a9-gic" - const: PERIPHCLK - const: PERIPHCLKEN - - const: clk # for "arm,gic-400" and "nvidia,tegra210" - - const: gclk #for "arm,pl390" + - const: clk # for "arm,gic-400" and "nvidia,tegra210" + - const: gclk # for "arm,pl390" power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml index bcb5e20fa9ca..20ad4ad82ad6 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml @@ -48,13 +48,13 @@ properties: const: 1 fsl,channel: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: | u32 value representing the output channel that all input IRQs should be steered into. fsl,num-irqs: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: | u32 value representing the number of input interrupts of this channel, should be multiple of 32 input interrupts and up to 512 interrupts. diff --git a/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.yaml b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.yaml index 39ab8cdd19b4..a3ac818f067d 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/interrupt-controller/intel,ce4100-ioapic.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/interrupt-controller/intel,ce4100-ioapic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel I/O Advanced Programmable Interrupt Controller (IO APIC) diff --git a/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-lapic.yaml b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-lapic.yaml index d2d0145cb889..6b20a5fa8590 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-lapic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-lapic.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/interrupt-controller/intel,ce4100-lapic.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/interrupt-controller/intel,ce4100-lapic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel Local Advanced Programmable Interrupt Controller (LAPIC) diff --git a/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml b/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml index 14dced11877b..a02a6b5af205 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml @@ -2,8 +2,8 @@ # Copyright 2018 Linaro Ltd. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/interrupt-controller/intel,ixp4xx-interrupt.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/interrupt-controller/intel,ixp4xx-interrupt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel IXP4xx XScale Networking Processors Interrupt Controller diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongarch,cpu-interrupt-controller.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml index 2a1cf885c99d..adf989976dcc 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongarch,cpu-interrupt-controller.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/interrupt-controller/loongarch,cpu-interrupt-controller.yaml# +$id: http://devicetree.org/schemas/interrupt-controller/loongson,cpu-interrupt-controller.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: LoongArch CPU Interrupt Controller @@ -11,7 +11,7 @@ maintainers: properties: compatible: - const: loongarch,cpu-interrupt-controller + const: loongson,cpu-interrupt-controller '#interrupt-cells': const: 1 @@ -28,7 +28,7 @@ required: examples: - | interrupt-controller { - compatible = "loongarch,cpu-interrupt-controller"; + compatible = "loongson,cpu-interrupt-controller"; #interrupt-cells = <1>; interrupt-controller; }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,htpic.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,htpic.yaml index d6bc1a687fc7..f0acd5671bb1 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,htpic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,htpic.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/interrupt-controller/loongson,htpic.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/interrupt-controller/loongson,htpic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Loongson-3 HyperTransport Interrupt Controller diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml index 87a74558204f..1d145763908e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,htvec.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/interrupt-controller/loongson,htvec.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/interrupt-controller/loongson,htvec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Loongson-3 HyperTransport Interrupt Vector Controller diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml index 750cc44628e9..00b570c82903 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/interrupt-controller/loongson,liointc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/interrupt-controller/loongson,liointc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Loongson Local I/O Interrupt Controller @@ -54,7 +54,7 @@ properties: '#interrupt-cells': const: 2 - 'loongson,parent_int_map': + loongson,parent_int_map: description: | This property points how the children interrupts will be mapped into CPU interrupt lines. Each cell refers to a parent interrupt line from 0 to 3 @@ -71,7 +71,7 @@ required: - interrupts - interrupt-controller - '#interrupt-cells' - - 'loongson,parent_int_map' + - loongson,parent_int_map unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml index 1f6fd73d4624..a71fc2218ede 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-msi.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/interrupt-controller/loongson,pch-msi.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/interrupt-controller/loongson,pch-msi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Loongson PCH MSI Controller @@ -25,7 +25,7 @@ properties: description: u32 value of the base of parent HyperTransport vector allocated to PCH MSI. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 255 @@ -33,7 +33,7 @@ properties: description: u32 value of the number of parent HyperTransport vectors allocated to PCH MSI. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 1 maximum: 256 @@ -46,7 +46,7 @@ required: - loongson,msi-base-vec - loongson,msi-num-vecs -additionalProperties: true #fixme +additionalProperties: true # fixme examples: - | diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml index fdd6a38a31db..b7bc5cb1dff2 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-pic.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/interrupt-controller/loongson,pch-pic.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/interrupt-controller/loongson,pch-pic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Loongson PCH PIC Controller @@ -25,7 +25,7 @@ properties: description: u32 value of the base of parent HyperTransport vector allocated to PCH PIC. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 192 diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt index 84ced3f4179b..3ffc60184e44 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt @@ -25,6 +25,7 @@ Required properties: "mediatek,mt6577-sysirq": for MT6577 "mediatek,mt2712-sysirq", "mediatek,mt6577-sysirq": for MT2712 "mediatek,mt2701-sysirq", "mediatek,mt6577-sysirq": for MT2701 + "mediatek,mt8365-sysirq", "mediatek,mt6577-sysirq": for MT8365 - interrupt-controller : Identifies the node as an interrupt controller - #interrupt-cells : Use the same format as specified by GIC in arm,gic.txt. - reg: Physical base address of the intpol registers and length of memory diff --git a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml index 9acc21028413..b7c5022eec84 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml @@ -53,8 +53,8 @@ allOf: maxItems: 1 reg-names: items: - - const: 'mux status' - - const: 'mux mask' + - const: mux status + - const: mux mask required: - interrupts else: diff --git a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml index 27b798bfe29b..4ff609faba32 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Microsemi Ocelot SoC ICPU Interrupt Controller diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml index 94791e261c42..a106ba6e810b 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml @@ -26,6 +26,8 @@ properties: compatible: items: - enum: + - qcom,qdu1000-pdc + - qcom,sa8775p-pdc - qcom,sc7180-pdc - qcom,sc7280-pdc - qcom,sc8280xp-pdc @@ -53,7 +55,7 @@ properties: qcom,pdc-ranges: $ref: /schemas/types.yaml#/definitions/uint32-matrix minItems: 1 - maxItems: 32 # no hard limit + maxItems: 128 # no hard limit items: items: - description: starting PDC port diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml index 63bc89e13480..f75736a061af 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml @@ -59,6 +59,7 @@ properties: - enum: - sifive,fu540-c000-plic - starfive,jh7100-plic + - starfive,jh7110-plic - canaan,k210-plic - const: sifive,plic-1.0.0 - items: @@ -90,7 +91,7 @@ properties: riscv,cpu-intc node, which has a riscv node as parent. riscv,ndev: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: Specifies how many external interrupts are supported by this controller. diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt index ced6014061a3..977d7ed3670e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt @@ -6,11 +6,7 @@ and PL310 L2 Cache IRQs are controlled using System Configuration registers. This driver is used to unmask them prior to use. Required properties: -- compatible : Should be set to one of: - "st,stih415-irq-syscfg" - "st,stih416-irq-syscfg" - "st,stih407-irq-syscfg" - "st,stid127-irq-syscfg" +- compatible : Should be "st,stih407-irq-syscfg" - st,syscfg : Phandle to Cortex-A9 IRQ system config registers - st,irq-device : Array of IRQs to enable - should be 2 in length - st,fiq-device : Array of FIQs to enable - should be 2 in length @@ -25,11 +21,10 @@ Optional properties: Example: irq-syscfg { - compatible = "st,stih416-irq-syscfg"; + compatible = "st,stih407-irq-syscfg"; st,syscfg = <&syscfg_cpu>; st,irq-device = <ST_IRQ_SYSCFG_PMU_0>, <ST_IRQ_SYSCFG_PMU_1>; st,fiq-device = <ST_IRQ_SYSCFG_DISABLED>, <ST_IRQ_SYSCFG_DISABLED>; - st,invert-ext = <(ST_IRQ_SYSCFG_EXT_1_INV | ST_IRQ_SYSCFG_EXT_3_INV)>; }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml index 1151518859bd..6a49d74b992a 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml @@ -85,6 +85,9 @@ properties: description: Array of phandles to DMA controllers where the unmapped events originate. + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/iommu/apple,sart.yaml b/Documentation/devicetree/bindings/iommu/apple,sart.yaml index 1524fa3094ef..e87c1520fea6 100644 --- a/Documentation/devicetree/bindings/iommu/apple,sart.yaml +++ b/Documentation/devicetree/bindings/iommu/apple,sart.yaml @@ -28,9 +28,13 @@ description: properties: compatible: - enum: - - apple,t6000-sart - - apple,t8103-sart + oneOf: + - items: + - const: apple,t8112-sart + - const: apple,t6000-sart + - enum: + - apple,t6000-sart + - apple,t8103-sart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 807cb511fe18..ba677d401e24 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -53,6 +53,7 @@ properties: - qcom,sm8250-smmu-500 - qcom,sm8350-smmu-500 - qcom,sm8450-smmu-500 + - qcom,sm8550-smmu-500 - const: qcom,smmu-500 - const: arm,mmu-500 @@ -75,9 +76,22 @@ properties: - qcom,sm8350-smmu-500 - qcom,sm8450-smmu-500 - const: arm,mmu-500 - - - description: Qcom Adreno GPUs implementing "arm,smmu-500" + - description: Qcom Adreno GPUs implementing "qcom,smmu-500" and "arm,mmu-500" + items: + - enum: + - qcom,sc7280-smmu-500 + - qcom,sm6115-smmu-500 + - qcom,sm6125-smmu-500 + - qcom,sm8150-smmu-500 + - qcom,sm8250-smmu-500 + - qcom,sm8350-smmu-500 + - const: qcom,adreno-smmu + - const: qcom,smmu-500 + - const: arm,mmu-500 + - description: Qcom Adreno GPUs implementing "arm,mmu-500" (legacy binding) + deprecated: true items: + # Do not add additional SoC to this list. Instead use previous list. - enum: - qcom,sc7280-smmu-500 - qcom,sm8150-smmu-500 @@ -364,6 +378,30 @@ allOf: - description: interface clock required to access smmu's registers through the TCU's programming interface. + - if: + properties: + compatible: + items: + - enum: + - qcom,sm6115-smmu-500 + - qcom,sm6125-smmu-500 + - const: qcom,adreno-smmu + - const: qcom,smmu-500 + - const: arm,mmu-500 + then: + properties: + clock-names: + items: + - const: mem + - const: hlos + - const: iface + + clocks: + items: + - description: GPU memory bus clock + - description: Voter clock required for HLOS SMMU access + - description: Interface clock required for register access + # Disallow clocks for all other platforms with specific compatibles - if: properties: @@ -383,12 +421,11 @@ allOf: - qcom,sdm845-smmu-500 - qcom,sdx55-smmu-500 - qcom,sdx65-smmu-500 - - qcom,sm6115-smmu-500 - - qcom,sm6125-smmu-500 - qcom,sm6350-smmu-500 - qcom,sm6375-smmu-500 - qcom,sm8350-smmu-500 - qcom,sm8450-smmu-500 + - qcom,sm8550-smmu-500 then: properties: clock-names: false diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt deleted file mode 100644 index e6cecfd360eb..000000000000 --- a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt +++ /dev/null @@ -1,122 +0,0 @@ -* QCOM IOMMU v1 Implementation - -Qualcomm "B" family devices which are not compatible with arm-smmu have -a similar looking IOMMU but without access to the global register space, -and optionally requiring additional configuration to route context irqs -to non-secure vs secure interrupt line. - -** Required properties: - -- compatible : Should be one of: - - "qcom,msm8916-iommu" - "qcom,msm8953-iommu" - - Followed by "qcom,msm-iommu-v1". - -- clock-names : Should be a pair of "iface" (required for IOMMUs - register group access) and "bus" (required for - the IOMMUs underlying bus access). - -- clocks : Phandles for respective clocks described by - clock-names. - -- #address-cells : must be 1. - -- #size-cells : must be 1. - -- #iommu-cells : Must be 1. Index identifies the context-bank #. - -- ranges : Base address and size of the iommu context banks. - -- qcom,iommu-secure-id : secure-id. - -- List of sub-nodes, one per translation context bank. Each sub-node - has the following required properties: - - - compatible : Should be one of: - - "qcom,msm-iommu-v1-ns" : non-secure context bank - - "qcom,msm-iommu-v1-sec" : secure context bank - - reg : Base address and size of context bank within the iommu - - interrupts : The context fault irq. - -** Optional properties: - -- reg : Base address and size of the SMMU local base, should - be only specified if the iommu requires configuration - for routing of context bank irq's to secure vs non- - secure lines. (Ie. if the iommu contains secure - context banks) - - -** Examples: - - apps_iommu: iommu@1e20000 { - #address-cells = <1>; - #size-cells = <1>; - #iommu-cells = <1>; - compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; - ranges = <0 0x1e20000 0x40000>; - reg = <0x1ef0000 0x3000>; - clocks = <&gcc GCC_SMMU_CFG_CLK>, - <&gcc GCC_APSS_TCU_CLK>; - clock-names = "iface", "bus"; - qcom,iommu-secure-id = <17>; - - // mdp_0: - iommu-ctx@4000 { - compatible = "qcom,msm-iommu-v1-ns"; - reg = <0x4000 0x1000>; - interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>; - }; - - // venus_ns: - iommu-ctx@5000 { - compatible = "qcom,msm-iommu-v1-sec"; - reg = <0x5000 0x1000>; - interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>; - }; - }; - - gpu_iommu: iommu@1f08000 { - #address-cells = <1>; - #size-cells = <1>; - #iommu-cells = <1>; - compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; - ranges = <0 0x1f08000 0x10000>; - clocks = <&gcc GCC_SMMU_CFG_CLK>, - <&gcc GCC_GFX_TCU_CLK>; - clock-names = "iface", "bus"; - qcom,iommu-secure-id = <18>; - - // gfx3d_user: - iommu-ctx@1000 { - compatible = "qcom,msm-iommu-v1-ns"; - reg = <0x1000 0x1000>; - interrupts = <GIC_SPI 241 IRQ_TYPE_LEVEL_HIGH>; - }; - - // gfx3d_priv: - iommu-ctx@2000 { - compatible = "qcom,msm-iommu-v1-ns"; - reg = <0x2000 0x1000>; - interrupts = <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>; - }; - }; - - ... - - venus: video-codec@1d00000 { - ... - iommus = <&apps_iommu 5>; - }; - - mdp: mdp@1a01000 { - ... - iommus = <&apps_iommu 4>; - }; - - gpu@1c00000 { - ... - iommus = <&gpu_iommu 1>, <&gpu_iommu 2>; - }; diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml new file mode 100644 index 000000000000..d9fabdf930d9 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/qcom,iommu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies legacy IOMMU implementations + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: | + Qualcomm "B" family devices which are not compatible with arm-smmu have + a similar looking IOMMU, but without access to the global register space + and optionally requiring additional configuration to route context IRQs + to non-secure vs secure interrupt line. + +properties: + compatible: + items: + - enum: + - qcom,msm8916-iommu + - qcom,msm8953-iommu + - const: qcom,msm-iommu-v1 + + clocks: + items: + - description: Clock required for IOMMU register group access + - description: Clock required for underlying bus access + + clock-names: + items: + - const: iface + - const: bus + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + + ranges: true + + qcom,iommu-secure-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The SCM secure ID of the IOMMU instance. + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + '#iommu-cells': + const: 1 + +patternProperties: + "^iommu-ctx@[0-9a-f]+$": + type: object + additionalProperties: false + properties: + compatible: + enum: + - qcom,msm-iommu-v1-ns + - qcom,msm-iommu-v1-sec + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + required: + - compatible + - interrupts + - reg + +required: + - compatible + - clocks + - clock-names + - ranges + - '#address-cells' + - '#size-cells' + - '#iommu-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-msm8916.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + apps_iommu: iommu@1e20000 { + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1"; + reg = <0x01ef0000 0x3000>; + clocks = <&gcc GCC_SMMU_CFG_CLK>, + <&gcc GCC_APSS_TCU_CLK>; + clock-names = "iface", "bus"; + qcom,iommu-secure-id = <17>; + #address-cells = <1>; + #size-cells = <1>; + #iommu-cells = <1>; + ranges = <0 0x01e20000 0x40000>; + + /* mdp_0: */ + iommu-ctx@4000 { + compatible = "qcom,msm-iommu-v1-ns"; + reg = <0x4000 0x1000>; + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index 72308a4c14e7..be90f68c11d1 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -74,16 +74,16 @@ properties: renesas,ipmmu-main: $ref: /schemas/types.yaml#/definitions/phandle-array items: - - items: + - minItems: 1 + items: - description: phandle to main IPMMU - - description: the interrupt bit number associated with the particular - cache IPMMU device. The interrupt bit number needs to match the main - IPMMU IMSSTR register. Only used by cache IPMMU instances. + - description: + The interrupt bit number associated with the particular cache + IPMMU device. If present, the interrupt bit number needs to match + the main IPMMU IMSSTR register. Only used by cache IPMMU + instances. description: - Reference to the main IPMMU phandle plus 1 cell. The cell is - the interrupt bit number associated with the particular cache IPMMU - device. The interrupt bit number needs to match the main IPMMU IMSSTR - register. Only used by cache IPMMU instances. + Reference to the main IPMMU. required: - compatible @@ -109,6 +109,22 @@ allOf: required: - power-domains + - if: + properties: + compatible: + contains: + const: renesas,rcar-gen4-ipmmu-vmsa + then: + properties: + renesas,ipmmu-main: + items: + - maxItems: 1 + else: + properties: + renesas,ipmmu-main: + items: + - minItems: 2 + examples: - | #include <dt-bindings/clock/r8a7791-cpg-mssr.h> diff --git a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml index 14bebe1ad8f8..34ef5215c150 100644 --- a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml +++ b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml @@ -58,7 +58,7 @@ examples: #include <dt-bindings/leds/common.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml b/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml index d1b01bae9f63..3c0431c51159 100644 --- a/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml +++ b/Documentation/devicetree/bindings/leds/issi,is31fl319x.yaml @@ -165,7 +165,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/leds/common.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/leds/leds-aw2013.yaml b/Documentation/devicetree/bindings/leds/leds-aw2013.yaml index 6c3ea0f06cef..08f3e1cfc1b1 100644 --- a/Documentation/devicetree/bindings/leds/leds-aw2013.yaml +++ b/Documentation/devicetree/bindings/leds/leds-aw2013.yaml @@ -54,7 +54,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/leds/common.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/leds/leds-rt4505.yaml b/Documentation/devicetree/bindings/leds/leds-rt4505.yaml index cb71fec173c1..bfd0e240f7d6 100644 --- a/Documentation/devicetree/bindings/leds/leds-rt4505.yaml +++ b/Documentation/devicetree/bindings/leds/leds-rt4505.yaml @@ -39,7 +39,7 @@ examples: - | #include <dt-bindings/leds/common.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/leds/ti,tca6507.yaml b/Documentation/devicetree/bindings/leds/ti,tca6507.yaml index 9ce5c0f16e17..4b1575e4f180 100644 --- a/Documentation/devicetree/bindings/leds/ti,tca6507.yaml +++ b/Documentation/devicetree/bindings/leds/ti,tca6507.yaml @@ -87,7 +87,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/leds/common.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml index dfd26b998189..385809ed1569 100644 --- a/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml +++ b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mailbox/amlogic,meson-gxbb-mhu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mailbox/amlogic,meson-gxbb-mhu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson Message-Handling-Unit Controller diff --git a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml index 5c5c328b3134..4c0668e5f0bd 100644 --- a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml @@ -29,6 +29,7 @@ properties: items: - enum: - apple,t8103-asc-mailbox + - apple,t8112-asc-mailbox - apple,t6000-asc-mailbox - const: apple,asc-mailbox-v4 @@ -39,6 +40,7 @@ properties: items: - enum: - apple,t8103-m3-mailbox + - apple,t8112-m3-mailbox - apple,t6000-m3-mailbox - const: apple,m3-mailbox-v2 diff --git a/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml index 935937c67133..404477910f02 100644 --- a/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mailbox/microchip,mpfs-mailbox.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mailbox/microchip,mpfs-mailbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) mailbox controller diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index d888ead09282..8f924bb4c583 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mailbox/qcom,apcs-kpss-global.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mailbox/qcom,apcs-kpss-global.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm APCS global block @@ -91,20 +91,21 @@ allOf: - if: properties: compatible: - enum: - - qcom,sdx55-apcs-gcc + contains: + enum: + - qcom,sdx55-apcs-gcc then: properties: clocks: items: + - description: reference clock - description: primary pll parent of the clock driver - description: auxiliary parent - - description: reference clock clock-names: items: + - const: ref - const: pll - const: aux - - const: ref - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml index bdfb4a8220c5..b526f9c0c272 100644 --- a/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/sprd-mailbox.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mailbox/sprd-mailbox.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mailbox/sprd-mailbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Spreadtrum mailbox controller diff --git a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml index 0dfe05a04dd0..134fd223a02b 100644 --- a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mailbox/st,stm32-ipcc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mailbox/st,stm32-ipcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 IPC controller diff --git a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml index 2193141dd7fd..374ffe64016f 100644 --- a/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mailbox/xlnx,zynqmp-ipi-mailbox.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mailbox/xlnx,zynqmp-ipi-mailbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx IPI(Inter Processor Interrupt) mailbox controller @@ -72,6 +72,7 @@ patternProperties: '^mailbox@[0-9a-f]+$': description: Internal ipi mailbox node type: object # DT nodes are json objects + additionalProperties: false properties: xlnx,ipi-id: description: diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml index 53945c61325c..42dfe22ad5f1 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml @@ -11,7 +11,7 @@ maintainers: - Maxime Ripard <mripard@kernel.org> allOf: - - $ref: "rc.yaml#" + - $ref: rc.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml index 9d44236f2deb..a4f06bbdfe49 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/allwinner,sun50i-h6-vpu-g2.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/allwinner,sun50i-h6-vpu-g2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Hantro G2 VPU codec implemented on Allwinner H6 SoC diff --git a/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml b/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml index e551be5e680e..f23fa6d06ad0 100644 --- a/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml @@ -2,8 +2,8 @@ # Copyright 2020 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/amlogic,axg-ge2d.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/amlogic,axg-ge2d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic GE2D Acceleration Unit diff --git a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml index b827edabcafa..55930f6107c9 100644 --- a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/amlogic,gx-vdec.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/amlogic,gx-vdec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Video Decoder diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml index 4432fea32650..377acce93423 100644 --- a/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/amlogic,meson-ir-tx.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/amlogic,meson-ir-tx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson IR transmitter diff --git a/Documentation/devicetree/bindings/media/amlogic,meson6-ir.yaml b/Documentation/devicetree/bindings/media/amlogic,meson6-ir.yaml new file mode 100644 index 000000000000..3f9fa92703bb --- /dev/null +++ b/Documentation/devicetree/bindings/media/amlogic,meson6-ir.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/amlogic,meson6-ir.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson IR remote control receiver + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +allOf: + - $ref: rc.yaml# + +properties: + compatible: + oneOf: + - enum: + - amlogic,meson6-ir + - amlogic,meson8b-ir + - amlogic,meson-gxbb-ir + - items: + - const: amlogic,meson-gx-ir + - const: amlogic,meson-gxbb-ir + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + ir-receiver@c8100480 { + compatible = "amlogic,meson6-ir"; + reg = <0xc8100480 0x20>; + interrupts = <GIC_SPI 15 IRQ_TYPE_EDGE_RISING>; + }; diff --git a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt deleted file mode 100644 index 0bf6fb7fbeab..000000000000 --- a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt +++ /dev/null @@ -1,16 +0,0 @@ -Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE) - -Required properties: - -- compatible : should be one of: - "samsung,exynos4212-fimc-lite" for Exynos4212/4412 SoCs, - "samsung,exynos5250-fimc-lite" for Exynos5250 compatible - devices; -- reg : physical base address and size of the device memory mapped - registers; -- interrupts : should contain FIMC-LITE interrupt; -- clocks : FIMC LITE gate clock should be specified in this property. -- clock-names : should contain "flite" entry. - -Each FIMC device should have an alias in the aliases node, in the form of -fimc-lite<n>, where <n> is an integer specifying the IP block instance. diff --git a/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt deleted file mode 100644 index 32ced99d4244..000000000000 --- a/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt +++ /dev/null @@ -1,50 +0,0 @@ -Exynos4x12 SoC series Imaging Subsystem (FIMC-IS) - -The FIMC-IS is a subsystem for processing image signal from an image sensor. -The Exynos4x12 SoC series FIMC-IS V1.5 comprises of a dedicated ARM Cortex-A5 -processor, ISP, DRC and FD IP blocks and peripheral devices such as UART, I2C -and SPI bus controllers, PWM and ADC. - -fimc-is node ------------- - -Required properties: -- compatible : should be "samsung,exynos4212-fimc-is" for Exynos4212 and - Exynos4412 SoCs; -- reg : physical base address and length of the registers set; -- interrupts : must contain two FIMC-IS interrupts, in order: ISP0, ISP1; -- clocks : list of clock specifiers, corresponding to entries in - clock-names property; -- clock-names : must contain "ppmuispx", "ppmuispx", "lite0", "lite1" - "mpll", "sysreg", "isp", "drc", "fd", "mcuisp", "gicisp", - "pwm_isp", "mcuctl_isp", "uart", "ispdiv0", "ispdiv1", - "mcuispdiv0", "mcuispdiv1", "aclk200", "div_aclk200", - "aclk400mcuisp", "div_aclk400mcuisp" entries, - matching entries in the clocks property. -pmu subnode ------------ - -Required properties: - - reg : must contain PMU physical base address and size of the register set. - -The following are the FIMC-IS peripheral device nodes and can be specified -either standalone or as the fimc-is node child nodes. - -i2c-isp (ISP I2C bus controller) nodes ------------------------------------------- - -Required properties: - -- compatible : should be "samsung,exynos4212-i2c-isp" for Exynos4212 and - Exynos4412 SoCs; -- reg : physical base address and length of the registers set; -- clocks : must contain gate clock specifier for this controller; -- clock-names : must contain "i2c_isp" entry. - -For the above nodes it is required to specify a pinctrl state named "default", -according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt. - -Device tree nodes of the image sensors' controlled directly by the FIMC-IS -firmware must be child nodes of their corresponding ISP I2C bus controller node. -The data link of these image sensors must be specified using the common video -interfaces bindings, defined in video-interfaces.txt. diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml b/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml index 61072745b983..008c007ed702 100644 --- a/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml @@ -23,6 +23,9 @@ properties: description: autosuspend delay time in milliseconds $ref: /schemas/types.yaml#/definitions/uint32 + wakeup-source: + description: IR receiver can wake-up the system. + required: - compatible - gpios diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml index 1d6af1bf9a6b..be00de2f2d58 100644 --- a/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml +++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9p031.yaml @@ -82,7 +82,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml index e53b8d65f381..088022f88010 100644 --- a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml +++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml @@ -55,7 +55,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml index af8ada55b3f2..4e69b6a7ffcc 100644 --- a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml +++ b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Chrontel HDMI-CEC Controller diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml index 82d3d18c16a1..a0855d3b7577 100644 --- a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml @@ -38,7 +38,7 @@ properties: dongwoon,aac-mode: description: Indication of AAC mode select. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: - 1 # AAC2 mode(operation time# 0.48 x Tvib) - 2 # AAC3 mode(operation time# 0.70 x Tvib) @@ -50,7 +50,7 @@ properties: description: Number of AAC Timing count that controlled by one 6-bit period of vibration register AACT[5:0], the unit of which is 100 us. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 default: 0x20 minimum: 0x00 maximum: 0x3f @@ -59,7 +59,7 @@ properties: description: Indication of VCM internal clock dividing rate select, as one multiple factor to calculate VCM ring periodic time Tvib. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: - 0 # Dividing Rate - 2 - 1 # Dividing Rate - 1 diff --git a/Documentation/devicetree/bindings/media/i2c/imx219.yaml b/Documentation/devicetree/bindings/media/i2c/imx219.yaml index 5fc96944b448..07d088cf66e0 100644 --- a/Documentation/devicetree/bindings/media/i2c/imx219.yaml +++ b/Documentation/devicetree/bindings/media/i2c/imx219.yaml @@ -83,7 +83,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/imx258.yaml b/Documentation/devicetree/bindings/media/i2c/imx258.yaml index cde0f7383b2a..80d24220baa0 100644 --- a/Documentation/devicetree/bindings/media/i2c/imx258.yaml +++ b/Documentation/devicetree/bindings/media/i2c/imx258.yaml @@ -84,7 +84,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -111,7 +111,7 @@ examples: }; - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml index 0c4213adbf6a..a37447256f8d 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -86,7 +86,7 @@ properties: is 100000 micro volts maxim,gpio-poc: - $ref: '/schemas/types.yaml#/definitions/uint32-array' + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 2 maxItems: 2 description: | @@ -156,6 +156,7 @@ properties: patternProperties: "^i2c@[0-3]$": type: object + additionalProperties: false description: | Child node of the i2c bus multiplexer which represents a GMSL link. Each serializer device on the GMSL link remote end is represented with @@ -167,6 +168,12 @@ properties: description: The index of the GMSL channel. maxItems: 1 + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + patternProperties: "^camera@[a-f0-9]+$": type: object diff --git a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml index edde4201116f..f8ace8cbccdb 100644 --- a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml +++ b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml @@ -106,7 +106,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/media/video-interfaces.h> - i2c2 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/ov2685.txt b/Documentation/devicetree/bindings/media/i2c/ov2685.txt deleted file mode 100644 index 625c4a8c0d53..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/ov2685.txt +++ /dev/null @@ -1,41 +0,0 @@ -* Omnivision OV2685 MIPI CSI-2 sensor - -Required Properties: -- compatible: shall be "ovti,ov2685" -- clocks: reference to the xvclk input clock -- clock-names: shall be "xvclk" -- avdd-supply: Analog voltage supply, 2.8 volts -- dovdd-supply: Digital I/O voltage supply, 1.8 volts -- dvdd-supply: Digital core voltage supply, 1.8 volts -- reset-gpios: Low active reset gpio - -The device node shall contain one 'port' child node with an -'endpoint' subnode for its digital output video port, -in accordance with the video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. -The endpoint optional property 'data-lanes' shall be "<1>". - -Example: -&i2c7 { - ov2685: camera-sensor@3c { - compatible = "ovti,ov2685"; - reg = <0x3c>; - pinctrl-names = "default"; - pinctrl-0 = <&clk_24m_cam>; - - clocks = <&cru SCLK_TESTCLKOUT1>; - clock-names = "xvclk"; - - avdd-supply = <&pp2800_cam>; - dovdd-supply = <&pp1800>; - dvdd-supply = <&pp1800>; - reset-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>; - - port { - ucam_out: endpoint { - remote-endpoint = <&mipi_in_ucam>; - data-lanes = <1>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml index e17288d57981..57f5e48fd8e0 100644 --- a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Omnivision OV8856 CMOS Sensor maintainers: - - Dongchun Zhu <dongchun.zhu@mediatek.com> + - Sakari Ailus <sakari.ailus@linux.intel.com> description: |- The Omnivision OV8856 is a high performance, 1/4-inch, 8 megapixel, CMOS diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml index 54df9d73dc86..763cebe03dc2 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml @@ -88,7 +88,7 @@ properties: properties: link-frequencies: true ovti,mipi-clock-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: Definition of MIPI clock voltage unit. This entry corresponds to the link speed defined by the 'link-frequencies' property. diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml new file mode 100644 index 000000000000..8b389314c352 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov2685.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OmniVision OV2685 Image Sensor + +maintainers: + - Shunqian Zheng <zhengsq@rock-chips.com> + +properties: + compatible: + const: ovti,ov2685 + + reg: + maxItems: 1 + + clocks: + items: + - description: XVCLK clock + + clock-names: + items: + - const: xvclk + + dvdd-supply: + description: Digital Domain Power Supply + + avdd-supply: + description: Analog Domain Power Supply + + dovdd-supply: + description: I/O Domain Power Supply + + reset-gpios: + maxItems: 1 + description: Reset Pin GPIO Control (active low) + + port: + description: MIPI CSI-2 transmitter port + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + maxItems: 2 + + required: + - data-lanes + +required: + - compatible + - reg + - clocks + - clock-names + - dvdd-supply + - avdd-supply + - dovdd-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3399-cru.h> + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ov2685: camera-sensor@3c { + compatible = "ovti,ov2685"; + reg = <0x3c>; + pinctrl-names = "default"; + pinctrl-0 = <&clk_24m_cam>; + + clocks = <&cru SCLK_TESTCLKOUT1>; + clock-names = "xvclk"; + + avdd-supply = <&pp2800_cam>; + dovdd-supply = <&pp1800>; + dvdd-supply = <&pp1800>; + reset-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>; + + port { + ucam_out: endpoint { + remote-endpoint = <&mipi_in_ucam>; + data-lanes = <1>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml index 61e4e9cf8783..1f497679168c 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml @@ -81,7 +81,7 @@ examples: #include <dt-bindings/clock/sun8i-v3s-ccu.h> #include <dt-bindings/gpio/gpio.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml index 161e6d598e1c..5d24edba8f99 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml @@ -107,7 +107,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/media/video-interfaces.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; ov772x: camera@21 { diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml index 6bac326dceaf..8a70e23ba6ab 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml @@ -82,7 +82,7 @@ examples: #include <dt-bindings/clock/sun8i-a83t-ccu.h> #include <dt-bindings/gpio/gpio.h> - i2c2 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml index 0c4654e70d46..79a7658f6d05 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml @@ -78,7 +78,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml b/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml index f50e54a722eb..34a05df786ce 100644 --- a/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml +++ b/Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml @@ -50,7 +50,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/samsung,s5k5baf.yaml b/Documentation/devicetree/bindings/media/i2c/samsung,s5k5baf.yaml new file mode 100644 index 000000000000..c8f2955e0825 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/samsung,s5k5baf.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/samsung,s5k5baf.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor with embedded SoC ISP + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + +properties: + compatible: + const: samsung,s5k5baf + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: mclk + + clock-frequency: + default: 24000000 + description: mclk clock frequency + + rstn-gpios: + maxItems: 1 + description: RSTN pin + + stbyn-gpios: + maxItems: 1 + description: STDBYN pin + + vdda-supply: + description: Analog power supply 2.8V (2.6V to 3.0V) + + vddio-supply: + description: I/O power supply 1.8V (1.65V to 1.95V) or 2.8V (2.5V to 3.1V) + + vddreg-supply: + description: + Regulator input power supply 1.8V (1.7V to 1.9V) or 2.8V (2.6V to 3.0) + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + items: + - const: 1 + +required: + - compatible + - clocks + - clock-names + - rstn-gpios + - stbyn-gpios + - vdda-supply + - vddio-supply + - vddreg-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@2d { + compatible = "samsung,s5k5baf"; + reg = <0x2d>; + clocks = <&camera 0>; + clock-names = "mclk"; + clock-frequency = <24000000>; + rstn-gpios = <&gpl2 1 GPIO_ACTIVE_LOW>; + stbyn-gpios = <&gpl2 0 GPIO_ACTIVE_LOW>; + vdda-supply = <&cam_io_en_reg>; + vddio-supply = <&vtcam_reg>; + vddreg-supply = <&vt_core_15v_reg>; + + port { + endpoint { + remote-endpoint = <&csis1_ep>; + data-lanes = <1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/samsung,s5k6a3.yaml b/Documentation/devicetree/bindings/media/i2c/samsung,s5k6a3.yaml new file mode 100644 index 000000000000..7e83a94124b5 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/samsung,s5k6a3.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/samsung,s5k6a3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5K6A3(YX) raw image sensor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + +description: + S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data + interfaces and CCI (I2C compatible) control bus. + +properties: + compatible: + const: samsung,s5k6a3 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: extclk + + clock-frequency: + default: 24000000 + description: extclk clock frequency + + gpios: + maxItems: 1 + description: GPIO connected to the RESET pin + + afvdd-supply: + description: AF (actuator) voltage supply + + svdda-supply: + description: Core voltage supply + + svddio-supply: + description: I/O voltage supply + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + items: + - const: 1 + +required: + - compatible + - clocks + - clock-names + - gpios + - afvdd-supply + - svdda-supply + - svddio-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@10 { + compatible = "samsung,s5k6a3"; + reg = <0x10>; + clock-frequency = <24000000>; + clocks = <&camera 1>; + clock-names = "extclk"; + gpios = <&gpm1 6 GPIO_ACTIVE_LOW>; + afvdd-supply = <&ldo19_reg>; + svdda-supply = <&cam_io_reg>; + svddio-supply = <&ldo19_reg>; + + port { + endpoint { + remote-endpoint = <&csis1_ep>; + data-lanes = <1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml index c9760f895b3e..e2470dd5920c 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml @@ -97,7 +97,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml index 4271fc3cc623..b397a730ee94 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml @@ -52,7 +52,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml index 21377daae026..a531badc16c9 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml @@ -12,15 +12,26 @@ maintainers: description: |- The Sony IMX290 is a 1/2.8-Inch CMOS Solid-state image sensor with Square - Pixel for Color Cameras. It is programmable through I2C and 4-wire - interfaces. The sensor output is available via CMOS logic parallel SDR - output, Low voltage LVDS DDR output and CSI-2 serial data output. The CSI-2 - bus is the default. No bindings have been defined for the other busses. + Pixel, available in either mono or colour variants. It is programmable + through I2C and 4-wire interfaces. + + The sensor output is available via CMOS logic parallel SDR output, Low voltage + LVDS DDR output and CSI-2 serial data output. The CSI-2 bus is the default. + No bindings have been defined for the other busses. + + imx290lqr is the full model identifier for the colour variant. "sony,imx290" + is treated the same as this as it was the original compatible string. + imx290llr is the mono version of the sensor. properties: compatible: - enum: - - sony,imx290 + oneOf: + - enum: + - sony,imx290lqr # Colour + - sony,imx290llr # Monochrome + - sony,imx327lqr # Colour + - const: sony,imx290 + deprecated: true reg: maxItems: 1 @@ -101,7 +112,7 @@ examples: #size-cells = <0>; imx290: camera-sensor@1a { - compatible = "sony,imx290"; + compatible = "sony,imx290lqr"; reg = <0x1a>; pinctrl-names = "default"; diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml index f5055b9db693..bce57b22f7b6 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml @@ -65,7 +65,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -82,7 +82,7 @@ examples: imx334: endpoint { remote-endpoint = <&cam>; data-lanes = <1 2 3 4>; - link-frequencies = /bits/ 64 <891000000>; + link-frequencies = /bits/ 64 <891000000 445500000>; }; }; }; diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml index cf2ca2702cc9..a167dcdb3a32 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml @@ -66,7 +66,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml index 60dc25ff2b9e..d9b7815650fd 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml @@ -77,7 +77,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml index 9cfc0c7d23e0..7032c7e15039 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml @@ -27,7 +27,7 @@ properties: maxItems: 1 mediatek,gce-client-reg: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: items: - description: phandle of GCE diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml index 71595c013dbb..e5448c60e3eb 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegdec.yaml @@ -26,11 +26,6 @@ properties: Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. Ports are according to the HW. - dma-ranges: - maxItems: 1 - description: | - Describes the physical address space of IOMMU maps to memory. - "#address-cells": const: 2 @@ -89,7 +84,6 @@ required: - compatible - power-domains - iommus - - dma-ranges - ranges additionalProperties: false @@ -115,7 +109,6 @@ examples: <&iommu_vpp M4U_PORT_L19_JPGDEC_BSDMA1>, <&iommu_vpp M4U_PORT_L19_JPGDEC_BUFF_OFFSET1>, <&iommu_vpp M4U_PORT_L19_JPGDEC_BUFF_OFFSET0>; - dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; #address-cells = <2>; #size-cells = <2>; ranges; diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml index 95990539f7c0..596186497b68 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml @@ -26,11 +26,6 @@ properties: Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. Ports are according to the HW. - dma-ranges: - maxItems: 1 - description: | - Describes the physical address space of IOMMU maps to memory. - "#address-cells": const: 2 @@ -89,7 +84,6 @@ required: - compatible - power-domains - iommus - - dma-ranges - ranges additionalProperties: false @@ -113,7 +107,6 @@ examples: <&iommu_vpp M4U_PORT_L20_JPGENC_C_RDMA>, <&iommu_vpp M4U_PORT_L20_JPGENC_Q_TABLE>, <&iommu_vpp M4U_PORT_L20_JPGENC_BSDMA>; - dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; #address-cells = <2>; #size-cells = <2>; ranges; diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml index aa55ca65d6ed..fad59b486d5d 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml @@ -56,11 +56,6 @@ properties: List of the hardware port in respective IOMMU block for current Socs. Refer to bindings/iommu/mediatek,iommu.yaml. - dma-ranges: - maxItems: 1 - description: | - Describes the physical address space of IOMMU maps to memory. - mediatek,vpu: $ref: /schemas/types.yaml#/definitions/phandle description: diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml index 0f2ea8d9a10c..a2051b31fa29 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml @@ -49,11 +49,6 @@ properties: List of the hardware port in respective IOMMU block for current Socs. Refer to bindings/iommu/mediatek,iommu.yaml. - dma-ranges: - maxItems: 1 - description: | - Describes the physical address space of IOMMU maps to memory. - mediatek,vpu: $ref: /schemas/types.yaml#/definitions/phandle description: diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml index c4f20acdc1f8..dca9b0c5e106 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$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 @@ -61,7 +61,10 @@ properties: - mediatek,mt8195-vcodec-dec reg: - maxItems: 1 + minItems: 1 + items: + - description: VDEC_SYS register space + - description: VDEC_RACING_CTRL register space iommus: minItems: 1 @@ -76,11 +79,6 @@ properties: The node of system control processor (SCP), using the remoteproc & rpmsg framework. - dma-ranges: - maxItems: 1 - description: | - Describes the physical address space of IOMMU maps to memory. - "#address-cells": const: 2 @@ -91,17 +89,19 @@ properties: # Required child node: patternProperties: - '^vcodec-lat@[0-9a-f]+$': + '^video-codec@[0-9a-f]+$': type: object properties: compatible: enum: + - mediatek,mtk-vcodec-core - mediatek,mtk-vcodec-lat - mediatek,mtk-vcodec-lat-soc reg: maxItems: 1 + description: VDEC_MISC register space interrupts: maxItems: 1 @@ -114,68 +114,13 @@ patternProperties: Refer to bindings/iommu/mediatek,iommu.yaml. clocks: + minItems: 4 maxItems: 5 clock-names: - items: - - const: sel - - const: soc-vdec - - const: soc-lat - - const: vdec - - const: top - - assigned-clocks: - maxItems: 1 - - assigned-clock-parents: - maxItems: 1 - - power-domains: - maxItems: 1 - - required: - - compatible - - reg - - iommus - - clocks - - clock-names - - assigned-clocks - - assigned-clock-parents - - power-domains - - additionalProperties: false - - '^vcodec-core@[0-9a-f]+$': - type: object - - properties: - compatible: - const: mediatek,mtk-vcodec-core - - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - - iommus: - minItems: 1 - maxItems: 32 - description: | - List of the hardware port in respective IOMMU block for current Socs. - Refer to bindings/iommu/mediatek,iommu.yaml. - - clocks: + minItems: 4 maxItems: 5 - clock-names: - items: - - const: sel - - const: soc-vdec - - const: soc-lat - - const: vdec - - const: top - assigned-clocks: maxItems: 1 @@ -188,7 +133,6 @@ patternProperties: required: - compatible - reg - - interrupts - iommus - clocks - clock-names @@ -203,7 +147,6 @@ required: - reg - iommus - mediatek,scp - - dma-ranges - ranges if: @@ -211,12 +154,45 @@ if: compatible: contains: enum: + - mediatek,mtk-vcodec-core - mediatek,mtk-vcodec-lat then: required: - interrupts +allOf: + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8192-vcodec-dec + then: + properties: + clock-names: + items: + - const: sel + - const: soc-vdec + - const: soc-lat + - const: vdec + - const: top + + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8195-vcodec-dec + then: + properties: + clock-names: + items: + - const: sel + - const: vdec + - const: lat + - const: top + additionalProperties: false examples: @@ -236,12 +212,11 @@ examples: compatible = "mediatek,mt8192-vcodec-dec"; mediatek,scp = <&scp>; iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; - dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; #address-cells = <2>; #size-cells = <2>; ranges = <0 0 0 0x16000000 0 0x40000>; reg = <0 0x16000000 0 0x1000>; /* VDEC_SYS */ - vcodec-lat@10000 { + video-codec@10000 { compatible = "mediatek,mtk-vcodec-lat"; reg = <0 0x10000 0 0x800>; interrupts = <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH 0>; @@ -264,7 +239,7 @@ examples: power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>; }; - vcodec-core@25000 { + video-codec@25000 { compatible = "mediatek,mtk-vcodec-core"; reg = <0 0x25000 0 0x1000>; interrupts = <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH 0>; diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml index c8412e8ab353..37800e1908cc 100644 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml @@ -44,11 +44,6 @@ properties: Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. Ports are according to the HW. - dma-ranges: - maxItems: 1 - description: | - Describes the physical address space of IOMMU maps to memory. - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt b/Documentation/devicetree/bindings/media/meson-ir.txt deleted file mode 100644 index efd9d29a8f10..000000000000 --- a/Documentation/devicetree/bindings/media/meson-ir.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Amlogic Meson IR remote control receiver - -Required properties: - - compatible : depending on the platform this should be one of: - - "amlogic,meson6-ir" - - "amlogic,meson8b-ir" - - "amlogic,meson-gxbb-ir" - - reg : physical base address and length of the device registers - - interrupts : a single specifier for the interrupt from the device - -Optional properties: - - linux,rc-map-name: see rc.txt file in the same directory. - -Example: - - ir-receiver@c8100480 { - compatible= "amlogic,meson6-ir"; - reg = <0xc8100480 0x20>; - interrupts = <0 15 1>; - }; diff --git a/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml index 4b77103ca913..59b805ca47c5 100644 --- a/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml +++ b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/microchip,sama5d4-vdec.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/microchip,sama5d4-vdec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Hantro G1 VPU codec implemented on Microchip SAMA5D4 SoCs diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml new file mode 100644 index 000000000000..6038b9b5ab36 --- /dev/null +++ b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml @@ -0,0 +1,173 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/nxp,imx8-isi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX8 Image Sensing Interface + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: | + The Image Sensing Interface (ISI) combines image processing pipelines with + DMA engines to process and capture frames originating from a variety of + sources. The inputs to the ISI go through Pixel Link interfaces, and their + number and nature is SoC-dependent. They cover both capture interfaces (MIPI + CSI-2 RX, HDMI RX, ...) and display engine outputs for writeback support. + +properties: + compatible: + enum: + - fsl,imx8mn-isi + - fsl,imx8mp-isi + + reg: + maxItems: 1 + + clocks: + items: + - description: The AXI clock + - description: The APB clock + # TODO: Check if the per-channel ipg_proc_clk clocks need to be specified + # as well, in case some SoCs have the ability to control them separately. + # This may be the case of the i.MX8[DQ]X(P) + + clock-names: + items: + - const: axi + - const: apb + + fsl,blk-ctrl: + $ref: /schemas/types.yaml#/definitions/phandle + description: + A phandle referencing the block control that contains the CSIS to ISI + gasket. + + interrupts: + description: Processing pipeline interrupts, one per pipeline + minItems: 1 + maxItems: 2 + + power-domains: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Ports represent the Pixel Link inputs to the ISI. Their number and + assignment are model-dependent. Each port shall have a single endpoint. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - fsl,blk-ctrl + - ports + +allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx8mn-isi + then: + properties: + interrupts: + maxItems: 1 + ports: + properties: + port@0: + description: MIPI CSI-2 RX + required: + - port@0 + + - if: + properties: + compatible: + contains: + const: fsl,imx8mp-isi + then: + properties: + interrupts: + maxItems: 2 + ports: + properties: + port@0: + description: MIPI CSI-2 RX 0 + port@1: + description: MIPI CSI-2 RX 1 + required: + - port@0 + - port@1 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mn-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/imx8mn-power.h> + + isi@32e20000 { + compatible = "fsl,imx8mn-isi"; + reg = <0x32e20000 0x100>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MN_CLK_DISP_AXI_ROOT>, + <&clk IMX8MN_CLK_DISP_APB_ROOT>; + clock-names = "axi", "apb"; + fsl,blk-ctrl = <&disp_blk_ctrl>; + power-domains = <&disp_blk_ctrl IMX8MN_DISPBLK_PD_ISI>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + isi_in: endpoint { + remote-endpoint = <&mipi_csi_out>; + }; + }; + }; + }; + + - | + #include <dt-bindings/clock/imx8mp-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + isi@32e00000 { + compatible = "fsl,imx8mp-isi"; + reg = <0x32e00000 0x4000>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>, + <&clk IMX8MP_CLK_MEDIA_APB_ROOT>; + clock-names = "axi", "apb"; + fsl,blk-ctrl = <&media_blk_ctrl>; + power-domains = <&mediamix_pd>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + isi_in_0: endpoint { + remote-endpoint = <&mipi_csi_0_out>; + }; + }; + + port@1 { + reg = <1>; + isi_in_1: endpoint { + remote-endpoint = <&mipi_csi_1_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml index 7dc13a4b1805..3d58f02b0c5d 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Hantro G1/G2 VPU codecs implemented on i.MX8M SoCs diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml index 12ec3e1ea869..eb1499912c58 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,msm8916-camss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,msm8916-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm CAMSS ISP diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml index 2abb7d21c0d1..2350bf4b370e 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,msm8916-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,msm8916-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm MSM8916 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,msm8916-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: maxItems: 1 @@ -39,9 +35,6 @@ properties: iommus: maxItems: 1 - memory-region: - maxItems: 1 - video-decoder: type: object @@ -66,57 +59,36 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - - clocks - - clock-names - iommus - - memory-region - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,gcc-msm8916.h> - - video-codec@1d00000 { - compatible = "qcom,msm8916-venus"; - reg = <0x01d00000 0xff000>; - interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>, - <&gcc GCC_VENUS0_AHB_CLK>, - <&gcc GCC_VENUS0_AXI_CLK>; - clock-names = "core", "iface", "bus"; - power-domains = <&gcc VENUS_GDSC>; - iommus = <&apps_iommu 5>; - memory-region = <&venus_mem>; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,gcc-msm8916.h> + + video-codec@1d00000 { + compatible = "qcom,msm8916-venus"; + reg = <0x01d00000 0xff000>; + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>, + <&gcc GCC_VENUS0_AHB_CLK>, + <&gcc GCC_VENUS0_AXI_CLK>; + clock-names = "core", "iface", "bus"; + power-domains = <&gcc VENUS_GDSC>; + iommus = <&apps_iommu 5>; + memory-region = <&venus_mem>; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml index 6aeb3d6d02d5..8a10aa1cafc5 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,msm8996-camss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,msm8996-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm CAMSS ISP diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml index 29d0cb6c6ebe..3a4d817e544e 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,msm8996-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,msm8996-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm MSM8996 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,msm8996-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: maxItems: 1 @@ -37,12 +33,17 @@ properties: - const: bus - const: mbus + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: video-mem + - const: cpu-cfg + iommus: maxItems: 20 - memory-region: - maxItems: 1 - video-decoder: type: object @@ -93,83 +94,62 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - - clocks - - clock-names - iommus - - memory-region - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,mmcc-msm8996.h> - - video-codec@c00000 { - compatible = "qcom,msm8996-venus"; - reg = <0x00c00000 0xff000>; - interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mmcc VIDEO_CORE_CLK>, - <&mmcc VIDEO_AHB_CLK>, - <&mmcc VIDEO_AXI_CLK>, - <&mmcc VIDEO_MAXI_CLK>; - clock-names = "core", "iface", "bus", "mbus"; - power-domains = <&mmcc VENUS_GDSC>; - iommus = <&venus_smmu 0x00>, - <&venus_smmu 0x01>, - <&venus_smmu 0x0a>, - <&venus_smmu 0x07>, - <&venus_smmu 0x0e>, - <&venus_smmu 0x0f>, - <&venus_smmu 0x08>, - <&venus_smmu 0x09>, - <&venus_smmu 0x0b>, - <&venus_smmu 0x0c>, - <&venus_smmu 0x0d>, - <&venus_smmu 0x10>, - <&venus_smmu 0x11>, - <&venus_smmu 0x21>, - <&venus_smmu 0x28>, - <&venus_smmu 0x29>, - <&venus_smmu 0x2b>, - <&venus_smmu 0x2c>, - <&venus_smmu 0x2d>, - <&venus_smmu 0x31>; - memory-region = <&venus_mem>; - - video-decoder { - compatible = "venus-decoder"; - clocks = <&mmcc VIDEO_SUBCORE0_CLK>; - clock-names = "core"; - power-domains = <&mmcc VENUS_CORE0_GDSC>; - }; - - video-encoder { - compatible = "venus-encoder"; - clocks = <&mmcc VIDEO_SUBCORE1_CLK>; - clock-names = "core"; - power-domains = <&mmcc VENUS_CORE1_GDSC>; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,mmcc-msm8996.h> + + video-codec@c00000 { + compatible = "qcom,msm8996-venus"; + reg = <0x00c00000 0xff000>; + interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mmcc VIDEO_CORE_CLK>, + <&mmcc VIDEO_AHB_CLK>, + <&mmcc VIDEO_AXI_CLK>, + <&mmcc VIDEO_MAXI_CLK>; + clock-names = "core", "iface", "bus", "mbus"; + power-domains = <&mmcc VENUS_GDSC>; + iommus = <&venus_smmu 0x00>, + <&venus_smmu 0x01>, + <&venus_smmu 0x0a>, + <&venus_smmu 0x07>, + <&venus_smmu 0x0e>, + <&venus_smmu 0x0f>, + <&venus_smmu 0x08>, + <&venus_smmu 0x09>, + <&venus_smmu 0x0b>, + <&venus_smmu 0x0c>, + <&venus_smmu 0x0d>, + <&venus_smmu 0x10>, + <&venus_smmu 0x11>, + <&venus_smmu 0x21>, + <&venus_smmu 0x28>, + <&venus_smmu 0x29>, + <&venus_smmu 0x2b>, + <&venus_smmu 0x2c>, + <&venus_smmu 0x2d>, + <&venus_smmu 0x31>; + memory-region = <&venus_mem>; + + video-decoder { + compatible = "venus-decoder"; + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; + clock-names = "core"; + power-domains = <&mmcc VENUS_CORE0_GDSC>; + }; + + video-encoder { + compatible = "venus-encoder"; + clocks = <&mmcc VIDEO_SUBCORE1_CLK>; + clock-names = "core"; + power-domains = <&mmcc VENUS_CORE1_GDSC>; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml index 42ee3f06c6be..5cec1d077cda 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sc7180-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sc7180-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SC7180 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sc7180-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: minItems: 2 maxItems: 3 @@ -60,6 +56,10 @@ properties: - const: video-mem - const: cpu-cfg + operating-points-v2: true + opp-table: + type: object + video-decoder: type: object @@ -84,63 +84,42 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - power-domain-names - - clocks - - clock-names - iommus - - memory-region - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,videocc-sc7180.h> - - venus: video-codec@aa00000 { - compatible = "qcom,sc7180-venus"; - reg = <0x0aa00000 0xff000>; - interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; - power-domains = <&videocc VENUS_GDSC>, - <&videocc VCODEC0_GDSC>; - power-domain-names = "venus", "vcodec0"; - clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, - <&videocc VIDEO_CC_VENUS_AHB_CLK>, - <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>, - <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, - <&videocc VIDEO_CC_VCODEC0_AXI_CLK>; - clock-names = "core", "iface", "bus", - "vcodec0_core", "vcodec0_bus"; - iommus = <&apps_smmu 0x0c00 0x60>; - memory-region = <&venus_mem>; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sc7180.h> + + venus: video-codec@aa00000 { + compatible = "qcom,sc7180-venus"; + reg = <0x0aa00000 0xff000>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&videocc VENUS_GDSC>, + <&videocc VCODEC0_GDSC>; + power-domain-names = "venus", "vcodec0"; + clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, + <&videocc VIDEO_CC_VENUS_AHB_CLK>, + <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>, + <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, + <&videocc VIDEO_CC_VCODEC0_AXI_CLK>; + clock-names = "core", "iface", "bus", + "vcodec0_core", "vcodec0_bus"; + iommus = <&apps_smmu 0x0c00 0x60>; + memory-region = <&venus_mem>; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml index cf361dd9de08..8f9b6433aeb8 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sc7280-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sc7280-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SC7280 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus Iris2 IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sc7280-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: minItems: 2 maxItems: 3 @@ -49,9 +45,6 @@ properties: iommus: maxItems: 2 - memory-region: - maxItems: 1 - interconnects: maxItems: 2 @@ -60,6 +53,10 @@ properties: - const: cpu-cfg - const: video-mem + operating-points-v2: true + opp-table: + type: object + video-decoder: type: object @@ -84,79 +81,58 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - power-domain-names - - clocks - - clock-names - iommus - - memory-region - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,videocc-sc7280.h> - #include <dt-bindings/interconnect/qcom,sc7280.h> - #include <dt-bindings/power/qcom-rpmpd.h> - - venus: video-codec@aa00000 { - compatible = "qcom,sc7280-venus"; - reg = <0x0aa00000 0xd0600>; - interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; - - clocks = <&videocc VIDEO_CC_MVSC_CORE_CLK>, - <&videocc VIDEO_CC_MVSC_CTL_AXI_CLK>, - <&videocc VIDEO_CC_VENUS_AHB_CLK>, - <&videocc VIDEO_CC_MVS0_CORE_CLK>, - <&videocc VIDEO_CC_MVS0_AXI_CLK>; - clock-names = "core", "bus", "iface", - "vcodec_core", "vcodec_bus"; - - power-domains = <&videocc MVSC_GDSC>, - <&videocc MVS0_GDSC>, - <&rpmhpd SC7280_CX>; - power-domain-names = "venus", "vcodec0", "cx"; - - interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>, - <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>; - interconnect-names = "cpu-cfg", "video-mem"; - - iommus = <&apps_smmu 0x2180 0x20>, - <&apps_smmu 0x2184 0x20>; - - memory-region = <&video_mem>; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; - - video-firmware { - iommus = <&apps_smmu 0x21a2 0x0>; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sc7280.h> + #include <dt-bindings/interconnect/qcom,sc7280.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + venus: video-codec@aa00000 { + compatible = "qcom,sc7280-venus"; + reg = <0x0aa00000 0xd0600>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&videocc VIDEO_CC_MVSC_CORE_CLK>, + <&videocc VIDEO_CC_MVSC_CTL_AXI_CLK>, + <&videocc VIDEO_CC_VENUS_AHB_CLK>, + <&videocc VIDEO_CC_MVS0_CORE_CLK>, + <&videocc VIDEO_CC_MVS0_AXI_CLK>; + clock-names = "core", "bus", "iface", + "vcodec_core", "vcodec_bus"; + + power-domains = <&videocc MVSC_GDSC>, + <&videocc MVS0_GDSC>, + <&rpmhpd SC7280_CX>; + power-domain-names = "venus", "vcodec0", "cx"; + + interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>, + <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>; + interconnect-names = "cpu-cfg", "video-mem"; + + iommus = <&apps_smmu 0x2180 0x20>, + <&apps_smmu 0x2184 0x20>; + + memory-region = <&video_mem>; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; + }; + + video-firmware { + iommus = <&apps_smmu 0x21a2 0x0>; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml index b28c8e17f158..0a109e126064 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sdm660-camss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sdm660-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm CAMSS ISP diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml index 45e3f58f52bd..a51835b22045 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sdm660-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sdm660-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SDM660 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -15,13 +14,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sdm660-venus - reg: - maxItems: 1 - clocks: maxItems: 4 @@ -40,15 +39,9 @@ properties: - const: cpu-cfg - const: video-mem - interrupts: - maxItems: 1 - iommus: maxItems: 20 - memory-region: - maxItems: 1 - power-domains: maxItems: 1 @@ -102,86 +95,65 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - clocks - - clock-names - - interrupts - iommus - - memory-region - - power-domains - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/qcom,mmcc-sdm660.h> - #include <dt-bindings/interrupt-controller/arm-gic.h> - - video-codec@cc00000 { - compatible = "qcom,sdm660-venus"; - reg = <0x0cc00000 0xff000>; - clocks = <&mmcc VIDEO_CORE_CLK>, - <&mmcc VIDEO_AHB_CLK>, - <&mmcc VIDEO_AXI_CLK>, - <&mmcc THROTTLE_VIDEO_AXI_CLK>; - clock-names = "core", "iface", "bus", "bus_throttle"; - interconnects = <&gnoc 0 &mnoc 13>, - <&mnoc 4 &bimc 5>; - interconnect-names = "cpu-cfg", "video-mem"; - interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; - iommus = <&mmss_smmu 0x400>, - <&mmss_smmu 0x401>, - <&mmss_smmu 0x40a>, - <&mmss_smmu 0x407>, - <&mmss_smmu 0x40e>, - <&mmss_smmu 0x40f>, - <&mmss_smmu 0x408>, - <&mmss_smmu 0x409>, - <&mmss_smmu 0x40b>, - <&mmss_smmu 0x40c>, - <&mmss_smmu 0x40d>, - <&mmss_smmu 0x410>, - <&mmss_smmu 0x421>, - <&mmss_smmu 0x428>, - <&mmss_smmu 0x429>, - <&mmss_smmu 0x42b>, - <&mmss_smmu 0x42c>, - <&mmss_smmu 0x42d>, - <&mmss_smmu 0x411>, - <&mmss_smmu 0x431>; - memory-region = <&venus_region>; - power-domains = <&mmcc VENUS_GDSC>; - - video-decoder { - compatible = "venus-decoder"; - clocks = <&mmcc VIDEO_SUBCORE0_CLK>; - clock-names = "vcodec0_core"; - power-domains = <&mmcc VENUS_CORE0_GDSC>; - }; - - video-encoder { - compatible = "venus-encoder"; - clocks = <&mmcc VIDEO_SUBCORE0_CLK>; - clock-names = "vcodec0_core"; - power-domains = <&mmcc VENUS_CORE0_GDSC>; - }; + #include <dt-bindings/clock/qcom,mmcc-sdm660.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + video-codec@cc00000 { + compatible = "qcom,sdm660-venus"; + reg = <0x0cc00000 0xff000>; + clocks = <&mmcc VIDEO_CORE_CLK>, + <&mmcc VIDEO_AHB_CLK>, + <&mmcc VIDEO_AXI_CLK>, + <&mmcc THROTTLE_VIDEO_AXI_CLK>; + clock-names = "core", "iface", "bus", "bus_throttle"; + interconnects = <&gnoc 0 &mnoc 13>, + <&mnoc 4 &bimc 5>; + interconnect-names = "cpu-cfg", "video-mem"; + interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; + iommus = <&mmss_smmu 0x400>, + <&mmss_smmu 0x401>, + <&mmss_smmu 0x40a>, + <&mmss_smmu 0x407>, + <&mmss_smmu 0x40e>, + <&mmss_smmu 0x40f>, + <&mmss_smmu 0x408>, + <&mmss_smmu 0x409>, + <&mmss_smmu 0x40b>, + <&mmss_smmu 0x40c>, + <&mmss_smmu 0x40d>, + <&mmss_smmu 0x410>, + <&mmss_smmu 0x421>, + <&mmss_smmu 0x428>, + <&mmss_smmu 0x429>, + <&mmss_smmu 0x42b>, + <&mmss_smmu 0x42c>, + <&mmss_smmu 0x42d>, + <&mmss_smmu 0x411>, + <&mmss_smmu 0x431>; + memory-region = <&venus_region>; + power-domains = <&mmcc VENUS_GDSC>; + + video-decoder { + compatible = "venus-decoder"; + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; + clock-names = "vcodec0_core"; + power-domains = <&mmcc VENUS_CORE0_GDSC>; + }; + + video-encoder { + compatible = "venus-encoder"; + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; + clock-names = "vcodec0_core"; + power-domains = <&mmcc VENUS_CORE0_GDSC>; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml index f9a003882f84..1530ad0d80bd 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sdm845-camss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sdm845-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm CAMSS ISP diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml index 8edc8a2f43a5..d5f80976f4cf 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sdm845-venus-v2.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sdm845-venus-v2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SDM845 Venus v2 video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sdm845-venus-v2 - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: minItems: 3 maxItems: 4 @@ -52,8 +48,9 @@ properties: iommus: maxItems: 2 - memory-region: - maxItems: 1 + operating-points-v2: true + opp-table: + type: object video-core0: type: object @@ -79,68 +76,47 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - power-domain-names - - clocks - - clock-names - iommus - - memory-region - video-core0 - video-core1 -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,videocc-sdm845.h> - - video-codec@aa00000 { - compatible = "qcom,sdm845-venus-v2"; - reg = <0x0aa00000 0xff000>; - interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, - <&videocc VIDEO_CC_VENUS_AHB_CLK>, - <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>, - <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, - <&videocc VIDEO_CC_VCODEC0_AXI_CLK>, - <&videocc VIDEO_CC_VCODEC1_CORE_CLK>, - <&videocc VIDEO_CC_VCODEC1_AXI_CLK>; - clock-names = "core", "iface", "bus", - "vcodec0_core", "vcodec0_bus", - "vcodec1_core", "vcodec1_bus"; - power-domains = <&videocc VENUS_GDSC>, - <&videocc VCODEC0_GDSC>, - <&videocc VCODEC1_GDSC>; - power-domain-names = "venus", "vcodec0", "vcodec1"; - iommus = <&apps_smmu 0x10a0 0x8>, - <&apps_smmu 0x10b0 0x0>; - memory-region = <&venus_mem>; - - video-core0 { - compatible = "venus-decoder"; - }; - - video-core1 { - compatible = "venus-encoder"; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sdm845.h> + + video-codec@aa00000 { + compatible = "qcom,sdm845-venus-v2"; + reg = <0x0aa00000 0xff000>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, + <&videocc VIDEO_CC_VENUS_AHB_CLK>, + <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>, + <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, + <&videocc VIDEO_CC_VCODEC0_AXI_CLK>, + <&videocc VIDEO_CC_VCODEC1_CORE_CLK>, + <&videocc VIDEO_CC_VCODEC1_AXI_CLK>; + clock-names = "core", "iface", "bus", + "vcodec0_core", "vcodec0_bus", + "vcodec1_core", "vcodec1_bus"; + power-domains = <&videocc VENUS_GDSC>, + <&videocc VCODEC0_GDSC>, + <&videocc VCODEC1_GDSC>; + power-domain-names = "venus", "vcodec0", "vcodec1"; + iommus = <&apps_smmu 0x10a0 0x8>, + <&apps_smmu 0x10b0 0x0>; + memory-region = <&venus_mem>; + + video-core0 { + compatible = "venus-decoder"; + }; + + video-core1 { + compatible = "venus-encoder"; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml index 57d503373efe..eabc0957b241 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sdm845-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sdm845-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SDM845 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sdm845-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: maxItems: 1 @@ -39,9 +35,6 @@ properties: iommus: maxItems: 2 - memory-region: - maxItems: 1 - video-core0: type: object @@ -94,66 +87,45 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - - clocks - - clock-names - iommus - - memory-region - video-core0 - video-core1 -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,videocc-sdm845.h> - - video-codec@aa00000 { - compatible = "qcom,sdm845-venus"; - reg = <0x0aa00000 0xff000>; - interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, - <&videocc VIDEO_CC_VENUS_AHB_CLK>, - <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>; - clock-names = "core", "iface", "bus"; - power-domains = <&videocc VENUS_GDSC>; - iommus = <&apps_smmu 0x10a0 0x8>, - <&apps_smmu 0x10b0 0x0>; - memory-region = <&venus_mem>; - - video-core0 { - compatible = "venus-decoder"; - clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, - <&videocc VIDEO_CC_VCODEC0_AXI_CLK>; - clock-names = "core", "bus"; - power-domains = <&videocc VCODEC0_GDSC>; - }; - - video-core1 { - compatible = "venus-encoder"; - clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>, - <&videocc VIDEO_CC_VCODEC1_AXI_CLK>; - clock-names = "core", "bus"; - power-domains = <&videocc VCODEC1_GDSC>; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sdm845.h> + + video-codec@aa00000 { + compatible = "qcom,sdm845-venus"; + reg = <0x0aa00000 0xff000>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, + <&videocc VIDEO_CC_VENUS_AHB_CLK>, + <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>; + clock-names = "core", "iface", "bus"; + power-domains = <&videocc VENUS_GDSC>; + iommus = <&apps_smmu 0x10a0 0x8>, + <&apps_smmu 0x10b0 0x0>; + memory-region = <&venus_mem>; + + video-core0 { + compatible = "venus-decoder"; + clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, + <&videocc VIDEO_CC_VCODEC0_AXI_CLK>; + clock-names = "core", "bus"; + power-domains = <&videocc VCODEC0_GDSC>; + }; + + video-core1 { + compatible = "venus-encoder"; + clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>, + <&videocc VIDEO_CC_VCODEC1_AXI_CLK>; + clock-names = "core", "bus"; + power-domains = <&videocc VCODEC1_GDSC>; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml index 07a2af12f37d..fa5073c0fd1e 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sm8250-camss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sm8250-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm CAMSS ISP diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml index 4b7a12523dcf..7915dcd2d99f 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sm8250-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sm8250-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SM8250 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sm8250-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: minItems: 2 maxItems: 3 @@ -47,9 +43,6 @@ properties: iommus: maxItems: 1 - memory-region: - maxItems: 1 - interconnects: maxItems: 2 @@ -58,6 +51,10 @@ properties: - const: cpu-cfg - const: video-mem + operating-points-v2: true + opp-table: + type: object + resets: maxItems: 2 @@ -90,78 +87,57 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - power-domain-names - - clocks - - clock-names - interconnects - interconnect-names - iommus - - memory-region - resets - reset-names - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,videocc-sm8250.h> - #include <dt-bindings/interconnect/qcom,sm8250.h> - #include <dt-bindings/clock/qcom,gcc-sm8250.h> - #include <dt-bindings/power/qcom-rpmpd.h> - - venus: video-codec@aa00000 { - compatible = "qcom,sm8250-venus"; - reg = <0x0aa00000 0xff000>; - interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; - power-domains = <&videocc MVS0C_GDSC>, - <&videocc MVS0_GDSC>, - <&rpmhpd SM8250_MX>; - power-domain-names = "venus", "vcodec0", "mx"; - - 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_AMPSS_M0 &config_noc SLAVE_VENUS_CFG>, - <&mmss_noc MASTER_VIDEO_P0 &mc_virt SLAVE_EBI_CH0>; - interconnect-names = "cpu-cfg", "video-mem"; - - iommus = <&apps_smmu 0x2100 0x0400>; - memory-region = <&video_mem>; - - resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>, - <&videocc VIDEO_CC_MVS0C_CLK_ARES>; - reset-names = "bus", "core"; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sm8250.h> + #include <dt-bindings/interconnect/qcom,sm8250.h> + #include <dt-bindings/clock/qcom,gcc-sm8250.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + venus: video-codec@aa00000 { + compatible = "qcom,sm8250-venus"; + reg = <0x0aa00000 0xff000>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&videocc MVS0C_GDSC>, + <&videocc MVS0_GDSC>, + <&rpmhpd SM8250_MX>; + power-domain-names = "venus", "vcodec0", "mx"; + + 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_AMPSS_M0 &config_noc SLAVE_VENUS_CFG>, + <&mmss_noc MASTER_VIDEO_P0 &mc_virt SLAVE_EBI_CH0>; + interconnect-names = "cpu-cfg", "video-mem"; + + iommus = <&apps_smmu 0x2100 0x0400>; + memory-region = <&video_mem>; + + resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>, + <&videocc VIDEO_CC_MVS0C_CLK_ARES>; + reset-names = "bus", "core"; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml new file mode 100644 index 000000000000..3153d91f9d18 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,venus-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SoC Venus Video Encode and Decode Accelerators Common Properties + +maintainers: + - Stanimir Varbanov <stanimir.k.varbanov@gmail.com> + - Vikash Garodia <quic_vgarodia@quicinc.com> + +description: | + The Venus IP is a video encode and decode accelerator present + on Qualcomm platforms + +properties: + reg: + maxItems: 1 + + clocks: + minItems: 3 + maxItems: 7 + + clock-names: + minItems: 3 + maxItems: 7 + + firmware-name: + maxItems: 1 + + interrupts: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 20 + + memory-region: + maxItems: 1 + + power-domains: + minItems: 1 + maxItems: 4 + + power-domain-names: + minItems: 1 + maxItems: 4 + + video-firmware: + type: object + additionalProperties: false + + description: | + Firmware subnode is needed when the platform does not + have TrustZone. + + properties: + iommus: + maxItems: 1 + + required: + - iommus + +required: + - reg + - clocks + - clock-names + - interrupts + - memory-region + - power-domains + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml index e732b7f3a635..7bbe580c80f7 100644 --- a/Documentation/devicetree/bindings/media/rc.yaml +++ b/Documentation/devicetree/bindings/media/rc.yaml @@ -18,7 +18,7 @@ properties: description: Specifies the scancode/key mapping table defined in-kernel for the remote controller. - $ref: '/schemas/types.yaml#/definitions/string' + $ref: /schemas/types.yaml#/definitions/string enum: - rc-adstech-dvb-t-pci - rc-alink-dtu-m @@ -39,6 +39,7 @@ properties: - rc-avertv-303 - rc-azurewave-ad-tu700 - rc-beelink-gs1 + - rc-beelink-mxiii - rc-behold - rc-behold-columbus - rc-budget-ci-old @@ -55,6 +56,7 @@ properties: - rc-dm1105-nec - rc-dntv-live-dvb-t - rc-dntv-live-dvbt-pro + - rc-dreambox - rc-dtt200u - rc-dvbsky - rc-dvico-mce diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml index b520d6c5c102..977ab188d654 100644 --- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml +++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml @@ -31,6 +31,7 @@ properties: - renesas,r8a77980-csi2 # R-Car V3H - renesas,r8a77990-csi2 # R-Car E3 - renesas,r8a779a0-csi2 # R-Car V3U + - renesas,r8a779g0-csi2 # R-Car V4H reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml b/Documentation/devicetree/bindings/media/renesas,fcp.yaml index 43f2fed8cd33..c6abe719881b 100644 --- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml +++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml @@ -21,15 +21,22 @@ description: | properties: compatible: - enum: - - renesas,fcpv # FCP for VSP - - renesas,fcpf # FCP for FDP + oneOf: + - enum: + - renesas,fcpv # FCP for VSP + - renesas,fcpf # FCP for FDP + - items: + - enum: + - renesas,r9a07g044-fcpvd # RZ/G2{L,LC} + - renesas,r9a07g054-fcpvd # RZ/V2L + - const: renesas,fcpv # Generic FCP for VSP fallback reg: maxItems: 1 - clocks: - maxItems: 1 + clocks: true + + clock-names: true iommus: maxItems: 1 @@ -49,6 +56,34 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - renesas,r9a07g044-fcpvd + - renesas,r9a07g054-fcpvd + then: + properties: + clocks: + items: + - description: Main clock + - description: Register access clock + - description: Video clock + clock-names: + items: + - const: aclk + - const: pclk + - const: vclk + required: + - clock-names + else: + properties: + clocks: + maxItems: 1 + clock-names: false + examples: # R8A7795 (R-Car H3) FCP for VSP-D1 - | diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml index 514857d36f6b..33650a1ea034 100644 --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml @@ -21,6 +21,7 @@ properties: items: - enum: - renesas,r8a779a0-isp # V3U + - renesas,r8a779g0-isp # V4H reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml index c0442e79cbb4..91e8f368fb52 100644 --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml @@ -53,6 +53,7 @@ properties: - renesas,vin-r8a77990 # R-Car E3 - renesas,vin-r8a77995 # R-Car D3 - renesas,vin-r8a779a0 # R-Car V3U + - renesas,vin-r8a779g0 # R-Car V4H reg: maxItems: 1 @@ -69,7 +70,7 @@ properties: resets: maxItems: 1 - #The per-board settings for Gen2 and RZ/G1 platforms: + # The per-board settings for Gen2 and RZ/G1 platforms: port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false @@ -108,7 +109,7 @@ properties: data-active: true - #The per-board settings for Gen3 and RZ/G2 platforms: + # The per-board settings for Gen3 and RZ/G2 platforms: renesas,id: description: VIN channel number $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml index 7a8f32473852..3265e922647c 100644 --- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml @@ -16,10 +16,15 @@ description: properties: compatible: - enum: - - renesas,r9a07g044-vsp2 # RZ/G2L - - renesas,vsp1 # R-Car Gen2 and RZ/G1 - - renesas,vsp2 # R-Car Gen3 and RZ/G2 + oneOf: + - enum: + - renesas,r9a07g044-vsp2 # RZ/G2L + - renesas,vsp1 # R-Car Gen2 and RZ/G1 + - renesas,vsp2 # R-Car Gen3 and RZ/G2 + - items: + - enum: + - renesas,r9a07g054-vsp2 # RZ/V2L + - const: renesas,r9a07g044-vsp2 # RZ/G2L fallback reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml index 81b26eb4cd35..9d90d8d0565a 100644 --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/rockchip,rk3568-vepu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/rockchip,rk3568-vepu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Hantro G1 VPU encoders implemented on Rockchip SoCs diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml index b3661d7d4357..0bad7e640148 100644 --- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml @@ -212,12 +212,19 @@ examples: compatible = "ovti,ov2685"; reg = <0x3c>; - port { - ucam_out: endpoint { - remote-endpoint = <&mipi_in_ucam>; - data-lanes = <1>; - }; - }; + clocks = <&cru SCLK_TESTCLKOUT1>; + clock-names = "xvclk"; + + avdd-supply = <&pp2800_cam>; + dovdd-supply = <&pp1800>; + dvdd-supply = <&pp1800>; + + port { + ucam_out: endpoint { + remote-endpoint = <&mipi_in_ucam>; + data-lanes = <1>; + }; + }; }; }; }; diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index 6cc4d3e5a61d..ee622a8ee1cc 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/rockchip-vpu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/rockchip-vpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Hantro G1 VPU codecs implemented on Rockchip SoCs diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4210-csis.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4210-csis.yaml new file mode 100644 index 000000000000..dd6cc7ac1f7c --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,exynos4210-csis.yaml @@ -0,0 +1,170 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,exynos4210-csis.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5P/Exynos SoC series MIPI CSI-2 receiver (MIPI CSIS) + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +properties: + compatible: + enum: + - samsung,s5pv210-csis + - samsung,exynos4210-csis + - samsung,exynos4212-csis + - samsung,exynos5250-csis + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + bus-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [2, 4] + description: + Number of data lines supported. + + clocks: + maxItems: 2 + + clock-names: + items: + - const: csis + - const: sclk_csis + + clock-frequency: + default: 166000000 + description: + The IP's main (system bus) clock frequency in Hz. + + interrupts: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + items: + - const: csis + + power-domains: + maxItems: 1 + + vddio-supply: + description: MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V). + + vddcore-supply: + description: MIPI CSIS Core voltage supply (e.g. 1.1V). + +patternProperties: + "^port@[34]$": + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + description: + Camera input port. + + properties: + reg: + enum: [3, 4] + + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + samsung,csis-hs-settle: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Differential receiver (HS-RX) settle time. + + samsung,csis-wclk: + type: boolean + description: + CSI-2 wrapper clock selection. If this property is present external clock + from CMU will be used, or the bus clock if it's not specified. + + required: + - data-lanes + + required: + - reg + +required: + - compatible + - reg + - bus-width + - clocks + - clock-names + - interrupts + - vddio-supply + - vddcore-supply + +anyOf: + - required: + - port@3 + - required: + - port@4 + +allOf: + - if: + required: + - samsung,isp-wb + then: + required: + - samsung,sysreg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + csis@11890000 { + compatible = "samsung,exynos4210-csis"; + reg = <0x11890000 0x4000>; + clocks = <&clock CLK_CSIS1>, + <&clock CLK_SCLK_CSIS1>; + clock-names = "csis", "sclk_csis"; + assigned-clocks = <&clock CLK_MOUT_CSIS1>, + <&clock CLK_SCLK_CSIS1>; + assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>; + assigned-clock-rates = <0>, <176000000>; + + interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>; + + bus-width = <2>; + power-domains = <&pd_cam>; + phys = <&mipi_phy 2>; + phy-names = "csis"; + + vddcore-supply = <&ldo8_reg>; + vddio-supply = <&ldo10_reg>; + + #address-cells = <1>; + #size-cells = <0>; + + /* Camera D (4) MIPI CSI-2 (CSIS1) */ + port@4 { + reg = <4>; + + endpoint { + remote-endpoint = <&is_s5k6a3_ep>; + data-lanes = <1>; + samsung,csis-hs-settle = <18>; + samsung,csis-wclk; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4210-fimc.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4210-fimc.yaml new file mode 100644 index 000000000000..271d0577a83c --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,exynos4210-fimc.yaml @@ -0,0 +1,152 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,exynos4210-fimc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5P/Exynos SoC Fully Integrated Mobile Camera + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: + Each FIMC device should have an alias in the aliases node, in the form of + fimc<n>, where <n> is an integer specifying the IP block instance. + +properties: + compatible: + enum: + - samsung,exynos4210-fimc + - samsung,exynos4212-fimc + - samsung,s5pv210-fimc + + reg: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: fimc + - const: sclk_fimc + + clock-frequency: + description: + Maximum FIMC local clock (LCLK) frequency. + + interrupts: + maxItems: 1 + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + + samsung,cam-if: + type: boolean + description: + The FIMC IP block includes the camera input interface. + + samsung,isp-wb: + type: boolean + description: | + The FIMC IP block has the ISP writeback input. + + samsung,lcd-wb: + type: boolean + description: | + The FIMC IP block has the LCD writeback input. + + samsung,mainscaler-ext: + type: boolean + description: + FIMC IP supports extended image size and has CIEXTEN register. + + samsung,min-pix-alignment: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: Minimum supported image height alignment. + - description: Horizontal image offset. + description: + The values are in pixels and default is <2 1>. + + samsung,min-pix-sizes: + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 2 + description: | + An array specyfing minimum image size in pixels at the FIMC input and + output DMA, in the first and second cell respectively. Default value + is <16 16>. + + samsung,pix-limits: + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 4 + description: | + An array of maximum supported image sizes in pixels, for details refer to + Table 2-1 in the S5PV210 SoC User Manual. The meaning of each cell is as + follows: + 0 - scaler input horizontal size + 1 - input horizontal size for the scaler bypassed + 2 - REAL_WIDTH without input rotation + 3 - REAL_HEIGHT with input rotation + + samsung,rotators: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0x11 + description: | + A bitmask specifying whether this IP has the input and the output + rotator. Bits 4 and 0 correspond to input and output rotator + respectively. If a rotator is present its corresponding bit should be + set. + + samsung,sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + System Registers (SYSREG) node. + +required: + - compatible + - reg + - clocks + - clock-names + - samsung,pix-limits + +allOf: + - if: + required: + - samsung,isp-wb + then: + required: + - samsung,sysreg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + fimc@11800000 { + compatible = "samsung,exynos4212-fimc"; + reg = <0x11800000 0x1000>; + clocks = <&clock CLK_FIMC0>, + <&clock CLK_SCLK_FIMC0>; + clock-names = "fimc", "sclk_fimc"; + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>; + iommus = <&sysmmu_fimc0>; + power-domains = <&pd_cam>; + samsung,sysreg = <&sys_reg>; + + samsung,pix-limits = <4224 8192 1920 4224>; + samsung,mainscaler-ext; + samsung,isp-wb; + samsung,cam-if; + + assigned-clocks = <&clock CLK_MOUT_FIMC0>, + <&clock CLK_SCLK_FIMC0>; + assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>; + assigned-clock-rates = <0>, <176000000>; + }; diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml new file mode 100644 index 000000000000..3691cd4962b2 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml @@ -0,0 +1,220 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,exynos4212-fimc-is.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos4212/4412 SoC Imaging Subsystem (FIMC-IS) + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: + The FIMC-IS is a subsystem for processing image signal from an image sensor. + The Exynos4x12 SoC series FIMC-IS V1.5 comprises of a dedicated ARM Cortex-A5 + processor, ISP, DRC and FD IP blocks and peripheral devices such as UART, I2C + and SPI bus controllers, PWM and ADC. + +properties: + compatible: + enum: + - samsung,exynos4212-fimc-is + + reg: + maxItems: 1 + + ranges: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + clocks: + maxItems: 21 + + clock-names: + items: + - const: lite0 + - const: lite1 + - const: ppmuispx + - const: ppmuispmx + - const: isp + - const: drc + - const: fd + - const: mcuisp + - const: gicisp + - const: mcuctl_isp + - const: pwm_isp + - const: ispdiv0 + - const: ispdiv1 + - const: mcuispdiv0 + - const: mcuispdiv1 + - const: mpll + - const: aclk200 + - const: aclk400mcuisp + - const: div_aclk200 + - const: div_aclk400mcuisp + - const: uart + + interrupts: + maxItems: 2 + + iommus: + maxItems: 4 + + iommu-names: + items: + - const: isp + - const: drc + - const: fd + - const: mcuctl + + power-domains: + maxItems: 1 + +patternProperties: + "^pmu@[0-9a-f]+$": + type: object + additionalProperties: false + description: + Node representing the SoC's Power Management Unit (duplicated with the + correct PMU node in the SoC). + + properties: + reg: + maxItems: 1 + + required: + - reg + + "^i2c-isp@[0-9a-f]+$": + type: object + $ref: /schemas/i2c/i2c-controller.yaml# + unevaluatedProperties: false + description: + ISP I2C bus controller + + properties: + compatible: + const: samsung,exynos4212-i2c-isp + + reg: + maxItems: 1 + + + clocks: + maxItems: 1 + + clock-names: + items: + - const: i2c_isp + + pinctrl-0: true + pinctrl-names: + items: + - const: default + + required: + - compatible + - reg + - clocks + - clock-names + +required: + - compatible + - reg + - '#address-cells' + - clocks + - clock-names + - interrupts + - ranges + - '#size-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + fimc-is@12000000 { + compatible = "samsung,exynos4212-fimc-is"; + reg = <0x12000000 0x260000>; + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&isp_clock CLK_ISP_FIMC_LITE0>, + <&isp_clock CLK_ISP_FIMC_LITE1>, + <&isp_clock CLK_ISP_PPMUISPX>, + <&isp_clock CLK_ISP_PPMUISPMX>, + <&isp_clock CLK_ISP_FIMC_ISP>, + <&isp_clock CLK_ISP_FIMC_DRC>, + <&isp_clock CLK_ISP_FIMC_FD>, + <&isp_clock CLK_ISP_MCUISP>, + <&isp_clock CLK_ISP_GICISP>, + <&isp_clock CLK_ISP_MCUCTL_ISP>, + <&isp_clock CLK_ISP_PWM_ISP>, + <&isp_clock CLK_ISP_DIV_ISP0>, + <&isp_clock CLK_ISP_DIV_ISP1>, + <&isp_clock CLK_ISP_DIV_MCUISP0>, + <&isp_clock CLK_ISP_DIV_MCUISP1>, + <&clock CLK_MOUT_MPLL_USER_T>, + <&clock CLK_ACLK200>, + <&clock CLK_ACLK400_MCUISP>, + <&clock CLK_DIV_ACLK200>, + <&clock CLK_DIV_ACLK400_MCUISP>, + <&clock CLK_UART_ISP_SCLK>; + clock-names = "lite0", "lite1", "ppmuispx", + "ppmuispmx", "isp", + "drc", "fd", "mcuisp", + "gicisp", "mcuctl_isp", "pwm_isp", + "ispdiv0", "ispdiv1", "mcuispdiv0", + "mcuispdiv1", "mpll", "aclk200", + "aclk400mcuisp", "div_aclk200", + "div_aclk400mcuisp", "uart"; + iommus = <&sysmmu_fimc_isp>, <&sysmmu_fimc_drc>, + <&sysmmu_fimc_fd>, <&sysmmu_fimc_mcuctl>; + iommu-names = "isp", "drc", "fd", "mcuctl"; + power-domains = <&pd_isp>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + pmu@10020000 { + reg = <0x10020000 0x3000>; + }; + + i2c-isp@12140000 { + compatible = "samsung,exynos4212-i2c-isp"; + reg = <0x12140000 0x100>; + clocks = <&isp_clock CLK_ISP_I2C1_ISP>; + clock-names = "i2c_isp"; + pinctrl-0 = <&fimc_is_i2c1>; + pinctrl-names = "default"; + #address-cells = <1>; + #size-cells = <0>; + + image-sensor@10 { + compatible = "samsung,s5k6a3"; + reg = <0x10>; + svdda-supply = <&cam_io_reg>; + svddio-supply = <&ldo19_reg>; + afvdd-supply = <&ldo19_reg>; + clock-frequency = <24000000>; + clocks = <&camera 1>; + clock-names = "extclk"; + gpios = <&gpm1 6 GPIO_ACTIVE_LOW>; + + port { + endpoint { + remote-endpoint = <&csis1_ep>; + data-lanes = <1>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-lite.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-lite.yaml new file mode 100644 index 000000000000..f80eca0a4f41 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-lite.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,exynos4212-fimc-lite.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC series camera host interface (FIMC-LITE) + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: + Each FIMC device should have an alias in the aliases node, in the form of + fimc-lite<n>, where <n> is an integer specifying the IP block instance. + +properties: + compatible: + enum: + - samsung,exynos4212-fimc-lite + - samsung,exynos5250-fimc-lite + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: flite + + interrupts: + maxItems: 1 + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + fimc-lite@12390000 { + compatible = "samsung,exynos4212-fimc-lite"; + reg = <0x12390000 0x1000>; + clocks = <&isp_clock CLK_ISP_FIMC_LITE0>; + clock-names = "flite"; + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&pd_isp>; + iommus = <&sysmmu_fimc_lite0>; + }; diff --git a/Documentation/devicetree/bindings/media/samsung,fimc.yaml b/Documentation/devicetree/bindings/media/samsung,fimc.yaml new file mode 100644 index 000000000000..79ff6d83a9fd --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,fimc.yaml @@ -0,0 +1,279 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,fimc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5P/Exynos SoC Camera Subsystem (FIMC) + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: | + The S5P/Exynos SoC Camera subsystem comprises of multiple sub-devices + represented by separate device tree nodes. Currently this includes: Fully + Integrated Mobile Camera (FIMC, in the S5P SoCs series known as CAMIF), MIPI + CSIS, FIMC-LITE and FIMC-IS (ISP). + +properties: + compatible: + const: samsung,fimc + + ranges: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + '#clock-cells': + const: 1 + description: | + The clock specifier cell stores an index of a clock: 0, 1 for + CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively. + + clocks: + minItems: 2 + maxItems: 4 + + clock-names: + minItems: 2 + items: + - const: sclk_cam0 + - const: sclk_cam1 + - const: pxl_async0 + - const: pxl_async1 + + clock-output-names: + maxItems: 2 + + parallel-ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + Active parallel video input ports. + + patternProperties: + "^port@[01]$": + $ref: /schemas/graph.yaml#/$defs/port-base + description: + Camera A and camera B inputs. + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + pinctrl-names: + minItems: 1 + items: + - const: default + - const: idle + - const: active_a + - const: active_b + +patternProperties: + "^csis@[0-9a-f]+$": + type: object + $ref: samsung,exynos4210-csis.yaml# + description: MIPI CSI-2 receiver. + + "^fimc@[0-9a-f]+$": + type: object + $ref: samsung,exynos4210-fimc.yaml# + description: Fully Integrated Mobile Camera. + + "^fimc-is@[0-9a-f]+$": + type: object + $ref: samsung,exynos4212-fimc-is.yaml# + description: Imaging Subsystem (FIMC-IS). + + "^fimc-lite@[0-9a-f]+$": + type: object + $ref: samsung,exynos4212-fimc-lite.yaml# + description: Camera host interface (FIMC-LITE). + +required: + - compatible + - '#address-cells' + - '#clock-cells' + - clocks + - clock-names + - clock-output-names + - ranges + - '#size-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + camera@11800000 { + compatible = "samsung,fimc"; + #clock-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x0 0x18000000>; + + clocks = <&clock CLK_SCLK_CAM0>, <&clock CLK_SCLK_CAM1>, + <&clock CLK_PIXELASYNCM0>, <&clock CLK_PIXELASYNCM1>; + clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", "pxl_async1"; + clock-output-names = "cam_a_clkout", "cam_b_clkout"; + + assigned-clocks = <&clock CLK_MOUT_CAM0>, + <&clock CLK_MOUT_CAM1>; + assigned-clock-parents = <&clock CLK_XUSBXTI>, + <&clock CLK_XUSBXTI>; + + pinctrl-0 = <&cam_port_a_clk_active &cam_port_b_clk_active>; + pinctrl-names = "default"; + + fimc@11800000 { + compatible = "samsung,exynos4212-fimc"; + reg = <0x11800000 0x1000>; + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock CLK_FIMC0>, + <&clock CLK_SCLK_FIMC0>; + clock-names = "fimc", "sclk_fimc"; + power-domains = <&pd_cam>; + samsung,sysreg = <&sys_reg>; + iommus = <&sysmmu_fimc0>; + + samsung,pix-limits = <4224 8192 1920 4224>; + samsung,mainscaler-ext; + samsung,isp-wb; + samsung,cam-if; + }; + + /* ... FIMC 1-3 */ + + csis@11880000 { + compatible = "samsung,exynos4210-csis"; + reg = <0x11880000 0x4000>; + interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock CLK_CSIS0>, + <&clock CLK_SCLK_CSIS0>; + clock-names = "csis", "sclk_csis"; + assigned-clocks = <&clock CLK_MOUT_CSIS0>, + <&clock CLK_SCLK_CSIS0>; + assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>; + assigned-clock-rates = <0>, <176000000>; + + bus-width = <4>; + power-domains = <&pd_cam>; + phys = <&mipi_phy 0>; + phy-names = "csis"; + #address-cells = <1>; + #size-cells = <0>; + + vddcore-supply = <&ldo8_reg>; + vddio-supply = <&ldo10_reg>; + + /* Camera C (3) MIPI CSI-2 (CSIS0) */ + port@3 { + reg = <3>; + endpoint { + remote-endpoint = <&s5c73m3_ep>; + data-lanes = <1 2 3 4>; + samsung,csis-hs-settle = <12>; + }; + }; + }; + + /* ... CSIS 1 */ + + fimc-lite@12390000 { + compatible = "samsung,exynos4212-fimc-lite"; + reg = <0x12390000 0x1000>; + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&pd_isp>; + clocks = <&isp_clock CLK_ISP_FIMC_LITE0>; + clock-names = "flite"; + iommus = <&sysmmu_fimc_lite0>; + }; + + /* ... FIMC-LITE 1 */ + + fimc-is@12000000 { + compatible = "samsung,exynos4212-fimc-is"; + reg = <0x12000000 0x260000>; + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&isp_clock CLK_ISP_FIMC_LITE0>, + <&isp_clock CLK_ISP_FIMC_LITE1>, + <&isp_clock CLK_ISP_PPMUISPX>, + <&isp_clock CLK_ISP_PPMUISPMX>, + <&isp_clock CLK_ISP_FIMC_ISP>, + <&isp_clock CLK_ISP_FIMC_DRC>, + <&isp_clock CLK_ISP_FIMC_FD>, + <&isp_clock CLK_ISP_MCUISP>, + <&isp_clock CLK_ISP_GICISP>, + <&isp_clock CLK_ISP_MCUCTL_ISP>, + <&isp_clock CLK_ISP_PWM_ISP>, + <&isp_clock CLK_ISP_DIV_ISP0>, + <&isp_clock CLK_ISP_DIV_ISP1>, + <&isp_clock CLK_ISP_DIV_MCUISP0>, + <&isp_clock CLK_ISP_DIV_MCUISP1>, + <&clock CLK_MOUT_MPLL_USER_T>, + <&clock CLK_ACLK200>, + <&clock CLK_ACLK400_MCUISP>, + <&clock CLK_DIV_ACLK200>, + <&clock CLK_DIV_ACLK400_MCUISP>, + <&clock CLK_UART_ISP_SCLK>; + clock-names = "lite0", "lite1", "ppmuispx", + "ppmuispmx", "isp", + "drc", "fd", "mcuisp", + "gicisp", "mcuctl_isp", "pwm_isp", + "ispdiv0", "ispdiv1", "mcuispdiv0", + "mcuispdiv1", "mpll", "aclk200", + "aclk400mcuisp", "div_aclk200", + "div_aclk400mcuisp", "uart"; + iommus = <&sysmmu_fimc_isp>, <&sysmmu_fimc_drc>, + <&sysmmu_fimc_fd>, <&sysmmu_fimc_mcuctl>; + iommu-names = "isp", "drc", "fd", "mcuctl"; + power-domains = <&pd_isp>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + pmu@10020000 { + reg = <0x10020000 0x3000>; + }; + + i2c-isp@12140000 { + compatible = "samsung,exynos4212-i2c-isp"; + reg = <0x12140000 0x100>; + clocks = <&isp_clock CLK_ISP_I2C1_ISP>; + clock-names = "i2c_isp"; + pinctrl-0 = <&fimc_is_i2c1>; + pinctrl-names = "default"; + #address-cells = <1>; + #size-cells = <0>; + + image-sensor@10 { + compatible = "samsung,s5k6a3"; + reg = <0x10>; + svdda-supply = <&cam_io_reg>; + svddio-supply = <&ldo19_reg>; + afvdd-supply = <&ldo19_reg>; + clock-frequency = <24000000>; + /* CAM_B_CLKOUT */ + clocks = <&camera 1>; + clock-names = "extclk"; + gpios = <&gpm1 6 GPIO_ACTIVE_LOW>; + + port { + endpoint { + remote-endpoint = <&csis1_ep>; + data-lanes = <1>; + }; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/samsung,s5c73m3.yaml b/Documentation/devicetree/bindings/media/samsung,s5c73m3.yaml new file mode 100644 index 000000000000..1b75390fdaac --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,s5c73m3.yaml @@ -0,0 +1,165 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,s5c73m3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5C73M3 8Mp camera ISP + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: + The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) + video data busses. The I2C bus is the main control bus and additionally the + SPI bus is used, mostly for transferring the firmware to and from the + device. Two slave device nodes corresponding to these control bus + interfaces are required and should be placed under respective bus + controller nodes. + +properties: + compatible: + const: samsung,s5c73m3 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: cis_extclk + + clock-frequency: + default: 24000000 + description: cis_extclk clock frequency. + + standby-gpios: + maxItems: 1 + description: STANDBY pin. + + vdda-supply: + description: Analog power supply (1.2V). + + vdd-af-supply: + description: lens power supply (2.8V). + + vddio-cis-supply: + description: CIS I/O power supply (1.2V to 1.8V). + + vddio-host-supply: + description: Host I/O power supply (1.8V to 2.8V). + + vdd-int-supply: + description: Digital power supply (1.2V). + + vdd-reg-supply: + description: Regulator input power supply (2.8V). + + xshutdown-gpios: + maxItems: 1 + description: XSHUTDOWN pin. + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + +required: + - compatible + - reg + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + - if: + required: + - spi-max-frequency + then: + properties: + # The SPI node is simplified firmware-transfer interface only + clocks: false + clock-names: false + standby-gpios: false + vdda-supply: false + vdd-af-supply: false + vddio-cis-supply: false + vddio-host-supply: false + vdd-int-supply: false + vdd-reg-supply: false + xshutdown-gpios: false + port: false + else: + required: + - clocks + - clock-names + - standby-gpios + - vdda-supply + - vdd-af-supply + - vddio-cis-supply + - vddio-host-supply + - vdd-int-supply + - vdd-reg-supply + - xshutdown-gpios + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + image-sensor@3c { + compatible = "samsung,s5c73m3"; + reg = <0x3c>; + clock-frequency = <24000000>; + clocks = <&camera 0>; + clock-names = "cis_extclk"; + standby-gpios = <&gpm0 6 GPIO_ACTIVE_LOW>; + vdda-supply = <&cam_vdda_reg>; + vdd-af-supply = <&cam_af_reg>; + vddio-cis-supply = <&ldo9_reg>; + vddio-host-supply = <&ldo18_reg>; + vdd-int-supply = <&buck9_reg>; + vdd-reg-supply = <&cam_io_reg>; + xshutdown-gpios = <&gpf1 3 GPIO_ACTIVE_LOW>; /* ISP_RESET */ + + port { + s5c73m3_ep: endpoint { + remote-endpoint = <&csis0_ep>; + data-lanes = <1 2 3 4>; + }; + }; + }; + }; + + spi { + #address-cells = <1>; + #size-cells = <0>; + + image-sensor@0 { + compatible = "samsung,s5c73m3"; + reg = <0>; + spi-max-frequency = <50000000>; + controller-data { + samsung,spi-feedback-delay = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt deleted file mode 100644 index 20447529c985..000000000000 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ /dev/null @@ -1,209 +0,0 @@ -Samsung S5P/Exynos SoC Camera Subsystem (FIMC) ----------------------------------------------- - -The S5P/Exynos SoC Camera subsystem comprises of multiple sub-devices -represented by separate device tree nodes. Currently this includes: FIMC (in -the S5P SoCs series known as CAMIF), MIPI CSIS, FIMC-LITE and FIMC-IS (ISP). - -The sub-subdevices are defined as child nodes of the common 'camera' node which -also includes common properties of the whole subsystem not really specific to -any single sub-device, like common camera port pins or the CAMCLK clock outputs -for external image sensors attached to an SoC. - -Common 'camera' node --------------------- - -Required properties: - -- compatible: must be "samsung,fimc", "simple-bus" -- clocks: list of clock specifiers, corresponding to entries in - the clock-names property; -- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0", - "pxl_async1" entries, matching entries in the clocks property. - -- #clock-cells: from the common clock bindings (../clock/clock-bindings.txt), - must be 1. A clock provider is associated with the 'camera' node and it should - be referenced by external sensors that use clocks provided by the SoC on - CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock. - The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively. - -- clock-output-names: from the common clock bindings, should contain names of - clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT, - CAM_B_CLKOUT output clocks respectively. - -The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used -to define a required pinctrl state named "default" and optional pinctrl states: -"idle", "active-a", active-b". These optional states can be used to switch the -camera port pinmux at runtime. The "idle" state should configure both the camera -ports A and B into high impedance state, especially the CAMCLK clock output -should be inactive. For the "active-a" state the camera port A must be activated -and the port B deactivated and for the state "active-b" it should be the other -way around. - -The 'camera' node must include at least one 'fimc' child node. - - -'fimc' device nodes -------------------- - -Required properties: - -- compatible: "samsung,s5pv210-fimc" for S5PV210, "samsung,exynos4210-fimc" - for Exynos4210 and "samsung,exynos4212-fimc" for Exynos4x12 SoCs; -- reg: physical base address and length of the registers set for the device; -- interrupts: should contain FIMC interrupt; -- clocks: list of clock specifiers, must contain an entry for each required - entry in clock-names; -- clock-names: must contain "fimc", "sclk_fimc" entries. -- samsung,pix-limits: an array of maximum supported image sizes in pixels, for - details refer to Table 2-1 in the S5PV210 SoC User Manual; The meaning of - each cell is as follows: - 0 - scaler input horizontal size, - 1 - input horizontal size for the scaler bypassed, - 2 - REAL_WIDTH without input rotation, - 3 - REAL_HEIGHT with input rotation, -- samsung,sysreg: a phandle to the SYSREG node. - -Each FIMC device should have an alias in the aliases node, in the form of -fimc<n>, where <n> is an integer specifying the IP block instance. - -Optional properties: - -- clock-frequency: maximum FIMC local clock (LCLK) frequency; -- samsung,min-pix-sizes: an array specyfing minimum image size in pixels at - the FIMC input and output DMA, in the first and second cell respectively. - Default value when this property is not present is <16 16>; -- samsung,min-pix-alignment: minimum supported image height alignment (first - cell) and the horizontal image offset (second cell). The values are in pixels - and default to <2 1> when this property is not present; -- samsung,mainscaler-ext: a boolean property indicating whether the FIMC IP - supports extended image size and has CIEXTEN register; -- samsung,rotators: a bitmask specifying whether this IP has the input and - the output rotator. Bits 4 and 0 correspond to input and output rotator - respectively. If a rotator is present its corresponding bit should be set. - Default value when this property is not specified is 0x11. -- samsung,cam-if: a bolean property indicating whether the IP block includes - the camera input interface. -- samsung,isp-wb: this property must be present if the IP block has the ISP - writeback input. -- samsung,lcd-wb: this property must be present if the IP block has the LCD - writeback input. - - -'parallel-ports' node ---------------------- - -This node should contain child 'port' nodes specifying active parallel video -input ports. It includes camera A and camera B inputs. 'reg' property in the -port nodes specifies data input - 1, 2 indicates input A, B respectively. - -Optional properties - -- samsung,camclk-out (deprecated) : specifies clock output for remote sensor, - 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT; - -Image sensor nodes ------------------- - -The sensor device nodes should be added to their control bus controller (e.g. -I2C0) nodes and linked to a port node in the csis or the parallel-ports node, -using the common video interfaces bindings, defined in video-interfaces.txt. - -Example: - - aliases { - fimc0 = &fimc_0; - }; - - /* Parallel bus IF sensor */ - i2c_0: i2c@13860000 { - s5k6aa: sensor@3c { - compatible = "samsung,s5k6aafx"; - reg = <0x3c>; - vddio-supply = <...>; - - clock-frequency = <24000000>; - clocks = <&camera 1>; - clock-names = "mclk"; - - port { - s5k6aa_ep: endpoint { - remote-endpoint = <&fimc0_ep>; - bus-width = <8>; - hsync-active = <0>; - vsync-active = <1>; - pclk-sample = <1>; - }; - }; - }; - - /* MIPI CSI-2 bus IF sensor */ - s5c73m3: sensor@1a { - compatible = "samsung,s5c73m3"; - reg = <0x1a>; - vddio-supply = <...>; - - clock-frequency = <24000000>; - clocks = <&camera 0>; - clock-names = "mclk"; - - port { - s5c73m3_1: endpoint { - data-lanes = <1 2 3 4>; - remote-endpoint = <&csis0_ep>; - }; - }; - }; - }; - - camera { - compatible = "samsung,fimc", "simple-bus"; - clocks = <&clock 132>, <&clock 133>, <&clock 351>, - <&clock 352>; - clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", - "pxl_async1"; - #clock-cells = <1>; - clock-output-names = "cam_a_clkout", "cam_b_clkout"; - pinctrl-names = "default"; - pinctrl-0 = <&cam_port_a_clk_active>; - #address-cells = <1>; - #size-cells = <1>; - - /* parallel camera ports */ - parallel-ports { - /* camera A input */ - port@1 { - reg = <1>; - fimc0_ep: endpoint { - remote-endpoint = <&s5k6aa_ep>; - bus-width = <8>; - hsync-active = <0>; - vsync-active = <1>; - pclk-sample = <1>; - }; - }; - }; - - fimc_0: fimc@11800000 { - compatible = "samsung,exynos4210-fimc"; - reg = <0x11800000 0x1000>; - interrupts = <0 85 0>; - }; - - csis_0: csis@11880000 { - compatible = "samsung,exynos4210-csis"; - reg = <0x11880000 0x1000>; - interrupts = <0 78 0>; - /* camera C input */ - port@3 { - reg = <3>; - csis0_ep: endpoint { - remote-endpoint = <&s5c73m3_ep>; - data-lanes = <1 2 3 4>; - samsung,csis-hs-settle = <12>; - }; - }; - }; - }; - -The MIPI-CSIS device binding is defined in samsung-mipi-csis.txt. diff --git a/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt deleted file mode 100644 index a4149c9434ea..000000000000 --- a/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt +++ /dev/null @@ -1,81 +0,0 @@ -Samsung S5P/Exynos SoC series MIPI CSI-2 receiver (MIPI CSIS) -------------------------------------------------------------- - -Required properties: - -- compatible : "samsung,s5pv210-csis" for S5PV210 (S5PC110), - "samsung,exynos4210-csis" for Exynos4210 (S5PC210), - "samsung,exynos4212-csis" for Exynos4212/Exynos4412, - "samsung,exynos5250-csis" for Exynos5250; -- reg : offset and length of the register set for the device; -- interrupts : should contain MIPI CSIS interrupt; the format of the - interrupt specifier depends on the interrupt controller; -- bus-width : maximum number of data lanes supported (SoC specific); -- vddio-supply : MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V); -- vddcore-supply : MIPI CSIS Core voltage supply (e.g. 1.1V); -- clocks : list of clock specifiers, corresponding to entries in - clock-names property; -- clock-names : must contain "csis", "sclk_csis" entries, matching entries - in the clocks property. - -Optional properties: - -- clock-frequency : The IP's main (system bus) clock frequency in Hz, default - value when this property is not specified is 166 MHz; -- samsung,csis-wclk : CSI-2 wrapper clock selection. If this property is present - external clock from CMU will be used, or the bus clock if - if it's not specified. - -The device node should contain one 'port' child node with one child 'endpoint' -node, according to the bindings defined in Documentation/devicetree/bindings/ -media/video-interfaces.txt. The following are properties specific to those nodes. - -port node ---------- - -- reg : (required) must be 3 for camera C input (CSIS0) or 4 for - camera D input (CSIS1); - -endpoint node -------------- - -- data-lanes : (required) an array specifying active physical MIPI-CSI2 - data input lanes and their mapping to logical lanes; the - array's content is unused, only its length is meaningful; - -- samsung,csis-hs-settle : (optional) differential receiver (HS-RX) settle time; - - -Example: - - reg0: regulator@0 { - }; - - reg1: regulator@1 { - }; - -/* SoC properties */ - - csis_0: csis@11880000 { - compatible = "samsung,exynos4210-csis"; - reg = <0x11880000 0x1000>; - interrupts = <0 78 0>; - #address-cells = <1>; - #size-cells = <0>; - }; - -/* Board properties */ - - csis_0: csis@11880000 { - clock-frequency = <166000000>; - vddio-supply = <®0>; - vddcore-supply = <®1>; - port { - reg = <3>; /* 3 - CSIS0, 4 - CSIS1 */ - csis0_ep: endpoint { - remote-endpoint = <...>; - data-lanes = <1>, <2>; - samsung,csis-hs-settle = <12>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt deleted file mode 100644 index f0ea9adad442..000000000000 --- a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt +++ /dev/null @@ -1,97 +0,0 @@ -Samsung S5C73M3 8Mp camera ISP ------------------------------- - -The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) video -data busses. The I2C bus is the main control bus and additionally the SPI bus -is used, mostly for transferring the firmware to and from the device. Two -slave device nodes corresponding to these control bus interfaces are required -and should be placed under respective bus controller nodes. - -I2C slave device node ---------------------- - -Required properties: - -- compatible : "samsung,s5c73m3"; -- reg : I2C slave address of the sensor; -- vdd-int-supply : digital power supply (1.2V); -- vdda-supply : analog power supply (1.2V); -- vdd-reg-supply : regulator input power supply (2.8V); -- vddio-host-supply : host I/O power supply (1.8V to 2.8V); -- vddio-cis-supply : CIS I/O power supply (1.2V to 1.8V); -- vdd-af-supply : lens power supply (2.8V); -- xshutdown-gpios : specifier of GPIO connected to the XSHUTDOWN pin; -- standby-gpios : specifier of GPIO connected to the STANDBY pin; -- clocks : should contain list of phandle and clock specifier pairs - according to common clock bindings for the clocks described - in the clock-names property; -- clock-names : should contain "cis_extclk" entry for the CIS_EXTCLK clock; - -Optional properties: - -- clock-frequency : the frequency at which the "cis_extclk" clock should be - configured to operate, in Hz; if this property is not - specified default 24 MHz value will be used. - -The common video interfaces bindings (see video-interfaces.txt) should be used -to specify link from the S5C73M3 to an external image data receiver. The S5C73M3 -device node should contain one 'port' child node with an 'endpoint' subnode for -this purpose. The data link from a raw image sensor to the S5C73M3 can be -similarly specified, but it is optional since the S5C73M3 ISP and a raw image -sensor are usually inseparable and form a hybrid module. - -Following properties are valid for the endpoint node(s): - -endpoint subnode ----------------- - -- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in - video-interfaces.txt. This sensor doesn't support data lane remapping - and physical lane indexes in subsequent elements of the array should - be only consecutive ascending values. - -SPI device node ---------------- - -Required properties: - -- compatible : "samsung,s5c73m3"; - -For more details see description of the SPI busses bindings -(../spi/spi-bus.txt) and bindings of a specific bus controller. - -Example: - -i2c@138a000000 { - ... - s5c73m3@3c { - compatible = "samsung,s5c73m3"; - reg = <0x3c>; - vdd-int-supply = <&buck9_reg>; - vdda-supply = <&ldo17_reg>; - vdd-reg-supply = <&cam_io_reg>; - vddio-host-supply = <&ldo18_reg>; - vddio-cis-supply = <&ldo9_reg>; - vdd-af-supply = <&cam_af_reg>; - clock-frequency = <24000000>; - clocks = <&clk 0>; - clock-names = "cis_extclk"; - xshutdown-gpios = <&gpf1 3 1>; - standby-gpios = <&gpm0 1 1>; - port { - s5c73m3_ep: endpoint { - remote-endpoint = <&csis0_ep>; - data-lanes = <1 2 3 4>; - }; - }; - }; -}; - -spi@1392000 { - ... - s5c73m3_spi: s5c73m3@0 { - compatible = "samsung,s5c73m3"; - reg = <0>; - ... - }; -}; diff --git a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt deleted file mode 100644 index 1f51e0439c96..000000000000 --- a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt +++ /dev/null @@ -1,58 +0,0 @@ -Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor with embedded SoC ISP --------------------------------------------------------------------- - -Required properties: - -- compatible : "samsung,s5k5baf"; -- reg : I2C slave address of the sensor; -- vdda-supply : analog power supply 2.8V (2.6V to 3.0V); -- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V) - or 2.8V (2.6V to 3.0); -- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V) - or 2.8V (2.5V to 3.1V); -- stbyn-gpios : GPIO connected to STDBYN pin; -- rstn-gpios : GPIO connected to RSTN pin; -- clocks : list of phandle and clock specifier pairs - according to common clock bindings for the - clocks described in clock-names; -- clock-names : should include "mclk" for the sensor's master clock; - -Optional properties: - -- clock-frequency : the frequency at which the "mclk" clock should be - configured to operate, in Hz; if this property is not - specified default 24 MHz value will be used. - -The device node should contain one 'port' child node with one child 'endpoint' -node, according to the bindings defined in Documentation/devicetree/bindings/ -media/video-interfaces.txt. The following are properties specific to those -nodes. - -endpoint node -------------- - -- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in - video-interfaces.txt. If present it should be <1> - the device - supports only one data lane without re-mapping. - -Example: - -s5k5bafx@2d { - compatible = "samsung,s5k5baf"; - reg = <0x2d>; - vdda-supply = <&cam_io_en_reg>; - vddreg-supply = <&vt_core_15v_reg>; - vddio-supply = <&vtcam_reg>; - stbyn-gpios = <&gpl2 0 1>; - rstn-gpios = <&gpl2 1 1>; - clock-names = "mclk"; - clocks = <&clock_cam 0>; - clock-frequency = <24000000>; - - port { - s5k5bafx_ep: endpoint { - remote-endpoint = <&csis1_ep>; - data-lanes = <1>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt deleted file mode 100644 index cce01e82f3e3..000000000000 --- a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt +++ /dev/null @@ -1,33 +0,0 @@ -Samsung S5K6A3(YX) raw image sensor ---------------------------------- - -S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces -and CCI (I2C compatible) control bus. - -Required properties: - -- compatible : "samsung,s5k6a3"; -- reg : I2C slave address of the sensor; -- svdda-supply : core voltage supply; -- svddio-supply : I/O voltage supply; -- afvdd-supply : AF (actuator) voltage supply; -- gpios : specifier of a GPIO connected to the RESET pin; -- clocks : should contain list of phandle and clock specifier pairs - according to common clock bindings for the clocks described - in the clock-names property; -- clock-names : should contain "extclk" entry for the sensor's EXTCLK clock; - -Optional properties: - -- clock-frequency : the frequency at which the "extclk" clock should be - configured to operate, in Hz; if this property is not - specified default 24 MHz value will be used. - -The common video interfaces bindings (see video-interfaces.txt) should be -used to specify link to the image data receiver. The S5K6A3(YX) device -node should contain one 'port' child node with an 'endpoint' subnode. - -Following properties are valid for the endpoint node: - -- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in - video-interfaces.txt. The sensor supports only one data lane. diff --git a/Documentation/devicetree/bindings/media/si470x.txt b/Documentation/devicetree/bindings/media/si470x.txt deleted file mode 100644 index a9403558362e..000000000000 --- a/Documentation/devicetree/bindings/media/si470x.txt +++ /dev/null @@ -1,26 +0,0 @@ -* Silicon Labs FM Radio receiver - -The Silicon Labs Si470x is family of FM radio receivers with receive power scan -supporting 76-108 MHz, programmable through an I2C interface. -Some of them includes an RDS encoder. - -Required Properties: -- compatible: Should contain "silabs,si470x" -- reg: the I2C address of the device - -Optional Properties: -- interrupts : The interrupt number -- reset-gpios: GPIO specifier for the chips reset line - -Example: - -&i2c2 { - si470x@63 { - compatible = "silabs,si470x"; - reg = <0x63>; - - interrupt-parent = <&gpj2>; - interrupts = <4 IRQ_TYPE_EDGE_FALLING>; - reset-gpios = <&gpj2 5 GPIO_ACTIVE_HIGH>; - }; -}; diff --git a/Documentation/devicetree/bindings/media/silabs,si470x.yaml b/Documentation/devicetree/bindings/media/silabs,si470x.yaml new file mode 100644 index 000000000000..a3d19c562ca3 --- /dev/null +++ b/Documentation/devicetree/bindings/media/silabs,si470x.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/silabs,si470x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silicon Labs Si470x FM Radio Receiver + +maintainers: + - Hans Verkuil <hverkuil@xs4all.nl> + - PaweÅ‚ Chmiel <pawel.mikolaj.chmiel@gmail.com> + +properties: + compatible: + const: silabs,si470x + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + reset-gpios: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + fmradio@10 { + compatible = "silabs,si470x"; + reg = <0x10>; + interrupt-parent = <&gpj2>; + interrupts = <4 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpj2 5 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/st,stm32-cec.yaml b/Documentation/devicetree/bindings/media/st,stm32-cec.yaml deleted file mode 100644 index 7f545a587a39..000000000000 --- a/Documentation/devicetree/bindings/media/st,stm32-cec.yaml +++ /dev/null @@ -1,53 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/media/st,stm32-cec.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: STMicroelectronics STM32 CEC - -maintainers: - - Yannick Fertre <yannick.fertre@foss.st.com> - -properties: - compatible: - const: st,stm32-cec - - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - - clocks: - items: - - description: Module Clock - - description: Bus Clock - - clock-names: - items: - - const: cec - - const: hdmi-cec - -required: - - compatible - - reg - - interrupts - - clocks - - clock-names - -additionalProperties: false - -examples: - - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/stm32mp1-clks.h> - cec: cec@40006c00 { - compatible = "st,stm32-cec"; - reg = <0x40006c00 0x400>; - interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&rcc CEC_K>, <&clk_lse>; - clock-names = "cec", "hdmi-cec"; - }; - -... diff --git a/Documentation/devicetree/bindings/media/ti,cal.yaml b/Documentation/devicetree/bindings/media/ti,cal.yaml index f8e4d260d10a..f1a940a110d2 100644 --- a/Documentation/devicetree/bindings/media/ti,cal.yaml +++ b/Documentation/devicetree/bindings/media/ti,cal.yaml @@ -47,7 +47,7 @@ properties: maxItems: 1 ti,camerrx-control: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to device control module @@ -75,7 +75,7 @@ properties: port@0: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false - description: CSI2 Port #0 + description: 'CSI2 Port #0' properties: endpoint: @@ -93,7 +93,7 @@ properties: port@1: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false - description: CSI2 Port #1 + description: 'CSI2 Port #1' properties: endpoint: diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl35x-smc.yaml b/Documentation/devicetree/bindings/memory-controllers/arm,pl35x-smc.yaml index bd23257fe021..6d3962a17e49 100644 --- a/Documentation/devicetree/bindings/memory-controllers/arm,pl35x-smc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl35x-smc.yaml @@ -73,6 +73,7 @@ properties: patternProperties: "@[0-7],[a-f0-9]+$": type: object + additionalProperties: true description: | The child device node represents the controller connected to the SMC bus. The controller can be a NAND controller or a pair of any memory diff --git a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml index c6e44f47ce7c..10a2d97e5f8b 100644 --- a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml @@ -38,6 +38,7 @@ properties: patternProperties: "^.*@[0-3],[a-f0-9]+$": type: object + 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 diff --git a/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml index 188db821dff3..3049d6bb0b1f 100644 --- a/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/intel,ixp4xx-expansion-bus-controller.yaml @@ -57,6 +57,7 @@ patternProperties: subnodes. type: object $ref: /schemas/memory-controllers/intel,ixp4xx-expansion-peripheral-props.yaml# + additionalProperties: true required: - compatible diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index a8fda30cccbb..2f36ac23604c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -43,6 +43,7 @@ properties: - mediatek,mt8195-smi-common-vdo - mediatek,mt8195-smi-common-vpp - mediatek,mt8195-smi-sub-common + - mediatek,mt8365-smi-common - description: for mt7623 items: @@ -133,6 +134,7 @@ allOf: - mediatek,mt8192-smi-common - mediatek,mt8195-smi-common-vdo - mediatek,mt8195-smi-common-vpp + - mediatek,mt8365-smi-common then: properties: diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index 5f4ac3609887..aee7f6cf1300 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -34,6 +34,10 @@ properties: - const: mediatek,mt7623-smi-larb - const: mediatek,mt2701-smi-larb + - items: + - const: mediatek,mt8365-smi-larb + - const: mediatek,mt8186-smi-larb + reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml index 9163c3f12a85..f5f03bf36413 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml @@ -50,6 +50,7 @@ properties: patternProperties: "^emc-timings-[0-9]+$": type: object + additionalProperties: false properties: nvidia,ram-code: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml index 7056ccb7eb30..8e3822314b25 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/memory-controllers/renesas,dbsc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/memory-controllers/renesas,dbsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas DDR Bus Controllers diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 30a403b1b79a..56e62cd0b36a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -20,7 +20,7 @@ description: | - if it contains "cfi-flash", then HyperFlash is used. allOf: - - $ref: "/schemas/spi/spi-controller.yaml#" + - $ref: /schemas/spi/spi-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml index 098348b2b815..783ac984d898 100644 --- a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml @@ -42,7 +42,7 @@ properties: maxItems: 8 devfreq-events: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 16 items: @@ -50,7 +50,7 @@ properties: description: phandles of the PPMU events used by the controller. device-handle: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | phandle of the connected DRAM memory device. For more information please refer to jedec,lpddr3.yaml. @@ -73,7 +73,7 @@ properties: - description: registers of DREX1 samsung,syscon-clk: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | Phandle of the clock register set used by the controller, these registers are used for enabling a 'pause' feature and are not exposed by clock diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml index e76ba767dfd2..14f1833d37c9 100644 --- a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml @@ -47,6 +47,7 @@ properties: patternProperties: "^.*@[0-4],[a-f0-9]+$": + additionalProperties: true type: object $ref: mc-peripheral-props.yaml# diff --git a/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml b/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml index c3a368a0fe93..6811246c5771 100644 --- a/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml +++ b/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml @@ -129,7 +129,7 @@ required: examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml index e8e74e91070c..c5a7e10d7d80 100644 --- a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml +++ b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml @@ -12,6 +12,11 @@ maintainers: description: | For device-tree bindings of other sub-modules refer to the binding documents under the respective sub-system directories. + Using regulator-{uv,ov}-{warn,error,protection}-microvolt requires special + handling: First, when GP_FB2 is used, it must be ensured that there is no + moment where all voltage monitors are disabled. Next, as da9063 only supports + UV *and* OV monitoring, both must be set to the same severity and value + (0: disable, 1: enable). properties: compatible: @@ -121,11 +126,19 @@ examples: regulator-max-microamp = <2000000>; regulator-boot-on; }; + ldo6 { + /* UNUSED */ + regulator-name = "LDO_6"; + regulator-uv-protection-microvolt = <0>; + regulator-ov-protection-microvolt = <0>; + }; ldo11 { regulator-name = "LDO_11"; regulator-min-microvolt = <900000>; - regulator-max-microvolt = <3600000>; - regulator-boot-on; + regulator-max-microvolt = <900000>; + regulator-uv-protection-microvolt = <1>; + regulator-ov-protection-microvolt = <1>; + regulator-always-on; }; }; }; diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index cdf1d719efe9..8caa48f4570e 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -246,7 +246,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -263,7 +263,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; @@ -296,7 +296,7 @@ examples: # Example for FPMCU - | - spi0 { + spi { #address-cells = <0x1>; #size-cells = <0x0>; diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml index 837a77013d57..fc2a53148e1c 100644 --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml @@ -46,6 +46,7 @@ properties: rtc: type: object $ref: /schemas/rtc/rtc.yaml# + unevaluatedProperties: false description: MT6357 Real Time Clock. properties: diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml index 5644882db2e8..c9574b243046 100644 --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml @@ -35,6 +35,7 @@ properties: adc: type: object + additionalProperties: false description: | Provides 9 channels for system monitoring, including VBUSDIV5 (lower accuracy, higher measure range), VBUSDIV2 (higher accuracy, lower @@ -73,6 +74,7 @@ properties: regulators: type: object + additionalProperties: false description: | List all supported regulators, which support the control for DisplayBias voltages and one general purpose LDO which commonly used to drive the diff --git a/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml b/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml index 3fdd9cb5b347..bd36a07c1721 100644 --- a/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml @@ -95,7 +95,7 @@ required: examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml index b7a8747d5fa0..24d03996b93a 100644 --- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml @@ -299,7 +299,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -315,7 +315,7 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/mips/loongson/devices.yaml b/Documentation/devicetree/bindings/mips/loongson/devices.yaml index f13ce386f42c..099e40e1482d 100644 --- a/Documentation/devicetree/bindings/mips/loongson/devices.yaml +++ b/Documentation/devicetree/bindings/mips/loongson/devices.yaml @@ -37,6 +37,18 @@ properties: items: - const: loongson,loongson64v-4core-virtio + - description: LS1B based boards + items: + - enum: + - loongson,lsgz-1b-dev + - const: loongson,ls1b + + - description: LS1C based boards + items: + - enum: + - loongmasses,smartloong-1c + - const: loongson,ls1c + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml index 8296c34cfa00..a6c19a6cc99e 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml @@ -27,6 +27,7 @@ allOf: enum: - xlnx,zynqmp-8.9a - xlnx,versal-8.9a + - xlnx,versal-net-emmc then: properties: clock-output-names: @@ -62,6 +63,10 @@ properties: description: For this device it is strongly suggested to include clock-output-names and '#clock-cells'. + - const: xlnx,versal-net-emmc # Versal Net eMMC PHY + description: + For this device it is strongly suggested to include + clock-output-names and '#clock-cells'. - items: - const: intel,lgm-sdhci-5.1-emmc # Intel LGM eMMC PHY - const: arasan,sdhci-5.1 @@ -88,12 +93,6 @@ properties: description: For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - items: - - const: intel,thunderbay-sdhci-5.1 # Intel Thunder Bay eMMC PHY - - const: arasan,sdhci-5.1 - description: - For this device it is strongly suggested to include - clock-output-names and '#clock-cells'. reg: maxItems: 1 @@ -309,22 +308,3 @@ examples: <&scmi_clk KEEM_BAY_PSS_SD0>; arasan,soc-ctl-syscon = <&sd0_phy_syscon>; }; - - - | - #define EMMC_XIN_CLK - #define EMMC_AXI_CLK - #define TBH_PSS_EMMC_RST_N - mmc@80420000 { - compatible = "intel,thunderbay-sdhci-5.1", "arasan,sdhci-5.1"; - interrupts = <GIC_SPI 714 IRQ_TYPE_LEVEL_HIGH>; - reg = <0x80420000 0x400>; - clocks = <&scmi_clk EMMC_XIN_CLK>, - <&scmi_clk EMMC_AXI_CLK>; - clock-names = "clk_xin", "clk_ahb"; - phys = <&emmc_phy>; - phy-names = "phy_arasan"; - assigned-clocks = <&scmi_clk EMMC_XIN_CLK>; - clock-output-names = "emmc_cardclock"; - resets = <&rst_pss1 TBH_PSS_EMMC_RST_N>; - #clock-cells = <0x0>; - }; diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml index 987b287f3bff..9fce8cd7b0b6 100644 --- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml @@ -42,6 +42,7 @@ patternProperties: "^sdhci@[0-9a-f]+$": type: object $ref: mmc-controller.yaml + unevaluatedProperties: false properties: compatible: diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml index adacd0535c14..6c40611405a0 100644 --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml @@ -9,19 +9,18 @@ title: Cadence SD/SDIO/eMMC Host Controller (SD4HC) maintainers: - Masahiro Yamada <yamada.masahiro@socionext.com> -allOf: - - $ref: mmc-controller.yaml - properties: compatible: items: - enum: + - amd,pensando-elba-sd4hc - microchip,mpfs-sd4hc - socionext,uniphier-sd4hc - const: cdns,sd4hc reg: - maxItems: 1 + minItems: 1 + maxItems: 2 interrupts: maxItems: 1 @@ -120,6 +119,26 @@ required: - interrupts - clocks +allOf: + - $ref: mmc-controller.yaml + - if: + properties: + compatible: + contains: + const: amd,pensando-elba-sd4hc + then: + properties: + reg: + items: + - description: Host controller registers + - description: Elba byte-lane enable register for writes + required: + - resets + else: + properties: + reg: + maxItems: 1 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index 7f721fbfb009..fbfd822b9270 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -10,7 +10,7 @@ maintainers: - Shawn Guo <shawnguo@kernel.org> allOf: - - $ref: mmc-controller.yaml + - $ref: sdhci-common.yaml# description: | The Enhanced Secure Digital Host Controller on Freescale i.MX family diff --git a/Documentation/devicetree/bindings/mmc/fujitsu,sdhci-fujitsu.yaml b/Documentation/devicetree/bindings/mmc/fujitsu,sdhci-fujitsu.yaml index 73d747e917f3..430b62899397 100644 --- a/Documentation/devicetree/bindings/mmc/fujitsu,sdhci-fujitsu.yaml +++ b/Documentation/devicetree/bindings/mmc/fujitsu,sdhci-fujitsu.yaml @@ -14,9 +14,13 @@ allOf: properties: compatible: - enum: - - fujitsu,mb86s70-sdhci-3.0 - - socionext,f-sdh30-e51-mmc + oneOf: + - items: + - const: socionext,synquacer-sdhci + - const: fujitsu,mb86s70-sdhci-3.0 + - enum: + - fujitsu,mb86s70-sdhci-3.0 + - socionext,f-sdh30-e51-mmc reg: maxItems: 1 @@ -29,6 +33,11 @@ properties: - const: iface - const: core + dma-coherent: true + + interrupts: + maxItems: 2 + resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 7a649ebc688c..46eefdd19a2c 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -34,6 +34,7 @@ properties: - mediatek,mt8188-mmc - mediatek,mt8192-mmc - mediatek,mt8195-mmc + - mediatek,mt8365-mmc - const: mediatek,mt8183-mmc reg: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml index 64df6919abaf..4f2d9e8127dd 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml @@ -34,8 +34,10 @@ properties: - const: qcom,sdhci-msm-v4 # for sdcc versions less than 5.0 - items: - enum: + - qcom,ipq5018-sdhci - qcom,ipq5332-sdhci - qcom,ipq9574-sdhci + - qcom,qcm2290-sdhci - qcom,qcs404-sdhci - qcom,sc7180-sdhci - qcom,sc7280-sdhci diff --git a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml index e7ec0c59bca6..9a88870cd865 100644 --- a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Allwinner A10 NAND Controller allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml maintainers: - Chen-Yu Tsai <wens@csie.org> diff --git a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml index d028269cdbaa..2fe53cbfbee0 100644 --- a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Arasan NAND Flash Controller with ONFI 3.1 support allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml maintainers: - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> diff --git a/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml index e552875040e2..f8c0f606f451 100644 --- a/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml +++ b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: PL353 NAND Controller allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml maintainers: - Miquel Raynal <miquel.raynal@bootlin.com> diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml index 8487089b6e16..ba086c34626d 100644 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml @@ -93,7 +93,7 @@ required: unevaluatedProperties: false allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml - if: properties: diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml index 8c62c7d3d0cd..cc3def758e00 100644 --- a/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel LGM SoC NAND Controller allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml maintainers: - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 3fe981b14e2c..89959e5c47ba 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -10,7 +10,7 @@ maintainers: - Rob Herring <robh@kernel.org> allOf: - - $ref: "mtd.yaml#" + - $ref: mtd.yaml# - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: @@ -76,6 +76,13 @@ properties: If "broken-flash-reset" is present then having this property does not make any difference. + spi-cpol: true + spi-cpha: true + +dependencies: + spi-cpol: [ spi-cpha ] + spi-cpha: [ spi-cpol ] + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml index 44cd4476d1d3..f8c976898a95 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -14,7 +14,7 @@ description: | file systems on embedded devices. allOf: - - $ref: "mtd.yaml#" + - $ref: mtd.yaml# - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml# properties: diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml index 78da129e9985..da3d488c335f 100644 --- a/Documentation/devicetree/bindings/mtd/mtd.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml @@ -44,6 +44,7 @@ patternProperties: "^otp(-[0-9]+)?$": $ref: ../nvmem/nvmem.yaml# + unevaluatedProperties: false description: | An OTP memory region. Some flashes provide a one-time-programmable diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml index 7f6f7c9596c4..cf4198e43d7f 100644 --- a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml @@ -10,7 +10,7 @@ maintainers: - Uwe Kleine-König <u.kleine-koenig@pengutronix.de> allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/mtd/nand-chip.yaml b/Documentation/devicetree/bindings/mtd/nand-chip.yaml index 33d079f76c05..609d4a4ddd80 100644 --- a/Documentation/devicetree/bindings/mtd/nand-chip.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-chip.yaml @@ -10,7 +10,7 @@ maintainers: - Miquel Raynal <miquel.raynal@bootlin.com> allOf: - - $ref: "mtd.yaml#" + - $ref: mtd.yaml# description: | This file covers the generic description of a NAND chip. It implies that the diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index efcd415f8641..f70a32d2d9d4 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -51,7 +51,7 @@ properties: patternProperties: "^nand@[a-f0-9]$": - $ref: "nand-chip.yaml#" + $ref: nand-chip.yaml# properties: reg: diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml index 5bbb1c01ddee..94f0742b375c 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml @@ -31,7 +31,7 @@ properties: patternProperties: "^partition@[0-9a-f]+$": - $ref: "partition.yaml#" + $ref: partition.yaml# properties: compatible: const: brcm,bcm4908-firmware diff --git a/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml index 213858f60375..c5fa78ff7125 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml @@ -32,7 +32,7 @@ properties: patternProperties: "^partition@[0-9a-f]+$": - $ref: "partition.yaml#" + $ref: partition.yaml# properties: compatible: items: diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml index 07024ee45951..00c991ffa6c4 100644 --- a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml +++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml @@ -46,7 +46,7 @@ patternProperties: - 512 allOf: - - $ref: "nand-controller.yaml#" + - $ref: nand-controller.yaml# - if: properties: diff --git a/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml b/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml index f0dc78bb0515..cc6b8274e6a2 100644 --- a/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml +++ b/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml @@ -10,7 +10,7 @@ maintainers: - Miquel Raynal <miquel.raynal@bootlin.com> allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml index 566f330851f7..7eb1d0a38565 100644 --- a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Rockchip SoCs NAND FLASH Controller (NFC) allOf: - - $ref: "nand-controller.yaml#" + - $ref: nand-controller.yaml# maintainers: - Heiko Stuebner <heiko@sntech.de> diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.yaml b/Documentation/devicetree/bindings/mtd/spi-nand.yaml index 4d095e613204..77a8727c7966 100644 --- a/Documentation/devicetree/bindings/mtd/spi-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/spi-nand.yaml @@ -10,7 +10,7 @@ maintainers: - Miquel Raynal <miquel.raynal@bootlin.com> allOf: - - $ref: "nand-chip.yaml#" + - $ref: nand-chip.yaml# - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml index 19cf1f18b61c..986e85ccebc7 100644 --- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml @@ -45,7 +45,7 @@ patternProperties: enum: [1, 4, 8] allOf: - - $ref: "nand-controller.yaml#" + - $ref: nand-controller.yaml# - if: properties: diff --git a/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml index 4ac198814b7a..115682fa81b7 100644 --- a/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml @@ -63,10 +63,10 @@ properties: patternProperties: "@[0-9a-f]+$": - $ref: "/schemas/mtd/partitions/partition.yaml" + $ref: /schemas/mtd/partitions/partition.yaml allOf: - - $ref: "/schemas/memory-controllers/ti,gpmc-child.yaml" + - $ref: /schemas/memory-controllers/ti,gpmc-child.yaml required: - compatible diff --git a/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml b/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml index 8a79ad300216..7d3ace4f5505 100644 --- a/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml +++ b/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml @@ -36,10 +36,10 @@ properties: patternProperties: "@[0-9a-f]+$": - $ref: "/schemas/mtd/partitions/partition.yaml" + $ref: /schemas/mtd/partitions/partition.yaml allOf: - - $ref: "/schemas/memory-controllers/ti,gpmc-child.yaml" + - $ref: /schemas/memory-controllers/ti,gpmc-child.yaml required: - compatible diff --git a/Documentation/devicetree/bindings/net/actions,owl-emac.yaml b/Documentation/devicetree/bindings/net/actions,owl-emac.yaml index d30fada2ac39..5718ab4654b2 100644 --- a/Documentation/devicetree/bindings/net/actions,owl-emac.yaml +++ b/Documentation/devicetree/bindings/net/actions,owl-emac.yaml @@ -16,7 +16,7 @@ description: | operation modes at 10/100 Mb/s data transfer rates. allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml index 987b91b9afe9..eb26623dab51 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Allwinner A10 EMAC Ethernet Controller allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# maintainers: - Chen-Yu Tsai <wens@csie.org> diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml index ede977cdfb8d..85f552b907f3 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml @@ -11,7 +11,7 @@ maintainers: - Maxime Ripard <mripard@kernel.org> allOf: - - $ref: "mdio.yaml#" + - $ref: mdio.yaml# # Select every compatible, including the deprecated ones. This way, we # will be able to report a warning when we have that compatible, since diff --git a/Documentation/devicetree/bindings/net/altr,tse.yaml b/Documentation/devicetree/bindings/net/altr,tse.yaml index 8d1d94494349..9d02af468906 100644 --- a/Documentation/devicetree/bindings/net/altr,tse.yaml +++ b/Documentation/devicetree/bindings/net/altr,tse.yaml @@ -66,7 +66,7 @@ required: - tx-fifo-depth allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index ddd5a073c3a8..a2c51a84efa5 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson DWMAC Ethernet controller diff --git a/Documentation/devicetree/bindings/net/asix,ax88796c.yaml b/Documentation/devicetree/bindings/net/asix,ax88796c.yaml index 164d1ff9e83c..6b849a4349c0 100644 --- a/Documentation/devicetree/bindings/net/asix,ax88796c.yaml +++ b/Documentation/devicetree/bindings/net/asix,ax88796c.yaml @@ -58,7 +58,7 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/gpio/gpio.h> - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml index f81eda8cb0a5..d6ef468495c5 100644 --- a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml +++ b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml @@ -15,7 +15,7 @@ description: |+ MAC. allOf: - - $ref: "mdio.yaml#" + - $ref: mdio.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml new file mode 100644 index 000000000000..57e4c87cb00b --- /dev/null +++ b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/bluetooth/nxp,88w8987-bt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Bluetooth chips + +description: + This binding describes UART-attached NXP bluetooth chips. These chips + are dual-radio chips supporting WiFi and Bluetooth. The bluetooth + works on standard H4 protocol over 4-wire UART. The RTS and CTS lines + are used during FW download. To enable power save mode, the host + asserts break signal over UART-TX line to put the chip into power save + state. De-asserting break wakes up the BT chip. + +maintainers: + - Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> + +properties: + compatible: + enum: + - nxp,88w8987-bt + - nxp,88w8997-bt + + fw-init-baudrate: + description: + Chip baudrate after FW is downloaded and initialized. + This property depends on the module vendor's + configuration. If this property is not specified, + 115200 is set as default. + +required: + - compatible + +additionalProperties: false + +examples: + - | + serial { + bluetooth { + compatible = "nxp,88w8987-bt"; + fw-init-baudrate = <3000000>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml index a6a6b0e4df7a..68f78b90d23a 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml @@ -23,6 +23,7 @@ properties: - qcom,wcn3998-bt - qcom,qca6390-bt - qcom,wcn6750-bt + - qcom,wcn6855-bt enable-gpios: maxItems: 1 @@ -133,6 +134,22 @@ allOf: - vddrfa1p7-supply - vddrfa1p2-supply - vddasd-supply + - if: + properties: + compatible: + contains: + enum: + - qcom,wcn6855-bt + then: + required: + - enable-gpios + - swctrl-gpios + - vddio-supply + - vddbtcxmx-supply + - vddrfacmn-supply + - vddrfa0p8-supply + - vddrfa1p2-supply + - vddrfa1p7-supply examples: - | diff --git a/Documentation/devicetree/bindings/net/brcm,amac.yaml b/Documentation/devicetree/bindings/net/brcm,amac.yaml index ee2eac8f5710..210fb29c4e7b 100644 --- a/Documentation/devicetree/bindings/net/brcm,amac.yaml +++ b/Documentation/devicetree/bindings/net/brcm,amac.yaml @@ -10,7 +10,7 @@ maintainers: - Florian Fainelli <f.fainelli@gmail.com> allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml index c99034f053e8..0e5e5db32faf 100644 --- a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml +++ b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml @@ -73,8 +73,6 @@ allOf: unevaluatedProperties: false examples: - #include <dt-bindings/interrupt-controller/arm-gic.h> - - | ethernet@f0b60000 { phy-mode = "internal"; diff --git a/Documentation/devicetree/bindings/net/brcm,systemport.yaml b/Documentation/devicetree/bindings/net/brcm,systemport.yaml index 5fc9c9fafd85..b40006d44791 100644 --- a/Documentation/devicetree/bindings/net/brcm,systemport.yaml +++ b/Documentation/devicetree/bindings/net/brcm,systemport.yaml @@ -66,7 +66,7 @@ required: - phy-mode allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml index b964c7dcec15..cc70b00c6ce5 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml @@ -121,7 +121,7 @@ required: - compatible dependencies: - brcm,requires-autobaud-mode: [ 'shutdown-gpios' ] + brcm,requires-autobaud-mode: [ shutdown-gpios ] if: not: diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml index 6e59bd2a6094..4162469c3c08 100644 --- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml +++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml @@ -63,6 +63,9 @@ properties: boot loader. This property should only be used the used operating system doesn't support the clocks and clock-names property. + power-domains: + maxItems: 1 + xceiver-supply: description: Regulator that powers the CAN transceiver. diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml index fce84aecae77..2a98b26630cb 100644 --- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml +++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml @@ -62,7 +62,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml b/Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml new file mode 100644 index 000000000000..769fa5c27b76 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/st,stm32-bxcan.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/st,stm32-bxcan.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics bxCAN controller + +description: STMicroelectronics BxCAN controller for CAN bus + +maintainers: + - Dario Binacchi <dario.binacchi@amarulasolutions.com> + +allOf: + - $ref: can-controller.yaml# + +properties: + compatible: + enum: + - st,stm32f4-bxcan + + st,can-primary: + description: + Primary and secondary mode of the bxCAN peripheral is only relevant + if the chip has two CAN peripherals. In that case they share some + of the required logic. + To avoid misunderstandings, it should be noted that ST documentation + uses the terms master/slave instead of primary/secondary. + type: boolean + + reg: + maxItems: 1 + + interrupts: + items: + - description: transmit interrupt + - description: FIFO 0 receive interrupt + - description: FIFO 1 receive interrupt + - description: status change error interrupt + + interrupt-names: + items: + - const: tx + - const: rx0 + - const: rx1 + - const: sce + + resets: + maxItems: 1 + + clocks: + maxItems: 1 + + st,gcan: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + The phandle to the gcan node which allows to access the 512-bytes + SRAM memory shared by the two bxCAN cells (CAN1 primary and CAN2 + secondary) in dual CAN peripheral configuration. + +required: + - compatible + - reg + - interrupts + - resets + - clocks + - st,gcan + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/stm32fx-clock.h> + #include <dt-bindings/mfd/stm32f4-rcc.h> + + can1: can@40006400 { + compatible = "st,stm32f4-bxcan"; + reg = <0x40006400 0x200>; + interrupts = <19>, <20>, <21>, <22>; + interrupt-names = "tx", "rx0", "rx1", "sce"; + resets = <&rcc STM32F4_APB1_RESET(CAN1)>; + clocks = <&rcc 0 STM32F4_APB1_CLOCK(CAN1)>; + st,can-primary; + st,gcan = <&gcan>; + }; diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml index 65af8183cb9c..897d2cbda45b 100644 --- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml +++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml @@ -35,15 +35,15 @@ properties: maxItems: 1 tx-fifo-depth: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: CAN Tx fifo depth (Zynq, Axi CAN). rx-fifo-depth: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: CAN Rx fifo depth (Zynq, Axi CAN, CAN FD in sequential Rx mode) tx-mailbox-count: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: CAN Tx mailbox buffer count (CAN FD) required: diff --git a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml index 253b5d1407ee..44fd23a5fa2b 100644 --- a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml +++ b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml @@ -31,9 +31,9 @@ properties: ranges: true -#The subnodes represents the two ethernet ports in this device. -#They are not independent of each other since they share resources -#in the parent node, and are thus children. +# The subnodes represents the two ethernet ports in this device. +# They are not independent of each other since they share resources +# in the parent node, and are thus children. patternProperties: "^ethernet-port@[0-9]+$": type: object diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml index 5bef4128d175..4c78c546343f 100644 --- a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml +++ b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml @@ -19,6 +19,7 @@ properties: - const: brcm,bcm53115 - const: brcm,bcm53125 - const: brcm,bcm53128 + - const: brcm,bcm53134 - const: brcm,bcm5365 - const: brcm,bcm5395 - const: brcm,bcm5389 @@ -57,8 +58,11 @@ properties: - items: - enum: - brcm,bcm3384-switch + - brcm,bcm6318-switch - brcm,bcm6328-switch + - brcm,bcm6362-switch - brcm,bcm6368-switch + - brcm,bcm63268-switch - const: brcm,bcm63xx-switch required: diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml index eed16e216fb6..c745407f2f68 100644 --- a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml +++ b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml @@ -76,12 +76,6 @@ properties: supports reporting the number of packets in-flight in a switch queue type: boolean - "#address-cells": - const: 1 - - "#size-cells": - const: 0 - ports: type: object @@ -99,11 +93,9 @@ properties: required: - reg - interrupts - - "#address-cells" - - "#size-cells" allOf: - - $ref: "dsa.yaml#" + - $ref: dsa.yaml# - if: properties: compatible: @@ -145,8 +137,6 @@ examples: - | switch@f0b00000 { compatible = "brcm,bcm7445-switch-v4.0"; - #address-cells = <1>; - #size-cells = <0>; reg = <0xf0b00000 0x40000>, <0xf0b40000 0x110>, <0xf0b40340 0x30>, diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml index 449ee0735012..e532c6b795f4 100644 --- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml +++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml @@ -11,16 +11,23 @@ maintainers: - Landen Chao <Landen.Chao@mediatek.com> - DENG Qingfang <dqfext@gmail.com> - Sean Wang <sean.wang@mediatek.com> + - Daniel Golle <daniel@makrotopia.org> description: | - There are two versions of MT7530, standalone and in a multi-chip module. + There are three versions of MT7530, standalone, in a multi-chip module and + built-into a SoC. MT7530 is a part of the multi-chip module in MT7620AN, MT7620DA, MT7620DAN, MT7620NN, MT7621AT, MT7621DAT, MT7621ST and MT7623AI SoCs. + The MT7988 SoC comes with a built-in switch similar to MT7531 as well as four + Gigabit Ethernet PHYs. The switch registers are directly mapped into the SoC's + memory map rather than using MDIO. The switch got an internally connected 10G + CPU port and 4 user ports connected to the built-in Gigabit Ethernet PHYs. + MT7530 in MT7620AN, MT7620DA, MT7620DAN and MT7620NN SoCs has got 10/100 PHYs and the switch registers are directly mapped into SoC's memory map rather than - using MDIO. The DSA driver currently doesn't support this. + using MDIO. The DSA driver currently doesn't support MT7620 variants. There is only the standalone version of MT7531. @@ -81,6 +88,10 @@ properties: Multi-chip module MT7530 in MT7621AT, MT7621DAT and MT7621ST SoCs const: mediatek,mt7621 + - description: + Built-in switch of the MT7988 SoC + const: mediatek,mt7988-switch + reg: maxItems: 1 @@ -93,7 +104,7 @@ properties: gpio-controller: type: boolean - description: + description: | If defined, LED controller of the MT7530 switch will run on GPIO mode. There are 15 controllable pins. @@ -112,7 +123,7 @@ properties: maxItems: 1 io-supply: - description: + description: | Phandle to the regulator node necessary for the I/O power. See Documentation/devicetree/bindings/regulator/mt6323-regulator.txt for details for the regulator setup on these boards. @@ -124,7 +135,7 @@ properties: switch is a part of the multi-chip module. reset-gpios: - description: + description: | GPIO to reset the switch. Use this if mediatek,mcm is not used. This property is optional because some boards share the reset line with other components which makes it impossible to probe the switch if the @@ -268,6 +279,17 @@ allOf: required: - mediatek,mcm + - if: + properties: + compatible: + const: mediatek,mt7988-switch + then: + $ref: "#/$defs/mt7530-dsa-port" + properties: + gpio-controller: false + mediatek,mcm: false + reset-names: false + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml index a4b53434c85c..e51be1ac0362 100644 --- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml @@ -67,7 +67,7 @@ examples: }; }; - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml index 389892592aac..df64eebebe18 100644 --- a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml @@ -18,6 +18,8 @@ description: PHY it is connected to. In this config, an internal mdio-bus is registered and the MDIO master is used for communication. Mixed external and internal mdio-bus configurations are not supported by the hardware. + Each phy has at most 3 LEDs connected and can be declared + using the standard LEDs structure. properties: compatible: @@ -66,7 +68,7 @@ properties: With the legacy mapping the reg corresponding to the internal mdio is the switch reg with an offset of -1. -$ref: "dsa.yaml#" +$ref: dsa.yaml# patternProperties: "^(ethernet-)?ports$": @@ -117,6 +119,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> mdio { #address-cells = <1>; @@ -226,6 +229,25 @@ examples: label = "lan1"; phy-mode = "internal"; phy-handle = <&internal_phy_port1>; + + leds { + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_WHITE>; + function = LED_FUNCTION_LAN; + default-state = "keep"; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_AMBER>; + function = LED_FUNCTION_LAN; + default-state = "keep"; + }; + }; }; port@2 { diff --git a/Documentation/devicetree/bindings/net/engleder,tsnep.yaml b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml index 4116667133ce..82a5d7927ca4 100644 --- a/Documentation/devicetree/bindings/net/engleder,tsnep.yaml +++ b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml @@ -62,7 +62,7 @@ properties: mdio: type: object - $ref: "mdio.yaml#" + $ref: mdio.yaml# description: optional node for embedded MDIO controller required: diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index 00be387984ac..6b0d359367da 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -205,7 +205,7 @@ properties: duplex is assumed. pause: - $ref: /schemas/types.yaml#definitions/flag + $ref: /schemas/types.yaml#/definitions/flag description: Indicates that pause should be enabled. @@ -222,6 +222,41 @@ properties: required: - speed + leds: + description: + Describes the LEDs associated by Ethernet Controller. + These LEDs are not integrated in the PHY and PHY doesn't have any + control on them. Ethernet Controller regs are used to control + these defined LEDs. + + type: object + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + patternProperties: + '^led@[a-f0-9]+$': + $ref: /schemas/leds/common.yaml# + + properties: + reg: + maxItems: 1 + description: + This define the LED index in the PHY or the MAC. It's really + driver dependent and required for ports that define multiple + LED for the same port. + + required: + - reg + + unevaluatedProperties: false + + additionalProperties: false + dependencies: pcs-handle-names: [pcs-handle] diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 1327b81f15a2..4f574532ee13 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -83,7 +83,7 @@ properties: 0: Disable 2.4 Vpp operating mode. 1: Request 2.4 Vpp operating mode from link partner. Absence of this property will leave configuration to default values. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] broken-turn-around: @@ -197,6 +197,35 @@ properties: PHY's that have configurable TX internal delays. If this property is present then the PHY applies the TX delay. + leds: + type: object + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + patternProperties: + '^led@[a-f0-9]+$': + $ref: /schemas/leds/common.yaml# + + properties: + reg: + maxItems: 1 + description: + This define the LED index in the PHY or the MAC. It's really + driver dependent and required for ports that define multiple + LED for the same port. + + required: + - reg + + unevaluatedProperties: false + + additionalProperties: false + required: - reg @@ -204,6 +233,8 @@ additionalProperties: true examples: - | + #include <dt-bindings/leds/common.h> + ethernet { #address-cells = <1>; #size-cells = <0>; @@ -219,5 +250,17 @@ examples: reset-gpios = <&gpio1 4 1>; reset-assert-us = <1000>; reset-deassert-us = <2000>; + + leds { + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_WHITE>; + function = LED_FUNCTION_LAN; + default-state = "keep"; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/net/ethernet-switch.yaml b/Documentation/devicetree/bindings/net/ethernet-switch.yaml index a04f8ef744aa..f1b9075dc7fb 100644 --- a/Documentation/devicetree/bindings/net/ethernet-switch.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-switch.yaml @@ -40,6 +40,10 @@ patternProperties: type: object description: Ethernet switch ports + required: + - "#address-cells" + - "#size-cells" + oneOf: - required: - ports @@ -51,7 +55,7 @@ additionalProperties: true $defs: base: description: An ethernet switch without any extra port properties - $ref: '#/' + $ref: '#' patternProperties: "^(ethernet-)?port@[0-9]+$": diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index e6f2045f05de..b494e009326e 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -144,6 +144,9 @@ properties: description: Regulator that powers the Ethernet PHY. + power-domains: + maxItems: 1 + fsl,num-tx-queues: $ref: /schemas/types.yaml#/definitions/uint32 description: diff --git a/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml index 6e0763898d3a..a1b71b35319e 100644 --- a/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml +++ b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml @@ -14,7 +14,7 @@ description: located under the 'dpmacs' node for the fsl-mc bus DTS node. allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml b/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml index 8b9b3f915d92..f92730b1d2fa 100644 --- a/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml +++ b/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml @@ -2,8 +2,8 @@ # Copyright 2018 Linaro Ltd. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/intel,ixp46x-ptp-timer.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/intel,ixp46x-ptp-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel IXP46x PTP Timer (TSYNC) diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml index 4e1b79818aff..4fdc5328826c 100644 --- a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml +++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml @@ -2,13 +2,13 @@ # Copyright 2018 Linaro Ltd. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/intel,ixp4xx-ethernet.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/intel,ixp4xx-ethernet.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel IXP4xx ethernet allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# maintainers: - Linus Walleij <linus.walleij@linaro.org> @@ -28,7 +28,7 @@ properties: description: Ethernet MMIO address range queue-rx: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to the RX queue node @@ -36,7 +36,7 @@ properties: description: phandle to the RX queue on the NPE queue-txready: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to the TX READY queue node @@ -48,7 +48,7 @@ properties: phy-handle: true intel,npe-handle: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to the NPE this ethernet instance is using diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml index e6329febb60c..7a405e9b37b2 100644 --- a/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml +++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml @@ -2,8 +2,8 @@ # Copyright 2021 Linaro Ltd. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/intel,ixp4xx-hss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/intel,ixp4xx-hss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel IXP4xx V.35 WAN High Speed Serial Link (HSS) @@ -24,7 +24,7 @@ properties: description: The HSS instance intel,npe-handle: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: items: - description: phandle to the NPE this HSS instance is using @@ -33,7 +33,7 @@ properties: and the instance to use in the second cell intel,queue-chl-rxtrig: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to the RX trigger queue on the NPE @@ -41,7 +41,7 @@ properties: description: phandle to the RX trigger queue on the NPE intel,queue-chl-txready: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to the TX ready queue on the NPE @@ -49,7 +49,7 @@ properties: description: phandle to the TX ready queue on the NPE intel,queue-pkt-rx: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to the RX queue on the NPE @@ -57,7 +57,7 @@ properties: description: phandle to the packet RX queue on the NPE intel,queue-pkt-tx: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 4 items: items: @@ -66,7 +66,7 @@ properties: description: phandle to the packet TX0, TX1, TX2 and TX3 queues on the NPE intel,queue-pkt-rxfree: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 4 items: items: @@ -76,7 +76,7 @@ properties: RXFREE3 queues on the NPE intel,queue-pkt-txdone: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to the TXDONE queue on the NPE diff --git a/Documentation/devicetree/bindings/net/marvell,mvusb.yaml b/Documentation/devicetree/bindings/net/marvell,mvusb.yaml index 8e288ab38fd7..3a3325168048 100644 --- a/Documentation/devicetree/bindings/net/marvell,mvusb.yaml +++ b/Documentation/devicetree/bindings/net/marvell,mvusb.yaml @@ -20,7 +20,7 @@ description: |+ definition. allOf: - - $ref: "mdio.yaml#" + - $ref: mdio.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/marvell-bluetooth.yaml b/Documentation/devicetree/bindings/net/marvell-bluetooth.yaml index 309ef21a1e37..188a42ca6ceb 100644 --- a/Documentation/devicetree/bindings/net/marvell-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/marvell-bluetooth.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/marvell-bluetooth.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/marvell-bluetooth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Marvell Bluetooth chips @@ -15,11 +15,29 @@ maintainers: properties: compatible: - const: mrvl,88w8897 + enum: + - mrvl,88w8897 + - mrvl,88w8997 + + max-speed: + description: see Documentation/devicetree/bindings/serial/serial.yaml required: - compatible +allOf: + - if: + properties: + compatible: + contains: + const: mrvl,88w8997 + then: + properties: + max-speed: true + else: + properties: + max-speed: false + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.yaml b/Documentation/devicetree/bindings/net/mdio-gpio.yaml index 1d83b8dcce2c..eb4171a1940e 100644 --- a/Documentation/devicetree/bindings/net/mdio-gpio.yaml +++ b/Documentation/devicetree/bindings/net/mdio-gpio.yaml @@ -12,7 +12,7 @@ maintainers: - Russell King <linux@armlinux.org.uk> allOf: - - $ref: "mdio.yaml#" + - $ref: mdio.yaml# properties: compatible: @@ -33,8 +33,8 @@ properties: - description: MDIO - description: MDO -#Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases" -#node. +# Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases" +# node. additionalProperties: type: object diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml index 7ef696204c5a..acb2b2ac4fe1 100644 --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml @@ -21,6 +21,7 @@ properties: - mediatek,mt7623-eth - mediatek,mt7622-eth - mediatek,mt7629-eth + - mediatek,mt7981-eth - mediatek,mt7986-eth - ralink,rt5350-eth @@ -78,6 +79,11 @@ properties: description: List of phandles to wireless ethernet dispatch nodes. + mediatek,wed-pcie: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the mediatek wed-pcie controller. + dma-coherent: true mdio-bus: @@ -91,7 +97,7 @@ properties: const: 0 allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# - if: properties: compatible: @@ -123,6 +129,8 @@ allOf: mediatek,wed: false + mediatek,wed-pcie: false + - if: properties: compatible: @@ -160,6 +168,8 @@ allOf: description: Phandle to the mediatek pcie-mirror controller. + mediatek,wed-pcie: false + - if: properties: compatible: @@ -206,6 +216,44 @@ allOf: mediatek,wed: false + mediatek,wed-pcie: false + + - if: + properties: + compatible: + contains: + const: mediatek,mt7981-eth + then: + properties: + interrupts: + minItems: 4 + + clocks: + minItems: 15 + maxItems: 15 + + clock-names: + items: + - const: fe + - const: gp2 + - const: gp1 + - const: wocpu0 + - const: sgmii_ck + - const: sgmii_tx250m + - const: sgmii_rx250m + - const: sgmii_cdr_ref + - const: sgmii_cdr_fb + - const: sgmii2_tx250m + - const: sgmii2_rx250m + - const: sgmii2_cdr_ref + - const: sgmii2_cdr_fb + - const: netsys0 + - const: netsys1 + + mediatek,sgmiisys: + minItems: 2 + maxItems: 2 + - if: properties: compatible: @@ -242,11 +290,6 @@ allOf: minItems: 2 maxItems: 2 - mediatek,wed-pcie: - $ref: /schemas/types.yaml#/definitions/phandle - description: - Phandle to the mediatek wed-pcie controller. - patternProperties: "^mac@[0-1]$": type: object diff --git a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml index 64c893c98d80..2e889f9a563e 100644 --- a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml +++ b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml @@ -15,7 +15,7 @@ description: modes with flow-control as well as CRC offloading and VLAN tags. allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml index dc116f14750e..306ef9ecf2b9 100644 --- a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml @@ -73,7 +73,7 @@ properties: "^port@[0-9a-f]+$": type: object - $ref: "/schemas/net/ethernet-controller.yaml#" + $ref: /schemas/net/ethernet-controller.yaml# unevaluatedProperties: false properties: diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml index 57ffeb8fc876..fcafef8d5a33 100644 --- a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml @@ -99,7 +99,7 @@ properties: microchip,bandwidth: description: Specifies bandwidth in Mbit/s allocated to the port. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 maximum: 25000 microchip,sd-sgpio: @@ -107,7 +107,7 @@ properties: Index of the ports Signal Detect SGPIO in the set of 384 SGPIOs This is optional, and only needed if the default used index is is not correct. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 383 diff --git a/Documentation/devicetree/bindings/net/mscc,miim.yaml b/Documentation/devicetree/bindings/net/mscc,miim.yaml index 2c451cfa4e0b..5b292e7c9e46 100644 --- a/Documentation/devicetree/bindings/net/mscc,miim.yaml +++ b/Documentation/devicetree/bindings/net/mscc,miim.yaml @@ -10,7 +10,7 @@ maintainers: - Alexandre Belloni <alexandre.belloni@bootlin.com> allOf: - - $ref: "mdio.yaml#" + - $ref: mdio.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml index 308485a8ee6c..8e9a95f24c80 100644 --- a/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml +++ b/Documentation/devicetree/bindings/net/nfc/marvell,nci.yaml @@ -28,7 +28,7 @@ properties: maxItems: 1 reset-n-io: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 description: | Output GPIO pin used to reset the chip (active low) diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml index 0509e0166345..07c67c1e985f 100644 --- a/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml +++ b/Documentation/devicetree/bindings/net/nfc/nxp,pn532.yaml @@ -31,7 +31,7 @@ required: - compatible dependencies: - interrupts: [ 'reg' ] + interrupts: [ reg ] additionalProperties: false diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml index 41c9760227cd..12baee45752c 100644 --- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml +++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml @@ -69,7 +69,7 @@ examples: #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> - i2c4 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml new file mode 100644 index 000000000000..66a95191bd77 --- /dev/null +++ b/Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/pcs/mediatek,sgmiisys.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek SGMIISYS Controller + +maintainers: + - Matthias Brugger <matthias.bgg@gmail.com> + +description: + The MediaTek SGMIISYS controller provides a SGMII PCS and some clocks + to the ethernet subsystem to which it is attached. + +properties: + compatible: + items: + - enum: + - mediatek,mt7622-sgmiisys + - mediatek,mt7629-sgmiisys + - mediatek,mt7981-sgmiisys_0 + - mediatek,mt7981-sgmiisys_1 + - mediatek,mt7986-sgmiisys_0 + - mediatek,mt7986-sgmiisys_1 + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + mediatek,pnswap: + description: Invert polarity of the SGMII data lanes + type: boolean + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + sgmiisys: syscon@1b128000 { + compatible = "mediatek,mt7622-sgmiisys", "syscon"; + reg = <0 0x1b128000 0 0x1000>; + #clock-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/pse-pd/podl-pse-regulator.yaml b/Documentation/devicetree/bindings/net/pse-pd/podl-pse-regulator.yaml index c6b1c188abf7..94a527e6aa1b 100644 --- a/Documentation/devicetree/bindings/net/pse-pd/podl-pse-regulator.yaml +++ b/Documentation/devicetree/bindings/net/pse-pd/podl-pse-regulator.yaml @@ -13,7 +13,7 @@ description: Regulator based PoDL PSE controller. The device must be referenced by the PHY node to control power injection to the Ethernet cable. allOf: - - $ref: "pse-controller.yaml#" + - $ref: pse-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.txt b/Documentation/devicetree/bindings/net/qcom,ethqos.txt deleted file mode 100644 index 1f5746849a71..000000000000 --- a/Documentation/devicetree/bindings/net/qcom,ethqos.txt +++ /dev/null @@ -1,66 +0,0 @@ -Qualcomm Ethernet ETHQOS device - -This documents dwmmac based ethernet device which supports Gigabit -ethernet for version v2.3.0 onwards. - -This device has following properties: - -Required properties: - -- compatible: Should be one of: - "qcom,qcs404-ethqos" - "qcom,sm8150-ethqos" - -- reg: Address and length of the register set for the device - -- reg-names: Should contain register names "stmmaceth", "rgmii" - -- clocks: Should contain phandle to clocks - -- clock-names: Should contain clock names "stmmaceth", "pclk", - "ptp_ref", "rgmii" - -- interrupts: Should contain phandle to interrupts - -- interrupt-names: Should contain interrupt names "macirq", "eth_lpi" - -Rest of the properties are defined in stmmac.txt file in same directory - - -Example: - -ethernet: ethernet@7a80000 { - compatible = "qcom,qcs404-ethqos"; - reg = <0x07a80000 0x10000>, - <0x07a96000 0x100>; - reg-names = "stmmaceth", "rgmii"; - clock-names = "stmmaceth", "pclk", "ptp_ref", "rgmii"; - clocks = <&gcc GCC_ETH_AXI_CLK>, - <&gcc GCC_ETH_SLAVE_AHB_CLK>, - <&gcc GCC_ETH_PTP_CLK>, - <&gcc GCC_ETH_RGMII_CLK>; - interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "macirq", "eth_lpi"; - snps,reset-gpio = <&tlmm 60 GPIO_ACTIVE_LOW>; - snps,reset-active-low; - - snps,txpbl = <8>; - snps,rxpbl = <2>; - snps,aal; - snps,tso; - - phy-handle = <&phy1>; - phy-mode = "rgmii"; - - mdio { - #address-cells = <0x1>; - #size-cells = <0x0>; - compatible = "snps,dwmac-mdio"; - phy1: phy@4 { - device_type = "ethernet-phy"; - reg = <0x4>; - }; - }; - -}; diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml new file mode 100644 index 000000000000..60a38044fb19 --- /dev/null +++ b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml @@ -0,0 +1,111 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/qcom,ethqos.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Ethernet ETHQOS device + +maintainers: + - Bhupesh Sharma <bhupesh.sharma@linaro.org> + +description: + dwmmac based Qualcomm ethernet devices which support Gigabit + ethernet (version v2.3.0 and onwards). + +allOf: + - $ref: snps,dwmac.yaml# + +properties: + compatible: + enum: + - qcom,qcs404-ethqos + - qcom,sc8280xp-ethqos + - qcom,sm8150-ethqos + + reg: + maxItems: 2 + + reg-names: + items: + - const: stmmaceth + - const: rgmii + + interrupts: + items: + - description: Combined signal for various interrupt events + - description: The interrupt that occurs when Rx exits the LPI state + + interrupt-names: + items: + - const: macirq + - const: eth_lpi + + clocks: + maxItems: 4 + + clock-names: + items: + - const: stmmaceth + - const: pclk + - const: ptp_ref + - const: rgmii + + iommus: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - reg-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,gcc-qcs404.h> + #include <dt-bindings/gpio/gpio.h> + + ethernet: ethernet@7a80000 { + compatible = "qcom,qcs404-ethqos"; + reg = <0x07a80000 0x10000>, + <0x07a96000 0x100>; + reg-names = "stmmaceth", "rgmii"; + clock-names = "stmmaceth", "pclk", "ptp_ref", "rgmii"; + clocks = <&gcc GCC_ETH_AXI_CLK>, + <&gcc GCC_ETH_SLAVE_AHB_CLK>, + <&gcc GCC_ETH_PTP_CLK>, + <&gcc GCC_ETH_RGMII_CLK>; + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq", "eth_lpi"; + + rx-fifo-depth = <4096>; + tx-fifo-depth = <4096>; + + snps,tso; + snps,reset-gpio = <&tlmm 60 GPIO_ACTIVE_LOW>; + snps,reset-active-low; + snps,reset-delays-us = <0 10000 10000>; + + pinctrl-names = "default"; + pinctrl-0 = <ðernet_defaults>; + + phy-handle = <&phy1>; + phy-mode = "rgmii"; + mdio { + #address-cells = <0x1>; + #size-cells = <0x0>; + + compatible = "snps,dwmac-mdio"; + phy1: phy@4 { + compatible = "ethernet-phy-ieee802.3-c22"; + device_type = "ethernet-phy"; + reg = <0x4>; + + #phy-cells = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 4aeda379726f..2d5e4ffb2f9e 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -49,6 +49,7 @@ properties: - qcom,sc7280-ipa - qcom,sdm845-ipa - qcom,sdx55-ipa + - qcom,sdx65-ipa - qcom,sm6350-ipa - qcom,sm8350-ipa diff --git a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml index 7631ecc8fd01..3407e909e8a7 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml @@ -51,7 +51,7 @@ required: - "#size-cells" allOf: - - $ref: "mdio.yaml#" + - $ref: mdio.yaml# - if: properties: diff --git a/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml index d7748dd33199..164704338ef0 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml @@ -14,7 +14,7 @@ description: used to communicate with the gmac phy connected. allOf: - - $ref: "mdio.yaml#" + - $ref: mdio.yaml# properties: compatible: @@ -53,7 +53,9 @@ examples: reg = <0x10>; ports { - /* ... */ + #address-cells = <1>; + #size-cells = <0>; + /* ... */ }; }; }; diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml index 143b5667abad..8cc2b9924680 100644 --- a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml @@ -4,24 +4,30 @@ $id: http://devicetree.org/schemas/net/realtek-bluetooth.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: RTL8723BS/RTL8723CS/RTL8822CS Bluetooth +title: RTL8723BS/RTL8723CS/RTL8821CS/RTL8822CS Bluetooth maintainers: - Vasily Khoruzhick <anarsoul@gmail.com> - Alistair Francis <alistair@alistair23.me> description: - RTL8723CS/RTL8723CS/RTL8822CS is WiFi + BT chip. WiFi part is connected over - SDIO, while BT is connected over serial. It speaks H5 protocol with few - extra commands to upload firmware and change module speed. + RTL8723CS/RTL8723CS/RTL8821CS/RTL8822CS is a WiFi + BT chip. WiFi part + is connected over SDIO, while BT is connected over serial. It speaks + H5 protocol with few extra commands to upload firmware and change + module speed. properties: compatible: - enum: - - realtek,rtl8723bs-bt - - realtek,rtl8723cs-bt - - realtek,rtl8723ds-bt - - realtek,rtl8822cs-bt + oneOf: + - enum: + - realtek,rtl8723bs-bt + - realtek,rtl8723cs-bt + - realtek,rtl8723ds-bt + - realtek,rtl8822cs-bt + - items: + - enum: + - realtek,rtl8821cs-bt + - const: realtek,rtl8822cs-bt device-wake-gpios: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/rockchip,emac.yaml b/Documentation/devicetree/bindings/net/rockchip,emac.yaml index a6d4f14df442..364028b3bba4 100644 --- a/Documentation/devicetree/bindings/net/rockchip,emac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip,emac.yaml @@ -61,7 +61,7 @@ required: - mdio allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml index 04936632fcbb..2a21bbe02892 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/rockchip-dwmac.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/rockchip-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Rockchip 10/100/1000 Ethernet driver(GMAC) diff --git a/Documentation/devicetree/bindings/net/sff,sfp.yaml b/Documentation/devicetree/bindings/net/sff,sfp.yaml index 231c4d75e4b1..973e478a399d 100644 --- a/Documentation/devicetree/bindings/net/sff,sfp.yaml +++ b/Documentation/devicetree/bindings/net/sff,sfp.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/sff,sfp.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/sff,sfp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP) Transceiver diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 16b7d2904696..363b3e3ea3a6 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -30,6 +30,7 @@ select: - snps,dwmac-4.10a - snps,dwmac-4.20a - snps,dwmac-5.10a + - snps,dwmac-5.20 - snps,dwxgmac - snps,dwxgmac-2.10 @@ -65,6 +66,9 @@ properties: - ingenic,x2000-mac - loongson,ls2k-dwmac - loongson,ls7a-dwmac + - qcom,qcs404-ethqos + - qcom,sc8280xp-ethqos + - qcom,sm8150-ethqos - renesas,r9a06g032-gmac - renesas,rzn1-gmac - rockchip,px30-gmac @@ -87,8 +91,10 @@ properties: - snps,dwmac-4.10a - snps,dwmac-4.20a - snps,dwmac-5.10a + - snps,dwmac-5.20 - snps,dwxgmac - snps,dwxgmac-2.10 + - starfive,jh7110-dwmac reg: minItems: 1 @@ -105,7 +111,7 @@ properties: minItems: 1 items: - const: macirq - - const: eth_wake_irq + - enum: [eth_wake_irq, eth_lpi] - const: eth_lpi clocks: @@ -131,12 +137,16 @@ properties: - ptp_ref resets: - maxItems: 1 - description: - MAC Reset signal. + minItems: 1 + items: + - description: GMAC stmmaceth reset + - description: AHB reset reset-names: - const: stmmaceth + minItems: 1 + items: + - const: stmmaceth + - const: ahb power-domains: maxItems: 1 @@ -555,7 +565,7 @@ dependencies: snps,reset-delays-us: ["snps,reset-gpio"] allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# - if: properties: compatible: @@ -572,9 +582,11 @@ allOf: - ingenic,x1600-mac - ingenic,x1830-mac - ingenic,x2000-mac + - qcom,sc8280xp-ethqos - snps,dwmac-3.50a - snps,dwmac-4.10a - snps,dwmac-4.20a + - snps,dwmac-5.20 - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac @@ -625,10 +637,14 @@ allOf: - ingenic,x1600-mac - ingenic,x1830-mac - ingenic,x2000-mac + - qcom,qcs404-ethqos + - qcom,sc8280xp-ethqos + - qcom,sm8150-ethqos - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a - snps,dwmac-5.10a + - snps,dwmac-5.20 - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml new file mode 100644 index 000000000000..5e7cfbbebce6 --- /dev/null +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 StarFive Technology Co., Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/starfive,jh7110-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 DWMAC glue layer + +maintainers: + - Emil Renner Berthing <kernel@esmil.dk> + - Samin Guo <samin.guo@starfivetech.com> + +select: + properties: + compatible: + contains: + enum: + - starfive,jh7110-dwmac + required: + - compatible + +properties: + compatible: + items: + - enum: + - starfive,jh7110-dwmac + - const: snps,dwmac-5.20 + + reg: + maxItems: 1 + + clocks: + items: + - description: GMAC main clock + - description: GMAC AHB clock + - description: PTP clock + - description: TX clock + - description: GTX clock + + clock-names: + items: + - const: stmmaceth + - const: pclk + - const: ptp_ref + - const: tx + - const: gtx + + interrupts: + minItems: 3 + maxItems: 3 + + interrupt-names: + minItems: 3 + maxItems: 3 + + resets: + items: + - description: MAC Reset signal. + - description: AHB Reset signal. + + reset-names: + items: + - const: stmmaceth + - const: ahb + + starfive,tx-use-rgmii-clk: + description: + Tx clock is provided by external rgmii clock. + type: boolean + + starfive,syscon: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to syscon that configures phy mode + - description: Offset of phy mode selection + - description: Shift of phy mode selection + description: + A phandle to syscon with two arguments that configure phy mode. + The argument one is the offset of phy mode selection, the + argument two is the shift of phy mode selection. + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - interrupt-names + - resets + - reset-names + +allOf: + - $ref: snps,dwmac.yaml# + +unevaluatedProperties: false + +examples: + - | + ethernet@16030000 { + compatible = "starfive,jh7110-dwmac", "snps,dwmac-5.20"; + reg = <0x16030000 0x10000>; + clocks = <&clk 3>, <&clk 2>, <&clk 109>, + <&clk 6>, <&clk 111>; + clock-names = "stmmaceth", "pclk", "ptp_ref", + "tx", "gtx"; + resets = <&rst 1>, <&rst 2>; + reset-names = "stmmaceth", "ahb"; + interrupts = <7>, <6>, <5>; + interrupt-names = "macirq", "eth_wake_irq", "eth_lpi"; + phy-mode = "rgmii-id"; + snps,multicast-filter-bins = <64>; + snps,perfect-filter-entries = <8>; + rx-fifo-depth = <2048>; + tx-fifo-depth = <2048>; + snps,fixed-burst; + snps,no-pbl-x8; + snps,tso; + snps,force_thresh_dma_mode; + snps,axi-config = <&stmmac_axi_setup>; + snps,en-tx-lpi-clockgating; + snps,txpbl = <16>; + snps,rxpbl = <16>; + starfive,syscon = <&aon_syscon 0xc 0x12>; + phy-handle = <&phy0>; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,dwmac-mdio"; + + phy0: ethernet-phy@0 { + reg = <0>; + }; + }; + + stmmac_axi_setup: stmmac-axi-config { + snps,lpi_en; + snps,wr_osr_lmt = <4>; + snps,rd_osr_lmt = <4>; + snps,blen = <256 128 64 32 0 0 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/sti-dwmac.txt b/Documentation/devicetree/bindings/net/sti-dwmac.txt index 062c5174add3..42cd075456ab 100644 --- a/Documentation/devicetree/bindings/net/sti-dwmac.txt +++ b/Documentation/devicetree/bindings/net/sti-dwmac.txt @@ -7,8 +7,7 @@ and what is needed on STi platforms to program the stmmac glue logic. The device node has following properties. Required properties: - - compatible : Can be "st,stih415-dwmac", "st,stih416-dwmac", - "st,stih407-dwmac", "st,stid127-dwmac". + - compatible : "st,stih407-dwmac" - st,syscon : Should be phandle/offset pair. The phandle to the syscon node which encompases the glue register, and the offset of the control register. - st,gmac_en: this is to enable the gmac into a dedicated sysctl control diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index 5c93167b3b41..fc8c96b08d7d 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/stm32-dwmac.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/stm32-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 / MCU DWMAC glue layer controller @@ -26,7 +26,7 @@ select: - compatible allOf: - - $ref: "snps,dwmac.yaml#" + - $ref: snps,dwmac.yaml# properties: compatible: @@ -73,7 +73,7 @@ properties: - ptp_ref st,syscon: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to the syscon node which encompases the glue register diff --git a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml index e36c7817be69..b04ac4966608 100644 --- a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml +++ b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml @@ -62,10 +62,10 @@ properties: interrupt-names: items: - - const: "rx_thresh" - - const: "rx" - - const: "tx" - - const: "misc" + - const: rx_thresh + - const: rx + - const: tx + - const: misc pinctrl-names: true @@ -154,7 +154,7 @@ patternProperties: type: object description: CPSW MDIO bus. - $ref: "ti,davinci-mdio.yaml#" + $ref: ti,davinci-mdio.yaml# required: diff --git a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml index a339202c5e8e..53604fab0b73 100644 --- a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml +++ b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml @@ -13,7 +13,7 @@ description: TI SoC Davinci/Keystone2 MDIO Controller allOf: - - $ref: "mdio.yaml#" + - $ref: mdio.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/net/ti,dp83822.yaml b/Documentation/devicetree/bindings/net/ti,dp83822.yaml index f2489a9c852f..db74474207ed 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83822.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2020 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/ti,dp83822.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/ti,dp83822.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI DP83822 ethernet PHY @@ -21,7 +21,7 @@ description: | http://www.ti.com/lit/ds/symlink/dp83822i.pdf allOf: - - $ref: "ethernet-phy.yaml#" + - $ref: ethernet-phy.yaml# properties: reg: diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml index b8c0e4b5b494..4bc1f98fd9fe 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml @@ -2,13 +2,13 @@ # Copyright (C) 2019 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/ti,dp83867.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/ti,dp83867.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI DP83867 ethernet PHY allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: ethernet-controller.yaml# maintainers: - Andrew Davis <afd@ti.com> diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml index b04ff0014a59..fb6725df4668 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml @@ -2,13 +2,13 @@ # Copyright (C) 2019 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/ti,dp83869.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/ti,dp83869.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI DP83869 ethernet PHY allOf: - - $ref: "ethernet-phy.yaml#" + - $ref: ethernet-phy.yaml# maintainers: - Andrew Davis <afd@ti.com> diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml index 900063411a20..395a4650e285 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml @@ -54,11 +54,12 @@ properties: compatible: enum: + - ti,am642-cpsw-nuss - ti,am654-cpsw-nuss - ti,j7200-cpswxg-nuss - ti,j721e-cpsw-nuss - ti,j721e-cpswxg-nuss - - ti,am642-cpsw-nuss + - ti,j784s4-cpswxg-nuss reg: maxItems: 1 @@ -126,8 +127,18 @@ properties: description: CPSW port number phys: - maxItems: 1 - description: phandle on phy-gmii-sel PHY + minItems: 1 + items: + - description: CPSW MAC's PHY. + - description: Serdes PHY. Serdes PHY is required only if + the Serdes has to be configured in the + Single-Link configuration. + + phy-names: + minItems: 1 + items: + - const: mac + - const: serdes label: description: label associated with this port @@ -187,7 +198,9 @@ allOf: properties: compatible: contains: - const: ti,j721e-cpswxg-nuss + enum: + - ti,j721e-cpswxg-nuss + - ti,j784s4-cpswxg-nuss then: properties: ethernet-ports: @@ -205,8 +218,9 @@ allOf: compatible: contains: enum: - - ti,j721e-cpswxg-nuss - ti,j7200-cpswxg-nuss + - ti,j721e-cpswxg-nuss + - ti,j784s4-cpswxg-nuss then: properties: ethernet-ports: @@ -222,7 +236,6 @@ additionalProperties: false examples: - | - #include <dt-bindings/pinctrl/k3.h> #include <dt-bindings/soc/ti,sci_pm_domain.h> #include <dt-bindings/net/ti-dp83867.h> #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml index 0988ed8d1c12..474fa8bcf302 100644 --- a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/toshiba,visconti-dwmac.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/toshiba,visconti-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Toshiba Visconti DWMAC Ethernet controller diff --git a/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml b/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml index 6a71f694cb55..4158673f723c 100644 --- a/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml +++ b/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/net/vertexcom-mse102x.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/net/vertexcom-mse102x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: The Vertexcom MSE102x (SPI) @@ -55,7 +55,7 @@ additionalProperties: false examples: - | #include <dt-bindings/interrupt-controller/irq.h> - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml index 7d526ff53fb7..67b63f119f64 100644 --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml @@ -111,6 +111,11 @@ properties: $ref: /schemas/leds/common.yaml# additionalProperties: false properties: + led-active-low: + description: + LED is enabled with ground signal. + type: boolean + led-sources: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt deleted file mode 100644 index b61c2d5a0ff7..000000000000 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt +++ /dev/null @@ -1,215 +0,0 @@ -* Qualcomm Atheros ath10k wireless devices - -Required properties: -- compatible: Should be one of the following: - * "qcom,ath10k" - * "qcom,ipq4019-wifi" - * "qcom,wcn3990-wifi" - -PCI based devices uses compatible string "qcom,ath10k" and takes calibration -data along with board specific data via "qcom,ath10k-calibration-data". -Rest of the properties are not applicable for PCI based devices. - -AHB based devices (i.e. ipq4019) uses compatible string "qcom,ipq4019-wifi" -and also uses most of the properties defined in this doc (except -"qcom,ath10k-calibration-data"). It uses "qcom,ath10k-pre-calibration-data" -to carry pre calibration data. - -In general, entry "qcom,ath10k-pre-calibration-data" and -"qcom,ath10k-calibration-data" conflict with each other and only one -can be provided per device. - -SNOC based devices (i.e. wcn3990) uses compatible string "qcom,wcn3990-wifi". - -- reg: Address and length of the register set for the device. -- reg-names: Must include the list of following reg names, - "membase" -- interrupts: reference to the list of 17 interrupt numbers for "qcom,ipq4019-wifi" - compatible target. - reference to the list of 12 interrupt numbers for "qcom,wcn3990-wifi" - compatible target. - Must contain interrupt-names property per entry for - "qcom,ath10k", "qcom,ipq4019-wifi" compatible targets. - -- interrupt-names: Must include the entries for MSI interrupt - names ("msi0" to "msi15") and legacy interrupt - name ("legacy") for "qcom,ath10k", "qcom,ipq4019-wifi" - compatible targets. - -Optional properties: -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reseti.txt for details. -- reset-names: Must include the list of following reset names, - "wifi_cpu_init" - "wifi_radio_srif" - "wifi_radio_warm" - "wifi_radio_cold" - "wifi_core_warm" - "wifi_core_cold" -- clocks: List of clock specifiers, must contain an entry for each required - entry in clock-names. -- clock-names: Should contain the clock names "wifi_wcss_cmd", "wifi_wcss_ref", - "wifi_wcss_rtc" for "qcom,ipq4019-wifi" compatible target and - "cxo_ref_clk_pin" and optionally "qdss" for "qcom,wcn3990-wifi" - compatible target. -- qcom,msi_addr: MSI interrupt address. -- qcom,msi_base: Base value to add before writing MSI data into - MSI address register. -- qcom,ath10k-calibration-variant: string to search for in the board-2.bin - variant list with the same bus and device - specific ids -- qcom,ath10k-calibration-data : calibration data + board specific data - as an array, the length can vary between - hw versions. -- qcom,ath10k-pre-calibration-data : pre calibration data as an array, - the length can vary between hw versions. -- <supply-name>-supply: handle to the regulator device tree node - optional "supply-name" are "vdd-0.8-cx-mx", - "vdd-1.8-xo", "vdd-1.3-rfa", "vdd-3.3-ch0", - and "vdd-3.3-ch1". -- memory-region: - Usage: optional - Value type: <phandle> - Definition: reference to the reserved-memory for the msa region - used by the wifi firmware running in Q6. -- iommus: - Usage: optional - Value type: <prop-encoded-array> - Definition: A list of phandle and IOMMU specifier pairs. -- ext-fem-name: - Usage: Optional - Value type: string - Definition: Name of external front end module used. Some valid FEM names - for example: "microsemi-lx5586", "sky85703-11" - and "sky85803" etc. -- qcom,snoc-host-cap-8bit-quirk: - Usage: Optional - Value type: <empty> - Definition: Quirk specifying that the firmware expects the 8bit version - of the host capability QMI request -- qcom,xo-cal-data: xo cal offset to be configured in xo trim register. - -- qcom,msa-fixed-perm: Boolean context flag to disable SCM call for statically - mapped msa region. - -- qcom,coexist-support : should contain eithr "0" or "1" to indicate coex - support by the hardware. -- qcom,coexist-gpio-pin : gpio pin number information to support coex - which will be used by wifi firmware. - -* Subnodes -The ath10k wifi node can contain one optional firmware subnode. -Firmware subnode is needed when the platform does not have TustZone. -The firmware subnode must have: - -- iommus: - Usage: required - Value type: <prop-encoded-array> - Definition: A list of phandle and IOMMU specifier pairs. - - -Example (to supply PCI based wifi block details): - -In this example, the node is defined as child node of the PCI controller. - -pci { - pcie@0 { - reg = <0 0 0 0 0>; - #interrupt-cells = <1>; - #size-cells = <2>; - #address-cells = <3>; - device_type = "pci"; - - wifi@0,0 { - reg = <0 0 0 0 0>; - qcom,ath10k-calibration-data = [ 01 02 03 ... ]; - ext-fem-name = "microsemi-lx5586"; - }; - }; -}; - -Example (to supply ipq4019 SoC wifi block details): - -wifi0: wifi@a000000 { - compatible = "qcom,ipq4019-wifi"; - reg = <0xa000000 0x200000>; - resets = <&gcc WIFI0_CPU_INIT_RESET>, - <&gcc WIFI0_RADIO_SRIF_RESET>, - <&gcc WIFI0_RADIO_WARM_RESET>, - <&gcc WIFI0_RADIO_COLD_RESET>, - <&gcc WIFI0_CORE_WARM_RESET>, - <&gcc WIFI0_CORE_COLD_RESET>; - reset-names = "wifi_cpu_init", - "wifi_radio_srif", - "wifi_radio_warm", - "wifi_radio_cold", - "wifi_core_warm", - "wifi_core_cold"; - clocks = <&gcc GCC_WCSS2G_CLK>, - <&gcc GCC_WCSS2G_REF_CLK>, - <&gcc GCC_WCSS2G_RTC_CLK>; - clock-names = "wifi_wcss_cmd", - "wifi_wcss_ref", - "wifi_wcss_rtc"; - interrupts = <0 0x20 0x1>, - <0 0x21 0x1>, - <0 0x22 0x1>, - <0 0x23 0x1>, - <0 0x24 0x1>, - <0 0x25 0x1>, - <0 0x26 0x1>, - <0 0x27 0x1>, - <0 0x28 0x1>, - <0 0x29 0x1>, - <0 0x2a 0x1>, - <0 0x2b 0x1>, - <0 0x2c 0x1>, - <0 0x2d 0x1>, - <0 0x2e 0x1>, - <0 0x2f 0x1>, - <0 0xa8 0x0>; - interrupt-names = "msi0", "msi1", "msi2", "msi3", - "msi4", "msi5", "msi6", "msi7", - "msi8", "msi9", "msi10", "msi11", - "msi12", "msi13", "msi14", "msi15", - "legacy"; - qcom,msi_addr = <0x0b006040>; - qcom,msi_base = <0x40>; - qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ]; - qcom,coexist-support = <1>; - qcom,coexist-gpio-pin = <0x33>; -}; - -Example (to supply wcn3990 SoC wifi block details): - -wifi@18000000 { - compatible = "qcom,wcn3990-wifi"; - reg = <0x18800000 0x800000>; - reg-names = "membase"; - clocks = <&clock_gcc clk_rf_clk2_pin>; - clock-names = "cxo_ref_clk_pin"; - interrupts = - <GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>; - vdd-0.8-cx-mx-supply = <&pm8998_l5>; - vdd-1.8-xo-supply = <&vreg_l7a_1p8>; - vdd-1.3-rfa-supply = <&vreg_l17a_1p3>; - vdd-3.3-ch0-supply = <&vreg_l25a_3p3>; - vdd-3.3-ch1-supply = <&vreg_l26a_3p3>; - memory-region = <&wifi_msa_mem>; - iommus = <&apps_smmu 0x0040 0x1>; - qcom,msa-fixed-perm; - wifi-firmware { - iommus = <&apps_iommu 0xc22 0x1>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml new file mode 100644 index 000000000000..c85ed330426d --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml @@ -0,0 +1,358 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/wireless/qcom,ath10k.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies ath10k wireless devices + +maintainers: + - Kalle Valo <kvalo@kernel.org> + +description: + Qualcomm Technologies, Inc. IEEE 802.11ac devices. + +properties: + compatible: + enum: + - qcom,ath10k # SDIO-based devices + - qcom,ipq4019-wifi + - qcom,wcn3990-wifi # SNoC-based devices + + reg: + maxItems: 1 + + reg-names: + items: + - const: membase + + interrupts: + minItems: 12 + maxItems: 17 + + interrupt-names: + minItems: 12 + maxItems: 17 + + memory-region: + maxItems: 1 + description: + Reference to the MSA memory region used by the Wi-Fi firmware + running on the Q6 core. + + iommus: + minItems: 1 + maxItems: 2 + + clocks: + minItems: 1 + maxItems: 3 + + clock-names: + minItems: 1 + maxItems: 3 + + resets: + maxItems: 6 + + reset-names: + items: + - const: wifi_cpu_init + - const: wifi_radio_srif + - const: wifi_radio_warm + - const: wifi_radio_cold + - const: wifi_core_warm + - const: wifi_core_cold + + ext-fem-name: + $ref: /schemas/types.yaml#/definitions/string + description: Name of external front end module used. + enum: + - microsemi-lx5586 + - sky85703-11 + - sky85803 + + wifi-firmware: + type: object + additionalProperties: false + description: | + The ath10k Wi-Fi node can contain one optional firmware subnode. + Firmware subnode is needed when the platform does not have Trustzone. + properties: + iommus: + maxItems: 1 + required: + - iommus + + qcom,ath10k-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-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-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,coexist-support: + $ref: /schemas/types.yaml#/definitions/uint8 + enum: [0, 1] + description: + Indicate coex support by the hardware. + + qcom,coexist-gpio-pin: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + COEX GPIO number provided to the Wi-Fi firmware. + + qcom,msa-fixed-perm: + type: boolean + description: + Whether to skip executing an SCM call that reassigns the memory + region ownership. + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: State bits used by the AP to signal the WLAN Q6. + items: + - description: Signal bits used to enable/disable low power mode + on WCN in the case of WoW (Wake on Wireless). + + qcom,smem-state-names: + description: The names of the state bits used for SMP2P output. + items: + - const: wlan-smp2p-out + + qcom,snoc-host-cap-8bit-quirk: + type: boolean + description: + Quirk specifying that the firmware expects the 8bit version + of the host capability QMI request + + qcom,xo-cal-data: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + XO cal offset to be configured in XO trim register. + + vdd-0.8-cx-mx-supply: + description: Main logic power rail + + vdd-1.8-xo-supply: + description: Crystal oscillator supply + + vdd-1.3-rfa-supply: + description: RFA supply + + vdd-3.3-ch0-supply: + description: Primary Wi-Fi antenna supply + + vdd-3.3-ch1-supply: + description: Secondary Wi-Fi antenna supply + +required: + - compatible + - reg + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,ipq4019-wifi + then: + properties: + interrupts: + minItems: 17 + maxItems: 17 + + interrupt-names: + items: + - const: msi0 + - const: msi1 + - const: msi2 + - const: msi3 + - const: msi4 + - const: msi5 + - const: msi6 + - const: msi7 + - const: msi8 + - const: msi9 + - const: msi10 + - const: msi11 + - const: msi12 + - const: msi13 + - const: msi14 + - const: msi15 + - const: legacy + + clocks: + items: + - description: Wi-Fi command clock + - description: Wi-Fi reference clock + - description: Wi-Fi RTC clock + + clock-names: + items: + - const: wifi_wcss_cmd + - const: wifi_wcss_ref + - const: wifi_wcss_rtc + + required: + - clocks + - clock-names + - interrupts + - interrupt-names + - resets + - reset-names + + - if: + properties: + compatible: + contains: + enum: + - qcom,wcn3990-wifi + + then: + properties: + clocks: + minItems: 1 + items: + - description: XO reference clock + - description: Qualcomm Debug Subsystem clock + + clock-names: + minItems: 1 + items: + - const: cxo_ref_clk_pin + - const: qdss + + interrupts: + items: + - description: CE0 + - description: CE1 + - description: CE2 + - description: CE3 + - description: CE4 + - description: CE5 + - description: CE6 + - description: CE7 + - description: CE8 + - description: CE9 + - description: CE10 + - description: CE11 + + interrupt-names: false + + required: + - interrupts + +examples: + # SNoC + - | + #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + wifi@18800000 { + compatible = "qcom,wcn3990-wifi"; + reg = <0x18800000 0x800000>; + reg-names = "membase"; + memory-region = <&wlan_msa_mem>; + clocks = <&rpmcc RPM_SMD_RF_CLK2_PIN>; + clock-names = "cxo_ref_clk_pin"; + interrupts = <GIC_SPI 413 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>; + iommus = <&anoc2_smmu 0x1900>, + <&anoc2_smmu 0x1901>; + qcom,snoc-host-cap-8bit-quirk; + vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>; + vdd-1.8-xo-supply = <&vreg_l7a_1p8>; + vdd-1.3-rfa-supply = <&vreg_l17a_1p3>; + vdd-3.3-ch0-supply = <&vreg_l25a_3p3>; + vdd-3.3-ch1-supply = <&vreg_l23a_3p3>; + + wifi-firmware { + iommus = <&apps_smmu 0x1c02 0x1>; + }; + }; + + # AHB + - | + #include <dt-bindings/clock/qcom,gcc-ipq4019.h> + + wifi@a000000 { + compatible = "qcom,ipq4019-wifi"; + reg = <0xa000000 0x200000>; + resets = <&gcc WIFI0_CPU_INIT_RESET>, + <&gcc WIFI0_RADIO_SRIF_RESET>, + <&gcc WIFI0_RADIO_WARM_RESET>, + <&gcc WIFI0_RADIO_COLD_RESET>, + <&gcc WIFI0_CORE_WARM_RESET>, + <&gcc WIFI0_CORE_COLD_RESET>; + reset-names = "wifi_cpu_init", + "wifi_radio_srif", + "wifi_radio_warm", + "wifi_radio_cold", + "wifi_core_warm", + "wifi_core_cold"; + clocks = <&gcc GCC_WCSS2G_CLK>, + <&gcc GCC_WCSS2G_REF_CLK>, + <&gcc GCC_WCSS2G_RTC_CLK>; + clock-names = "wifi_wcss_cmd", + "wifi_wcss_ref", + "wifi_wcss_rtc"; + interrupts = <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 33 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 34 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 37 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 38 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 39 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 40 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 41 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 42 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 43 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 44 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 45 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 46 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 47 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "msi0", + "msi1", + "msi2", + "msi3", + "msi4", + "msi5", + "msi6", + "msi7", + "msi8", + "msi9", + "msi10", + "msi11", + "msi12", + "msi13", + "msi14", + "msi15", + "legacy"; + }; diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml new file mode 100644 index 000000000000..817f02a8b481 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2023 Linaro Limited +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/wireless/qcom,ath11k-pci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies ath11k wireless devices (PCIe) + +maintainers: + - Kalle Valo <kvalo@kernel.org> + +description: | + Qualcomm Technologies IEEE 802.11ax PCIe devices + +properties: + compatible: + enum: + - pci17cb,1103 # WCN6855 + + reg: + maxItems: 1 + + qcom,ath11k-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 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pcie { + #address-cells = <3>; + #size-cells = <2>; + + pcie@0 { + device_type = "pci"; + reg = <0x0 0x0 0x0 0x0 0x0>; + #address-cells = <3>; + #size-cells = <2>; + ranges; + + bus-range = <0x01 0xff>; + + wifi@0 { + compatible = "pci17cb,1103"; + reg = <0x10000 0x0 0x0 0x0 0x0>; + + qcom,ath11k-calibration-variant = "LE_X13S"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml index f799a1e52173..75c9489f319b 100644 --- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml +++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.yaml @@ -89,7 +89,7 @@ examples: #include <dt-bindings/interrupt-controller/irq.h> // For wl12xx family: - spi1 { + spi { #address-cells = <1>; #size-cells = <0>; @@ -104,8 +104,11 @@ examples: }; }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + // For wl18xx family: - spi2 { + spi { #address-cells = <1>; #size-cells = <0>; @@ -118,6 +121,9 @@ examples: }; }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + // SDIO example: mmc3 { vmmc-supply = <&wlan_en_reg>; diff --git a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml index 34dd1cc67124..fc6555724e18 100644 --- a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml +++ b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml @@ -14,6 +14,7 @@ properties: items: - enum: - apple,t8103-nvme-ans2 + - apple,t8112-nvme-ans2 - apple,t6000-nvme-ans2 - const: apple,nvme-ans2 @@ -65,7 +66,9 @@ if: properties: compatible: contains: - const: apple,t8103-nvme-ans2 + enum: + - apple,t8103-nvme-ans2 + - apple,t8112-nvme-ans2 then: properties: power-domains: diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml index 14c170c6a86e..296001e7f498 100644 --- a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml @@ -11,7 +11,7 @@ maintainers: - Maxime Ripard <mripard@kernel.org> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/amlogic,meson-gxbb-efuse.yaml b/Documentation/devicetree/bindings/nvmem/amlogic,meson-gxbb-efuse.yaml new file mode 100644 index 000000000000..e49c2754ff55 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/amlogic,meson-gxbb-efuse.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/amlogic,meson-gxbb-efuse.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson GX eFuse + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +allOf: + - $ref: nvmem.yaml# + +properties: + compatible: + oneOf: + - const: amlogic,meson-gxbb-efuse + - items: + - const: amlogic,meson-gx-efuse + - const: amlogic,meson-gxbb-efuse + + clocks: + maxItems: 1 + + secure-monitor: + description: phandle to the secure-monitor node + $ref: /schemas/types.yaml#/definitions/phandle + +required: + - compatible + - clocks + - secure-monitor + +unevaluatedProperties: false + +examples: + - | + efuse: efuse { + compatible = "amlogic,meson-gxbb-efuse"; + clocks = <&clk_efuse>; + #address-cells = <1>; + #size-cells = <1>; + secure-monitor = <&sm>; + + sn: sn@14 { + reg = <0x14 0x10>; + }; + + eth_mac: mac@34 { + reg = <0x34 0x10>; + }; + + bid: bid@46 { + reg = <0x46 0x30>; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/amlogic,meson6-efuse.yaml b/Documentation/devicetree/bindings/nvmem/amlogic,meson6-efuse.yaml new file mode 100644 index 000000000000..84b3dfd21e09 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/amlogic,meson6-efuse.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/amlogic,meson6-efuse.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson6 eFuse + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + - Martin Blumenstingl <martin.blumenstingl@googlemail.com> + +allOf: + - $ref: nvmem.yaml# + +properties: + compatible: + enum: + - amlogic,meson6-efuse + - amlogic,meson8-efuse + - amlogic,meson8b-efuse + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: core + +required: + - compatible + - reg + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + efuse: efuse@0 { + compatible = "amlogic,meson6-efuse"; + reg = <0x0 0x2000>; + clocks = <&clk_efuse>; + clock-names = "core"; + #address-cells = <1>; + #size-cells = <1>; + + ethernet_mac_address: mac@1b4 { + reg = <0x1b4 0x6>; + }; + + temperature_calib: calib@1f4 { + reg = <0x1f4 0x4>; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt deleted file mode 100644 index f7b3ed74db54..000000000000 --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt +++ /dev/null @@ -1,48 +0,0 @@ -= Amlogic Meson GX eFuse device tree bindings = - -Required properties: -- compatible: should be "amlogic,meson-gxbb-efuse" -- clocks: phandle to the efuse peripheral clock provided by the - clock controller. -- secure-monitor: phandle to the secure-monitor node - -= Data cells = -Are child nodes of eFuse, bindings of which as described in -bindings/nvmem/nvmem.txt - -Example: - - efuse: efuse { - compatible = "amlogic,meson-gxbb-efuse"; - clocks = <&clkc CLKID_EFUSE>; - #address-cells = <1>; - #size-cells = <1>; - secure-monitor = <&sm>; - - sn: sn@14 { - reg = <0x14 0x10>; - }; - - eth_mac: eth_mac@34 { - reg = <0x34 0x10>; - }; - - bid: bid@46 { - reg = <0x46 0x30>; - }; - }; - - sm: secure-monitor { - compatible = "amlogic,meson-gxbb-sm"; - }; - -= Data consumers = -Are device nodes which consume nvmem data cells. - -For example: - - eth_mac { - ... - nvmem-cells = <ð_mac>; - nvmem-cell-names = "eth_mac"; - }; diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt b/Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt deleted file mode 100644 index a3c63954a1a4..000000000000 --- a/Documentation/devicetree/bindings/nvmem/amlogic-meson-mx-efuse.txt +++ /dev/null @@ -1,22 +0,0 @@ -Amlogic Meson6/Meson8/Meson8b efuse - -Required Properties: -- compatible: depending on the SoC this should be one of: - - "amlogic,meson6-efuse" - - "amlogic,meson8-efuse" - - "amlogic,meson8b-efuse" -- reg: base address and size of the efuse registers -- clocks: a reference to the efuse core gate clock -- clock-names: must be "core" - -All properties and sub-nodes as well as the consumer bindings -defined in nvmem.txt in this directory are also supported. - - -Example: - efuse: nvmem@0 { - compatible = "amlogic,meson8-efuse"; - reg = <0x0 0x2000>; - clocks = <&clkc CLKID_EFUSE>; - clock-names = "core"; - }; diff --git a/Documentation/devicetree/bindings/nvmem/apple,efuses.yaml b/Documentation/devicetree/bindings/nvmem/apple,efuses.yaml index 5ec8f2bdb3a5..e0860b6b85f3 100644 --- a/Documentation/devicetree/bindings/nvmem/apple,efuses.yaml +++ b/Documentation/devicetree/bindings/nvmem/apple,efuses.yaml @@ -15,7 +15,7 @@ maintainers: - Sven Peter <sven@svenpeter.dev> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml index 25033de3ef6b..36def7128fca 100644 --- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml +++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml @@ -20,7 +20,7 @@ maintainers: - RafaÅ‚ MiÅ‚ecki <rafal@milecki.pl> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml index 3b4e6e94cb81..70fb2ad25103 100644 --- a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml +++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml @@ -14,7 +14,7 @@ description: | unique identifier per part. allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/imx-iim.yaml b/Documentation/devicetree/bindings/nvmem/imx-iim.yaml index 7aac1995cfaf..e9d9d8df4811 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-iim.yaml +++ b/Documentation/devicetree/bindings/nvmem/imx-iim.yaml @@ -14,7 +14,7 @@ description: | i.MX25, i.MX27, i.MX31, i.MX35, i.MX51 and i.MX53 SoCs. allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml index d0a239d7e199..9876243ff1e8 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml @@ -15,7 +15,7 @@ description: | i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM, i.MX8MN and i.MX8MP SoCs. allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml b/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml index fe2cd7f1afba..e89fd879c968 100644 --- a/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml +++ b/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml @@ -10,7 +10,7 @@ maintainers: - PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml index 5a0e7671aa3f..714a6538cc7c 100644 --- a/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml +++ b/Documentation/devicetree/bindings/nvmem/layouts/onie,tlv-layout.yaml @@ -61,7 +61,7 @@ properties: type: object additionalProperties: false - platforn-name: + platform-name: type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml index 75e0a516e59a..d16d42fb98b6 100644 --- a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml +++ b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml @@ -15,7 +15,7 @@ maintainers: - Lala Lin <lala.lin@mediatek.com> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: $nodename: diff --git a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml index c3c96fd0baac..a296d348adb4 100644 --- a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml +++ b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml @@ -15,7 +15,7 @@ description: | settings, chip identifiers) or user specific data could be stored. allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml index ff317fd7c15b..8938eec22b52 100644 --- a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml +++ b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.yaml @@ -10,7 +10,7 @@ maintainers: - Anson Huang <Anson.Huang@nxp.com> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml b/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml index f93bc50c40d7..6c26800f8b79 100644 --- a/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml +++ b/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml @@ -17,7 +17,7 @@ maintainers: - Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml index 2173fe82317d..8d8503dd934b 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml @@ -10,7 +10,7 @@ maintainers: - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: @@ -32,6 +32,8 @@ properties: - qcom,sdm670-qfprom - qcom,sdm845-qfprom - qcom,sm6115-qfprom + - qcom,sm6350-qfprom + - qcom,sm6375-qfprom - qcom,sm8150-qfprom - qcom,sm8250-qfprom - const: qcom,qfprom diff --git a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml index e08504ef3b6e..dce0c7d84ce7 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml @@ -15,7 +15,7 @@ description: | to/from the PBUS. allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: @@ -42,17 +42,22 @@ unevaluatedProperties: false examples: - | - sdam_1: nvram@b000 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "qcom,spmi-sdam"; - reg = <0xb000 0x100>; - ranges = <0 0xb000 0x100>; - - /* Data cells */ - restart_reason: restart@50 { - reg = <0x50 0x1>; - bits = <6 2>; - }; - }; + pmic { + #address-cells = <1>; + #size-cells = <0>; + + sdam_1: nvram@b000 { + compatible = "qcom,spmi-sdam"; + reg = <0xb000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xb000 0x100>; + + /* Data cells */ + restart_reason: restart@50 { + reg = <0x50 0x1>; + bits = <6 2>; + }; + }; + }; ... diff --git a/Documentation/devicetree/bindings/nvmem/rmem.yaml b/Documentation/devicetree/bindings/nvmem/rmem.yaml index a4a755dcfc43..38a39c9b8c1c 100644 --- a/Documentation/devicetree/bindings/nvmem/rmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/rmem.yaml @@ -10,7 +10,7 @@ maintainers: - Nicolas Saenz Julienne <nsaenzjulienne@suse.de> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml index febee8129aa9..c5403e149080 100644 --- a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml +++ b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml @@ -10,7 +10,7 @@ maintainers: - Heiko Stuebner <heiko@sntech.de> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml index dc790d2cd9f0..b8bca0599c45 100644 --- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml +++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml @@ -11,7 +11,7 @@ maintainers: - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: "#address-cells": true diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml index 172597cc5c63..a69de3e92282 100644 --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml @@ -16,7 +16,7 @@ maintainers: - Fabrice Gasnier <fabrice.gasnier@foss.st.com> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml index a7644ebbc2ca..8877c2283e9e 100644 --- a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml +++ b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml @@ -11,7 +11,7 @@ maintainers: - Vincent Shih <vincent.sunplus@gmail.com> allOf: - - $ref: "nvmem.yaml#" + - $ref: nvmem.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml index cbc5c69fd405..36d97fb87865 100644 --- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml +++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml @@ -50,7 +50,11 @@ properties: ethaddr: type: object - description: Ethernet interface's MAC address + description: Ethernet interfaces base MAC address. + properties: + "#nvmem-cell-cells": + description: The first argument is a MAC address offset. + const: 1 additionalProperties: false @@ -72,6 +76,7 @@ examples: reg = <0x40000 0x10000>; mac: ethaddr { + #nvmem-cell-cells = <1>; }; }; }; diff --git a/Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml b/Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml new file mode 100644 index 000000000000..a5bd90bc0712 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/amlogic,axg-pcie.yaml @@ -0,0 +1,134 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/amlogic,axg-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson AXG DWC PCIe SoC controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +description: + Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI core. + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + - $ref: /schemas/pci/snps,dw-pcie-common.yaml# + +# We need a select here so we don't match all nodes with 'snps,dw-pcie' +select: + properties: + compatible: + enum: + - amlogic,axg-pcie + - amlogic,g12a-pcie + required: + - compatible + +properties: + compatible: + items: + - enum: + - amlogic,axg-pcie + - amlogic,g12a-pcie + - const: snps,dw-pcie + + reg: + items: + - description: External local bus interface registers + - description: Meson designed configuration registers + - description: PCIe configuration space + + reg-names: + items: + - const: elbi + - const: cfg + - const: config + + interrupts: + maxItems: 1 + + clocks: + items: + - description: PCIe GEN 100M PLL clock + - description: PCIe RC clock gate + - description: PCIe PHY clock + + clock-names: + items: + - const: pclk + - const: port + - const: general + + phys: + maxItems: 1 + + phy-names: + const: pcie + + resets: + items: + - description: Port Reset + - description: Shared APB reset + + reset-names: + items: + - const: port + - const: apb + + num-lanes: + const: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - interrupts + - clock + - clock-names + - "#address-cells" + - "#size-cells" + - "#interrupt-cells" + - interrupt-map + - interrupt-map-mask + - ranges + - bus-range + - device_type + - num-lanes + - phys + - phy-names + - resets + - reset-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + pcie: pcie@f9800000 { + compatible = "amlogic,axg-pcie", "snps,dw-pcie"; + reg = <0xf9800000 0x400000>, <0xff646000 0x2000>, <0xf9f00000 0x100000>; + reg-names = "elbi", "cfg", "config"; + interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>; + clocks = <&pclk>, <&clk_port>, <&clk_phy>; + clock-names = "pclk", "port", "general"; + resets = <&reset_pcie_port>, <&reset_pcie_apb>; + reset-names = "port", "apb"; + phys = <&pcie_phy>; + phy-names = "pcie"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 179 IRQ_TYPE_EDGE_RISING>; + bus-range = <0x0 0xff>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + num-lanes = <1>; + ranges = <0x82000000 0 0 0xf9c00000 0 0x00300000>; + }; +... diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt deleted file mode 100644 index c3a75ac6e59d..000000000000 --- a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt +++ /dev/null @@ -1,70 +0,0 @@ -Amlogic Meson AXG DWC PCIE SoC controller - -Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI core. -It shares common functions with the PCIe DesignWare core driver and -inherits common properties defined in -Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. - -Additional properties are described here: - -Required properties: -- compatible: - should contain : - - "amlogic,axg-pcie" for AXG SoC Family - - "amlogic,g12a-pcie" for G12A SoC Family - to identify the core. -- reg: - should contain the configuration address space. -- reg-names: Must be - - "elbi" External local bus interface registers - - "cfg" Meson specific registers - - "config" PCIe configuration space -- reset-gpios: The GPIO to generate PCIe PERST# assert and deassert signal. -- clocks: Must contain an entry for each entry in clock-names. -- clock-names: Must include the following entries: - - "pclk" PCIe GEN 100M PLL clock - - "port" PCIe_x(A or B) RC clock gate - - "general" PCIe Phy clock -- resets: phandle to the reset lines. -- reset-names: must contain "port" and "apb" - - "port" Port A or B reset - - "apb" Share APB reset -- phys: should contain a phandle to the PCIE phy -- phy-names: must contain "pcie" - -- device_type: - should be "pci". As specified in snps,dw-pcie.yaml - - -Example configuration: - - pcie: pcie@f9800000 { - compatible = "amlogic,axg-pcie", "snps,dw-pcie"; - reg = <0x0 0xf9800000 0x0 0x400000 - 0x0 0xff646000 0x0 0x2000 - 0x0 0xf9f00000 0x0 0x100000>; - reg-names = "elbi", "cfg", "config"; - reset-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>; - interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>; - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &gic GIC_SPI 179 IRQ_TYPE_EDGE_RISING>; - bus-range = <0x0 0xff>; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - ranges = <0x82000000 0 0 0x0 0xf9c00000 0 0x00300000>; - - clocks = <&clkc CLKID_USB - &clkc CLKID_PCIE_A - &clkc CLKID_PCIE_CML_EN0>; - clock-names = "general", - "pclk", - "port"; - resets = <&reset RESET_PCIE_A>, - <&reset RESET_PCIE_APB>; - reset-names = "port", - "apb"; - phys = <&pcie_phy>; - phy-names = "pcie"; - }; diff --git a/Documentation/devicetree/bindings/pci/apple,pcie.yaml b/Documentation/devicetree/bindings/pci/apple,pcie.yaml index aa38680aaaca..215ff9a9c835 100644 --- a/Documentation/devicetree/bindings/pci/apple,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml @@ -33,6 +33,7 @@ properties: items: - enum: - apple,t8103-pcie + - apple,t8112-pcie - apple,t6000-pcie - const: apple,pcie diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml index e6ef1012a580..98651ab22103 100644 --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml @@ -10,7 +10,7 @@ maintainers: - Tom Joseph <tjoseph@cadence.com> allOf: - - $ref: "cdns-pcie-ep.yaml#" + - $ref: cdns-pcie-ep.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml index 293b8ec318bc..bc3c48f60fff 100644 --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml @@ -11,7 +11,7 @@ maintainers: allOf: - $ref: /schemas/pci/pci-bus.yaml# - - $ref: "cdns-pcie-host.yaml#" + - $ref: cdns-pcie-host.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml index baeafda36ebe..47a302ba4ac9 100644 --- a/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/pci/cdns-pcie-ep.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/pci/cdns-pcie-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence PCIe Device @@ -10,8 +10,8 @@ maintainers: - Tom Joseph <tjoseph@cadence.com> allOf: - - $ref: "cdns-pcie.yaml#" - - $ref: "pci-ep.yaml#" + - $ref: cdns-pcie.yaml# + - $ref: pci-ep.yaml# properties: cdns,max-outbound-regions: diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml index a944f9bfffff..a6b494401ebb 100644 --- a/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/pci/cdns-pcie-host.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/pci/cdns-pcie-host.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence PCIe Host @@ -10,8 +10,8 @@ maintainers: - Tom Joseph <tjoseph@cadence.com> allOf: - - $ref: "/schemas/pci/pci-bus.yaml#" - - $ref: "cdns-pcie.yaml#" + - $ref: /schemas/pci/pci-bus.yaml# + - $ref: cdns-pcie.yaml# properties: cdns,max-outbound-regions: diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie.yaml index df4fe28222b0..2e14f422e829 100644 --- a/Documentation/devicetree/bindings/pci/cdns-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/cdns-pcie.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/pci/cdns-pcie.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/pci/cdns-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence PCIe Core diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml new file mode 100644 index 000000000000..9bff8ecb653c --- /dev/null +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml @@ -0,0 +1,279 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/fsl,imx6q-pcie-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX6 PCIe RC/EP controller + +maintainers: + - Lucas Stach <l.stach@pengutronix.de> + - Richard Zhu <hongxing.zhu@nxp.com> + +description: + Generic Freescale i.MX PCIe Root Port and Endpoint controller + properties. + +properties: + clocks: + minItems: 3 + items: + - description: PCIe bridge clock. + - description: PCIe bus clock. + - description: PCIe PHY clock. + - description: Additional required clock entry for imx6sx-pcie, + imx6sx-pcie-ep, imx8mq-pcie, imx8mq-pcie-ep. + + clock-names: + minItems: 3 + items: + - const: pcie + - const: pcie_bus + - enum: [ pcie_phy, pcie_aux ] + - enum: [ pcie_inbound_axi, pcie_aux ] + + num-lanes: + const: 1 + + fsl,imx7d-pcie-phy: + $ref: /schemas/types.yaml#/definitions/phandle + description: A phandle to an fsl,imx7d-pcie-phy node. Additional + required properties for imx7d-pcie, imx7d-pcie-ep, imx8mq-pcie, + and imx8mq-pcie-ep. + + power-domains: + minItems: 1 + items: + - description: The phandle pointing to the DISPLAY domain for + imx6sx-pcie, imx6sx-pcie-ep, to PCIE_PHY power domain for + imx7d-pcie, imx7d-pcie-ep, imx8mq-pcie and imx8mq-pcie-ep. + - description: The phandle pointing to the PCIE_PHY power domains + for imx6sx-pcie and imx6sx-pcie-ep. + + power-domain-names: + minItems: 1 + items: + - const: pcie + - const: pcie_phy + + resets: + minItems: 2 + maxItems: 3 + description: Phandles to PCIe-related reset lines exposed by SRC + IP block. Additional required by imx7d-pcie, imx7d-pcie-ep, + imx8mq-pcie, and imx8mq-pcie-ep. + + reset-names: + minItems: 2 + maxItems: 3 + + fsl,tx-deemph-gen1: + description: Gen1 De-emphasis value (optional required). + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + fsl,tx-deemph-gen2-3p5db: + description: Gen2 (3.5db) De-emphasis value (optional required). + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + fsl,tx-deemph-gen2-6db: + description: Gen2 (6db) De-emphasis value (optional required). + $ref: /schemas/types.yaml#/definitions/uint32 + default: 20 + + fsl,tx-swing-full: + description: Gen2 TX SWING FULL value (optional required). + $ref: /schemas/types.yaml#/definitions/uint32 + default: 127 + + fsl,tx-swing-low: + description: TX launch amplitude swing_low value (optional required). + $ref: /schemas/types.yaml#/definitions/uint32 + default: 127 + + fsl,max-link-speed: + description: Specify PCI Gen for link capability (optional required). + Note that the IMX6 LVDS clock outputs do not meet gen2 jitter + requirements and thus for gen2 capability a gen2 compliant clock + generator should be used and configured. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 3, 4] + default: 1 + + phys: + maxItems: 1 + + phy-names: + const: pcie-phy + + vpcie-supply: + description: Should specify the regulator in charge of PCIe port power. + The regulator will be enabled when initializing the PCIe host and + disabled either as part of the init process or when shutting down + the host (optional required). + + vph-supply: + description: Should specify the regulator in charge of VPH one of + the three PCIe PHY powers. This regulator can be supplied by both + 1.8v and 3.3v voltage supplies (optional required). + +required: + - clocks + - clock-names + - num-lanes + +allOf: + - if: + properties: + compatible: + contains: + enum: + - fsl,imx6sx-pcie + - fsl,imx6sx-pcie-ep + then: + properties: + clock-names: + items: + - {} + - {} + - const: pcie_phy + - const: pcie_inbound_axi + power-domains: + minItems: 2 + power-domain-names: + minItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8mq-pcie + - fsl,imx8mq-pcie-ep + then: + properties: + clock-names: + items: + - {} + - {} + - const: pcie_phy + - const: pcie_aux + - if: + properties: + compatible: + not: + contains: + enum: + - fsl,imx6sx-pcie + - fsl,imx8mq-pcie + - fsl,imx6sx-pcie-ep + - fsl,imx8mq-pcie-ep + then: + properties: + clocks: + maxItems: 3 + clock-names: + maxItems: 3 + + - if: + properties: + compatible: + contains: + enum: + - fsl,imx6q-pcie + - fsl,imx6qp-pcie + - fsl,imx7d-pcie + - fsl,imx6q-pcie-ep + - fsl,imx6qp-pcie-ep + - fsl,imx7d-pcie-ep + then: + properties: + clock-names: + maxItems: 3 + contains: + const: pcie_phy + + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8mm-pcie + - fsl,imx8mp-pcie + - fsl,imx8mm-pcie-ep + - fsl,imx8mp-pcie-ep + then: + properties: + clock-names: + maxItems: 3 + contains: + const: pcie_aux + - if: + properties: + compatible: + contains: + enum: + - fsl,imx6q-pcie + - fsl,imx6qp-pcie + - fsl,imx6q-pcie-ep + - fsl,imx6qp-pcie-ep + then: + properties: + power-domains: false + power-domain-names: false + + - if: + not: + properties: + compatible: + contains: + enum: + - fsl,imx6sx-pcie + - fsl,imx6q-pcie + - fsl,imx6qp-pcie + - fsl,imx6sx-pcie-ep + - fsl,imx6q-pcie-ep + - fsl,imx6qp-pcie-ep + then: + properties: + power-domains: + maxItems: 1 + power-domain-names: false + + - if: + properties: + compatible: + contains: + enum: + - fsl,imx6q-pcie + - fsl,imx6sx-pcie + - fsl,imx6qp-pcie + - fsl,imx7d-pcie + - fsl,imx8mq-pcie + - fsl,imx6q-pcie-ep + - fsl,imx6sx-pcie-ep + - fsl,imx6qp-pcie-ep + - fsl,imx7d-pcie-ep + - fsl,imx8mq-pcie-ep + then: + properties: + resets: + minItems: 3 + reset-names: + items: + - const: pciephy + - const: apps + - const: turnoff + else: + properties: + resets: + maxItems: 2 + reset-names: + items: + - const: apps + - const: turnoff + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml new file mode 100644 index 000000000000..f4a328ec1daa --- /dev/null +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/fsl,imx6q-pcie-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX6 PCIe Endpoint controller + +maintainers: + - Lucas Stach <l.stach@pengutronix.de> + - Richard Zhu <hongxing.zhu@nxp.com> + +description: |+ + This PCIe controller is based on the Synopsys DesignWare PCIe IP and + thus inherits all the common properties defined in snps,dw-pcie-ep.yaml. + The controller instances are dual mode where in they can work either in + Root Port mode or Endpoint mode but one at a time. + +properties: + compatible: + enum: + - fsl,imx8mm-pcie-ep + - fsl,imx8mq-pcie-ep + - fsl,imx8mp-pcie-ep + + reg: + minItems: 2 + + reg-names: + items: + - const: dbi + - const: addr_space + + interrupts: + items: + - description: builtin eDMA interrupter. + + interrupt-names: + items: + - const: dma + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + +allOf: + - $ref: /schemas/pci/snps,dw-pcie-ep.yaml# + - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mp-clock.h> + #include <dt-bindings/power/imx8mp-power.h> + #include <dt-bindings/reset/imx8mp-reset.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pcie_ep: pcie-ep@33800000 { + compatible = "fsl,imx8mp-pcie-ep"; + reg = <0x33800000 0x000400000>, <0x18000000 0x08000000>; + reg-names = "dbi", "addr_space"; + clocks = <&clk IMX8MP_CLK_HSIO_ROOT>, + <&clk IMX8MP_CLK_HSIO_AXI>, + <&clk IMX8MP_CLK_PCIE_ROOT>; + clock-names = "pcie", "pcie_bus", "pcie_aux"; + assigned-clocks = <&clk IMX8MP_CLK_PCIE_AUX>; + assigned-clock-rates = <10000000>; + assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_50M>; + num-lanes = <1>; + interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>; /* eDMA */ + interrupt-names = "dma"; + fsl,max-link-speed = <3>; + power-domains = <&hsio_blk_ctrl IMX8MP_HSIOBLK_PD_PCIE>; + resets = <&src IMX8MP_RESET_PCIE_CTRL_APPS_EN>, + <&src IMX8MP_RESET_PCIE_CTRL_APPS_TURNOFF>; + reset-names = "apps", "turnoff"; + phys = <&pcie_phy>; + phy-names = "pcie-phy"; + num-ib-windows = <4>; + num-ob-windows = <4>; + }; diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index f13f87fddb3d..2443641754d3 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -13,6 +13,11 @@ maintainers: description: |+ This PCIe host controller is based on the Synopsys DesignWare PCIe IP and thus inherits all the common properties defined in snps,dw-pcie.yaml. + The controller instances are dual mode where in they can work either in + Root Port mode or Endpoint mode but one at a time. + + See fsl,imx6q-pcie-ep.yaml for details on the Endpoint mode device tree + bindings. properties: compatible: @@ -24,9 +29,6 @@ properties: - fsl,imx8mq-pcie - fsl,imx8mm-pcie - fsl,imx8mp-pcie - - fsl,imx8mm-pcie-ep - - fsl,imx8mq-pcie-ep - - fsl,imx8mp-pcie-ep reg: items: @@ -46,96 +48,6 @@ properties: items: - const: msi - clocks: - minItems: 3 - items: - - description: PCIe bridge clock. - - description: PCIe bus clock. - - description: PCIe PHY clock. - - description: Additional required clock entry for imx6sx-pcie, - imx8mq-pcie. - - clock-names: - minItems: 3 - items: - - const: pcie - - const: pcie_bus - - enum: [ pcie_phy, pcie_aux ] - - enum: [ pcie_inbound_axi, pcie_aux ] - - num-lanes: - const: 1 - - fsl,imx7d-pcie-phy: - $ref: /schemas/types.yaml#/definitions/phandle - description: A phandle to an fsl,imx7d-pcie-phy node. Additional - required properties for imx7d-pcie and imx8mq-pcie. - - power-domains: - minItems: 1 - items: - - description: The phandle pointing to the DISPLAY domain for - imx6sx-pcie, to PCIE_PHY power domain for imx7d-pcie and - imx8mq-pcie. - - description: The phandle pointing to the PCIE_PHY power domains - for imx6sx-pcie. - - power-domain-names: - minItems: 1 - items: - - const: pcie - - const: pcie_phy - - resets: - minItems: 2 - maxItems: 3 - description: Phandles to PCIe-related reset lines exposed by SRC - IP block. Additional required by imx7d-pcie and imx8mq-pcie. - - reset-names: - minItems: 2 - maxItems: 3 - - fsl,tx-deemph-gen1: - description: Gen1 De-emphasis value (optional required). - $ref: /schemas/types.yaml#/definitions/uint32 - default: 0 - - fsl,tx-deemph-gen2-3p5db: - description: Gen2 (3.5db) De-emphasis value (optional required). - $ref: /schemas/types.yaml#/definitions/uint32 - default: 0 - - fsl,tx-deemph-gen2-6db: - description: Gen2 (6db) De-emphasis value (optional required). - $ref: /schemas/types.yaml#/definitions/uint32 - default: 20 - - fsl,tx-swing-full: - description: Gen2 TX SWING FULL value (optional required). - $ref: /schemas/types.yaml#/definitions/uint32 - default: 127 - - fsl,tx-swing-low: - description: TX launch amplitude swing_low value (optional required). - $ref: /schemas/types.yaml#/definitions/uint32 - default: 127 - - fsl,max-link-speed: - description: Specify PCI Gen for link capability (optional required). - Note that the IMX6 LVDS clock outputs do not meet gen2 jitter - requirements and thus for gen2 capability a gen2 compliant clock - generator should be used and configured. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [1, 2, 3, 4] - default: 1 - - phys: - maxItems: 1 - - phy-names: - const: pcie-phy - reset-gpio: description: Should specify the GPIO for controlling the PCI bus device reset signal. It's not polarity aware and defaults to active-low reset @@ -147,17 +59,6 @@ properties: L=operation state) (optional required). type: boolean - vpcie-supply: - description: Should specify the regulator in charge of PCIe port power. - The regulator will be enabled when initializing the PCIe host and - disabled either as part of the init process or when shutting down - the host (optional required). - - vph-supply: - description: Should specify the regulator in charge of VPH one of - the three PCIe PHY powers. This regulator can be supplied by both - 1.8v and 3.3v voltage supplies (optional required). - required: - compatible - reg @@ -167,144 +68,15 @@ required: - device_type - bus-range - ranges - - num-lanes - interrupts - interrupt-names - "#interrupt-cells" - interrupt-map-mask - interrupt-map - - clocks - - clock-names allOf: - $ref: /schemas/pci/snps,dw-pcie.yaml# - - if: - properties: - compatible: - contains: - const: fsl,imx6sx-pcie - then: - properties: - clock-names: - items: - - {} - - {} - - const: pcie_phy - - const: pcie_inbound_axi - power-domains: - minItems: 2 - power-domain-names: - minItems: 2 - - if: - properties: - compatible: - contains: - const: fsl,imx8mq-pcie - then: - properties: - clock-names: - items: - - {} - - {} - - const: pcie_phy - - const: pcie_aux - - if: - properties: - compatible: - not: - contains: - enum: - - fsl,imx6sx-pcie - - fsl,imx8mq-pcie - then: - properties: - clocks: - maxItems: 3 - clock-names: - maxItems: 3 - - - if: - properties: - compatible: - contains: - enum: - - fsl,imx6q-pcie - - fsl,imx6qp-pcie - - fsl,imx7d-pcie - then: - properties: - clock-names: - maxItems: 3 - contains: - const: pcie_phy - - - if: - properties: - compatible: - contains: - enum: - - fsl,imx8mm-pcie - - fsl,imx8mp-pcie - then: - properties: - clock-names: - maxItems: 3 - contains: - const: pcie_aux - - if: - properties: - compatible: - contains: - enum: - - fsl,imx6q-pcie - - fsl,imx6qp-pcie - then: - properties: - power-domains: false - power-domain-names: false - - - if: - not: - properties: - compatible: - contains: - enum: - - fsl,imx6sx-pcie - - fsl,imx6q-pcie - - fsl,imx6qp-pcie - then: - properties: - power-domains: - maxItems: 1 - power-domain-names: false - - - if: - properties: - compatible: - contains: - enum: - - fsl,imx6q-pcie - - fsl,imx6sx-pcie - - fsl,imx6qp-pcie - - fsl,imx7d-pcie - - fsl,imx8mq-pcie - then: - properties: - resets: - minItems: 3 - reset-names: - items: - - const: pciephy - - const: apps - - const: turnoff - else: - properties: - resets: - maxItems: 2 - reset-names: - items: - - const: apps - - const: turnoff + - $ref: /schemas/pci/fsl,imx6q-pcie-common.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml index e87ff27526ff..730e63fd7669 100644 --- a/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/pci/intel,keembay-pcie-ep.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/pci/intel,keembay-pcie-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel Keem Bay PCIe controller Endpoint mode diff --git a/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml b/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml index ed4400c9ac09..505acc4f3efc 100644 --- a/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/pci/intel,keembay-pcie.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/pci/intel,keembay-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel Keem Bay PCIe controller Root Complex mode diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml index 89cfdee4b89f..b3c22ebd156c 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml @@ -45,7 +45,7 @@ properties: description: Reference to a syscon representing TCSR followed by the two offsets within syscon for Perst enable and Perst separation enable registers - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: Syscon to TCSR system registers @@ -166,7 +166,7 @@ examples: #include <dt-bindings/clock/qcom,gcc-sdx55.h> #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/arm-gic.h> - pcie_ep: pcie-ep@40000000 { + pcie_ep: pcie-ep@1c00000 { compatible = "qcom,sdx55-pcie-ep"; reg = <0x01c00000 0x3000>, <0x40000000 0xf1d>, diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml index fb32c43dd12d..81971be4e554 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml @@ -8,7 +8,7 @@ title: Qualcomm PCI express root complex maintainers: - Bjorn Andersson <bjorn.andersson@linaro.org> - - Stanimir Varbanov <svarbanov@mm-sol.com> + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> description: | Qualcomm PCIe root complex controller is based on the Synopsys DesignWare @@ -33,22 +33,24 @@ properties: - qcom,pcie-sc8180x - qcom,pcie-sc8280xp - qcom,pcie-sdm845 + - qcom,pcie-sdx55 - qcom,pcie-sm8150 - qcom,pcie-sm8250 - qcom,pcie-sm8350 - qcom,pcie-sm8450-pcie0 - qcom,pcie-sm8450-pcie1 + - qcom,pcie-sm8550 - items: - const: qcom,pcie-msm8998 - const: qcom,pcie-msm8996 reg: minItems: 4 - maxItems: 5 + maxItems: 6 reg-names: minItems: 4 - maxItems: 5 + maxItems: 6 interrupts: minItems: 1 @@ -58,6 +60,9 @@ properties: minItems: 1 maxItems: 8 + iommu-map: + maxItems: 2 + # Common definitions for clocks, clock-names and reset. # Platform constraints are described later. clocks: @@ -120,14 +125,20 @@ required: - compatible - reg - reg-names - - interrupts - - interrupt-names - - "#interrupt-cells" - interrupt-map-mask - interrupt-map - clocks - clock-names +anyOf: + - required: + - interrupts + - interrupt-names + - "#interrupt-cells" + - required: + - msi-map + - msi-map-mask + allOf: - $ref: /schemas/pci/pci-bus.yaml# - if: @@ -185,13 +196,15 @@ allOf: properties: reg: minItems: 4 - maxItems: 4 + maxItems: 5 reg-names: + minItems: 4 items: - const: parf # Qualcomm specific registers - const: dbi # DesignWare PCIe registers - const: elbi # External local bus interface registers - const: config # PCIe configuration space + - const: mhi # MHI registers - if: properties: @@ -201,22 +214,26 @@ allOf: - qcom,pcie-sc7280 - qcom,pcie-sc8180x - qcom,pcie-sc8280xp + - qcom,pcie-sdx55 - qcom,pcie-sm8250 - qcom,pcie-sm8350 - qcom,pcie-sm8450-pcie0 - qcom,pcie-sm8450-pcie1 + - qcom,pcie-sm8550 then: properties: reg: minItems: 5 - maxItems: 5 + maxItems: 6 reg-names: + minItems: 5 items: - const: parf # Qualcomm specific registers - const: dbi # DesignWare PCIe registers - const: elbi # External local bus interface registers - const: atu # ATU address space - const: config # PCIe configuration space + - const: mhi # MHI registers - if: properties: @@ -644,6 +661,37 @@ allOf: compatible: contains: enum: + - qcom,pcie-sm8550 + then: + properties: + clocks: + minItems: 7 + maxItems: 8 + clock-names: + minItems: 7 + items: + - const: aux # Auxiliary clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: slave_q2a # Slave Q2A clock + - const: ddrss_sf_tbu # PCIe SF TBU clock + - const: noc_aggr # Aggre NoC PCIe AXI clock + - const: cnoc_sf_axi # Config NoC PCIe1 AXI clock + resets: + minItems: 1 + maxItems: 2 + reset-names: + minItems: 1 + items: + - const: pci # PCIe core reset + - const: link_down # PCIe link down reset + + - if: + properties: + compatible: + contains: + enum: - qcom,pcie-sa8540p - qcom,pcie-sc8280xp then: @@ -674,6 +722,32 @@ allOf: compatible: contains: enum: + - qcom,pcie-sdx55 + then: + properties: + clocks: + minItems: 7 + maxItems: 7 + clock-names: + items: + - const: pipe # PIPE clock + - const: aux # Auxiliary clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: slave_q2a # Slave Q2A clock + - const: sleep # PCIe Sleep clock + resets: + maxItems: 1 + reset-names: + items: + - const: pci # PCIe core reset + + - if: + properties: + compatible: + contains: + enum: - qcom,pcie-sa8540p - qcom,pcie-sc8280xp then: @@ -724,6 +798,7 @@ allOf: - qcom,pcie-sm8350 - qcom,pcie-sm8450-pcie0 - qcom,pcie-sm8450-pcie1 + - qcom,pcie-sm8550 then: oneOf: - properties: diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml index 10e6eabdff53..62292185fe2e 100644 --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/pci/ti,j721e-pci-ep.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/pci/ti,j721e-pci-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI J721E PCI EP (PCIe Wrapper) @@ -11,7 +11,7 @@ maintainers: - Kishon Vijay Abraham I <kishon@ti.com> allOf: - - $ref: "cdns-pcie-ep.yaml#" + - $ref: cdns-pcie-ep.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml index 3d7aee97353a..a2c5eaea57f5 100644 --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/pci/ti,j721e-pci-host.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/pci/ti,j721e-pci-host.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI J721E PCI Host (PCIe Wrapper) @@ -11,7 +11,7 @@ maintainers: - Kishon Vijay Abraham I <kishon@ti.com> allOf: - - $ref: "cdns-pcie-host.yaml#" + - $ref: cdns-pcie-host.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml index 30f3b5f32a95..43416c216190 100644 --- a/Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml @@ -41,7 +41,7 @@ properties: Phandle to the system controller node $ref: /schemas/types.yaml#/definitions/phandle -#Required child nodes: +# Required child nodes: patternProperties: "^usb-phy@[0|1]$": diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml index 5b4c915cc9e5..24a3dbde223b 100644 --- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml +++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml @@ -55,7 +55,7 @@ properties: description: number of clock cells for ck_usbo_48m consumer const: 0 -#Required child nodes: +# Required child nodes: patternProperties: "^usb-phy@[0|1]$": diff --git a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml index 2e19a434c669..0ef2c9b9d466 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc7180-qmp-usb3-dp-phy.yaml @@ -83,7 +83,7 @@ properties: description: Phandle to a regulator supply to any specific refclk pll block. -#Required nodes: +# Required nodes: patternProperties: "^usb3-phy@[0-9a-f]+$": type: object diff --git a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml index d3b11351ca45..684c03a6bd40 100644 --- a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml @@ -19,6 +19,7 @@ properties: items: - enum: - apple,t8103-pinctrl + - apple,t8112-pinctrl - apple,t6000-pinctrl - const: apple,pinctrl diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml index e0e943e5b874..a09ebbfec574 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml @@ -51,7 +51,7 @@ properties: description: The interrupt outputs to sysirq. maxItems: 1 -#PIN CONFIGURATION NODES +# PIN CONFIGURATION NODES patternProperties: '-pins$': type: object diff --git a/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml b/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml index 008c3ab7f1bb..ca9d246d46fe 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml @@ -31,7 +31,7 @@ description: | }; }; state_1_node_a { - spi0 { + spi { function = "spi0"; groups = "spi0pins"; }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml index 5e90051ed314..8f60a9113e7a 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml @@ -96,9 +96,11 @@ $defs: 2: Lower Slew rate (slower edges) 3: Reserved (No adjustments) + bias-bus-hold: true bias-pull-down: true bias-pull-up: true bias-disable: true + input-enable: true output-high: true output-low: true diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml index cb5ba1bd6f8d..90b7d75840c1 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml @@ -75,7 +75,9 @@ $defs: bias-pull-down: true bias-pull-up: true bias-disable: true - input-enable: true + input-enable: false + output-disable: true + output-enable: true output-high: true output-low: true diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml index 69c0dd9998ea..d78c3cd0c295 100644 --- a/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml @@ -293,7 +293,7 @@ examples: pinctrl-names = "default"; }; - i2c0 { + i2c { pinctrl-0 = <&i2c0_pins_default>; pinctrl-names = "default"; }; diff --git a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml index 94d369eb85de..59a6af735a21 100644 --- a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml +++ b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml @@ -32,6 +32,7 @@ properties: items: - enum: - apple,t8103-pmgr-pwrstate + - apple,t8112-pmgr-pwrstate - apple,t6000-pmgr-pwrstate - const: apple,pmgr-pwrstate diff --git a/Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml b/Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml new file mode 100644 index 000000000000..202a5d51ee88 --- /dev/null +++ b/Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/qcom,kpss-acc-v2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) v2 + +maintainers: + - Christian Marangi <ansuelsmth@gmail.com> + +description: + The KPSS ACC provides clock, power manager, and reset control to a Krait CPU. + There is one ACC register region per CPU within the KPSS remapped region as + well as an alias register region that remaps accesses to the ACC associated + with the CPU accessing the region. ACC v2 is currently used as a + power-manager for enabling the cpu. + +properties: + compatible: + const: qcom,kpss-acc-v2 + + reg: + items: + - description: Base address and size of the register region + - description: Optional base address and size of the alias register region + minItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + power-manager@f9088000 { + compatible = "qcom,kpss-acc-v2"; + reg = <0xf9088000 0x1000>, + <0xf9008000 0x1000>; + }; +... diff --git a/Documentation/devicetree/bindings/power/supply/adc-battery.yaml b/Documentation/devicetree/bindings/power/supply/adc-battery.yaml new file mode 100644 index 000000000000..ed9702caedff --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/adc-battery.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/adc-battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADC battery + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +description: + Basic battery capacity meter, which only reports basic battery data + via ADC channels and optionally indicate that the battery is full by + polling a GPIO line. + + The voltage is expected to be measured between the battery terminals + and mandatory. The optional current/power channel is expected to + monitor the current/power flowing out of the battery. Last but not + least the temperature channel is supposed to measure the battery + temperature. + +allOf: + - $ref: power-supply.yaml# + +properties: + compatible: + const: adc-battery + + charged-gpios: + description: + GPIO which signals that the battery is fully charged. The GPIO is + often provided by charger ICs, that are not software controllable. + maxItems: 1 + + io-channels: + minItems: 1 + maxItems: 4 + + io-channel-names: + minItems: 1 + items: + - const: voltage + - enum: [ current, power, temperature ] + - enum: [ power, temperature ] + - const: temperature + + monitored-battery: true + +required: + - compatible + - io-channels + - io-channel-names + - monitored-battery + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + fuel-gauge { + compatible = "adc-battery"; + charged-gpios = <&gpio 42 GPIO_ACTIVE_HIGH>; + io-channels = <&adc 13>, <&adc 37>; + io-channel-names = "voltage", "current"; + + power-supplies = <&charger>; + monitored-battery = <&battery>; + }; diff --git a/Documentation/devicetree/bindings/power/supply/bq2415x.yaml b/Documentation/devicetree/bindings/power/supply/bq2415x.yaml index f7287ffd4b12..13822346e708 100644 --- a/Documentation/devicetree/bindings/power/supply/bq2415x.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq2415x.yaml @@ -77,7 +77,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/bq24190.yaml b/Documentation/devicetree/bindings/power/supply/bq24190.yaml index 001c0ffb408d..d3ebc9de8c0b 100644 --- a/Documentation/devicetree/bindings/power/supply/bq24190.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq24190.yaml @@ -75,7 +75,7 @@ examples: charge-term-current-microamp = <128000>; }; - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/bq24257.yaml b/Documentation/devicetree/bindings/power/supply/bq24257.yaml index cc45939d385b..eb064bbf876c 100644 --- a/Documentation/devicetree/bindings/power/supply/bq24257.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq24257.yaml @@ -84,7 +84,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -104,7 +104,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/bq24735.yaml b/Documentation/devicetree/bindings/power/supply/bq24735.yaml index 388ee16f8a1e..af41e7ccd784 100644 --- a/Documentation/devicetree/bindings/power/supply/bq24735.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq24735.yaml @@ -77,7 +77,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml index 1a1b240034ef..845822c87f2a 100644 --- a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml @@ -73,7 +73,7 @@ examples: constant-charge-voltage-max-microvolt = <4000000>; }; #include <dt-bindings/gpio/gpio.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/bq25890.yaml b/Documentation/devicetree/bindings/power/supply/bq25890.yaml index dae27e93af09..0ad302ab2bcc 100644 --- a/Documentation/devicetree/bindings/power/supply/bq25890.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq25890.yaml @@ -102,7 +102,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/bq25980.yaml b/Documentation/devicetree/bindings/power/supply/bq25980.yaml index b687b8bcd705..b70ce8d7f86c 100644 --- a/Documentation/devicetree/bindings/power/supply/bq25980.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq25980.yaml @@ -95,7 +95,7 @@ examples: }; #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml index 347d4433adc5..309ea33b5b25 100644 --- a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml @@ -75,15 +75,16 @@ additionalProperties: false examples: - | - i2c0 { + bat: battery { + compatible = "simple-battery"; + voltage-min-design-microvolt = <3200000>; + energy-full-design-microwatt-hours = <5290000>; + charge-full-design-microamp-hours = <1430000>; + }; + + i2c { #address-cells = <1>; #size-cells = <0>; - bat: battery { - compatible = "simple-battery"; - voltage-min-design-microvolt = <3200000>; - energy-full-design-microwatt-hours = <5290000>; - charge-full-design-microamp-hours = <1430000>; - }; bq27510g3: fuel-gauge@55 { compatible = "ti,bq27510g3"; diff --git a/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml b/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml index 774582cd3a2c..e68a97cb49fe 100644 --- a/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml +++ b/Documentation/devicetree/bindings/power/supply/lltc,ltc294x.yaml @@ -54,7 +54,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; battery@64 { diff --git a/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml b/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml index cfffaeef8b09..29d536541152 100644 --- a/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml +++ b/Documentation/devicetree/bindings/power/supply/ltc4162-l.yaml @@ -54,7 +54,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; charger: battery-charger@68 { diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml index 711066b8cdb9..b444b799848e 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max14656.yaml @@ -32,7 +32,7 @@ additionalProperties: false examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml index 3a529326ecbd..2627cd3eed83 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml @@ -68,7 +68,7 @@ unevaluatedProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -82,7 +82,7 @@ examples: }; - | #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml index 64a0edb7bc47..085e2504d0dc 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml @@ -69,7 +69,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml index 27bebc1757ba..07e38be39f1b 100644 --- a/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml +++ b/Documentation/devicetree/bindings/power/supply/richtek,rt9455.yaml @@ -68,7 +68,7 @@ additionalProperties: false examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml b/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml index ce6fbdba8f6b..069422a8c90c 100644 --- a/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml +++ b/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml @@ -28,6 +28,7 @@ properties: patternProperties: '^(ac|usb)$': type: object + additionalProperties: false description: USB/AC charging parameters properties: charger-type: @@ -61,7 +62,7 @@ additionalProperties: false examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml b/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml index e8bf09faafb8..afe1abc2d727 100644 --- a/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml +++ b/Documentation/devicetree/bindings/regulator/active-semi,act8865.yaml @@ -90,7 +90,7 @@ examples: - | #include <dt-bindings/regulator/active-semi,8865-regulator.h> - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml index 0a66338c7e5a..17250378542a 100644 --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml @@ -10,7 +10,7 @@ maintainers: - Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: @@ -19,43 +19,43 @@ properties: regulator-name: true anatop-reg-offset: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the anatop MFD register offset. anatop-vol-bit-shift: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the bit shift for the register. anatop-vol-bit-width: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the number of bits used in the register. anatop-min-bit-val: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the minimum value of this register. anatop-min-voltage: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the minimum voltage of this regulator. anatop-max-voltage: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the maximum voltage of this regulator. anatop-delay-reg-offset: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the anatop MFD step time register offset. anatop-delay-bit-shift: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the bit shift for the step time register. anatop-delay-bit-width: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the number of bits used in the step time register. anatop-enable-bit: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing regulator enable bit offset. vin-supply: diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml index 63e1161a87de..dc626517c2ad 100644 --- a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml +++ b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml @@ -109,7 +109,7 @@ properties: description: Specify a valid GPIO for platform control of the regulator dlg,ripple-cancel: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 0, 1, 2, 3 ] description: | Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h diff --git a/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml b/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml index c0dbba843f70..69bae90fc4b2 100644 --- a/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml +++ b/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml @@ -14,12 +14,21 @@ allOf: properties: compatible: - enum: - - fcs,fan53555 - - fcs,fan53526 - - silergy,syr827 - - silergy,syr828 - - tcs,tcs4525 + oneOf: + - enum: + - fcs,fan53555 + - fcs,fan53526 + - rockchip,rk8600 + - rockchip,rk8602 + - silergy,syr827 + - silergy,syr828 + - tcs,tcs4525 + - items: + - const: rockchip,rk8601 + - const: rockchip,rk8600 + - items: + - const: rockchip,rk8603 + - const: rockchip,rk8602 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml index 48af7cba4652..ac0281b1cceb 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml @@ -17,7 +17,7 @@ description: to be the same. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml index 0921f012c901..5a6491a81fda 100644 --- a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml @@ -14,7 +14,7 @@ description: regulator.yaml, can also be used. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: @@ -32,7 +32,7 @@ unevaluatedProperties: false examples: - | - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml b/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml index 6c3371d706bb..f4c1f36e52e9 100644 --- a/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml @@ -15,7 +15,7 @@ description: regulator.txt, can also be used. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml b/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml index 01b9775a92d1..27d5e9c2bb93 100644 --- a/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml @@ -25,7 +25,7 @@ properties: patternProperties: "^regulator-(ldo|sbb[0-2])$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# unevaluatedProperties: false required: diff --git a/Documentation/devicetree/bindings/regulator/max8660.yaml b/Documentation/devicetree/bindings/regulator/max8660.yaml index 35792a927b03..f05f4644c8ee 100644 --- a/Documentation/devicetree/bindings/regulator/max8660.yaml +++ b/Documentation/devicetree/bindings/regulator/max8660.yaml @@ -25,7 +25,7 @@ properties: patternProperties: "^regulator-.+$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# unevaluatedProperties: false additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/max8893.yaml b/Documentation/devicetree/bindings/regulator/max8893.yaml index 2b5e977bf409..e40ee798e198 100644 --- a/Documentation/devicetree/bindings/regulator/max8893.yaml +++ b/Documentation/devicetree/bindings/regulator/max8893.yaml @@ -25,7 +25,7 @@ properties: patternProperties: "^(ldo[1-5]|buck)$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml index 771cc134393c..79e5198e1c73 100644 --- a/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml @@ -18,7 +18,7 @@ description: | patternProperties: "^buck-v(core2|io18|dvfs11|dvfs12|dvfs13|dvfs14)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -28,7 +28,7 @@ patternProperties: "^ldo-v(avdd32aud|auxa32)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -38,7 +38,7 @@ patternProperties: "^ldo-v(dig18|emc33|ibr|mc|mch|mipi|rtc|sram|usb10)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -48,7 +48,7 @@ patternProperties: "^ldo-vcam(a|af|d|io)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -58,7 +58,7 @@ patternProperties: "^ldo-vtcxo[12]$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -71,7 +71,7 @@ patternProperties: "^ldo-vgp[1234]$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml index 3218f43e6957..2eb512c29a0d 100644 --- a/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml @@ -18,7 +18,7 @@ description: | patternProperties: "^buck-v(dram|dvfs2|pa|rf18a|rf18b|sbst)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -28,7 +28,7 @@ patternProperties: "^ldo-v(bif28|dig18|sram|usb33)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: diff --git a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml index 7023c597c3ed..2e720d152890 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml @@ -28,11 +28,11 @@ properties: patternProperties: "^buck[1-4]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object "^ldo[1-4]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml b/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml index 9245b7199439..374a4f6b1e23 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml @@ -28,7 +28,7 @@ properties: mps,fb-voltage-divider: description: An array of two integers containing the resistor values R1 and R2 of the feedback voltage divider in kilo ohms. - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array maxItems: 2 mps,switch-frequency-hz: diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml index c2e8c54e5311..f3fcfc8be72f 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml @@ -29,7 +29,7 @@ properties: properties: mps,switch-freq: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2, 3] default: 2 description: | @@ -51,14 +51,14 @@ properties: properties: mps,buck-softstart: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2, 3] description: | defines the soft start time of this buck, must be one of the following corresponding values 150us, 300us, 610us, 920us mps,buck-phase-delay: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2, 3] description: | defines the phase delay of this buck, must be one of the following diff --git a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml index 364b58730be2..6317daf76d1f 100644 --- a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml @@ -28,7 +28,7 @@ properties: patternProperties: "^vbuck[1-4]$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# unevaluatedProperties: false properties: diff --git a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml index 8cc413eb482d..d6b3b5a5c0b3 100644 --- a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml @@ -17,7 +17,7 @@ description: | patternProperties: "^buck_v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -27,7 +27,7 @@ patternProperties: "^ldo_v(ibr|rf12|usb|camio|efuse|xo22)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -37,7 +37,7 @@ patternProperties: "^ldo_v(rfck|emc|a12|a09|ufs|bbck)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -47,7 +47,7 @@ patternProperties: "^ldo_vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -57,7 +57,7 @@ patternProperties: "^ldo_vsram_(proc2|others|md|proc1|others_sshub)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -67,7 +67,7 @@ patternProperties: "^ldo_v(fe|bif|io)28$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -77,7 +77,7 @@ patternProperties: "^ldo_v(aud|io|aux|rf|m)18$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -87,7 +87,7 @@ patternProperties: "^ldo_vsim[12]$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml index 8a0931dc2f30..9c879bc3c360 100644 --- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml @@ -26,11 +26,11 @@ properties: patternProperties: "^buck[12]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# unevaluatedProperties: false "^ldo[123567]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# unevaluatedProperties: false required: diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml index 835b53302db8..3d469b8e9774 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml @@ -17,10 +17,10 @@ description: | Datasheet is available at https://www.nxp.com/docs/en/data-sheet/PCA9450DS.pdf -#The valid names for PCA9450 regulator nodes are: -#BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, -#LDO1, LDO2, LDO3, LDO4, LDO5 -#Note: Buck3 removed on PCA9450B and connect with Buck1 on PCA9450C. +# The valid names for PCA9450 regulator nodes are: +# BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, +# LDO1, LDO2, LDO3, LDO4, LDO5 +# Note: Buck3 removed on PCA9450B and connect with Buck1 on PCA9450C. properties: compatible: @@ -57,7 +57,7 @@ properties: properties: nxp,dvs-run-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 600000 maximum: 2187500 description: @@ -65,7 +65,7 @@ properties: dvs(dynamic voltage scaling) property. nxp,dvs-standby-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 600000 maximum: 2187500 description: diff --git a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml index aabf50f5b39e..894bdbca78a2 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml @@ -38,12 +38,6 @@ properties: description: Properties for single LDO regulator. - properties: - regulator-name: - pattern: "^ldo[1-4]$" - description: - should be "ldo1", ..., "ldo4" - unevaluatedProperties: false "^buck[1-7]$": @@ -53,13 +47,8 @@ properties: Properties for single BUCK regulator. properties: - regulator-name: - pattern: "^buck[1-7]$" - description: - should be "buck1", ..., "buck7" - nxp,ilim-ma: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 2100 maximum: 4500 deprecated: true @@ -75,7 +64,7 @@ properties: 4500 nxp,phase-shift: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 default: 0 enum: [ 0, 45, 90, 135, 180, 225, 270, 315 ] description: @@ -90,12 +79,6 @@ properties: description: Properties for single VSNVS regulator. - properties: - regulator-name: - pattern: "^vsnvs$" - description: - should be "vsnvs" - unevaluatedProperties: false additionalProperties: false @@ -109,7 +92,7 @@ additionalProperties: false examples: - | - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.yaml b/Documentation/devicetree/bindings/regulator/pfuze100.yaml index a26bbd68b729..67a30b23b92c 100644 --- a/Documentation/devicetree/bindings/regulator/pfuze100.yaml +++ b/Documentation/devicetree/bindings/regulator/pfuze100.yaml @@ -63,19 +63,19 @@ properties: patternProperties: "^sw([1-4]|[1-4][a-c]|[1-4][a-c][a-c])$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object "^vgen[1-6]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object "^vldo[1-4]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object "^(vsnvs|vref|vrefddr|swbst|coin|v33|vccsd)$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index 297a75069f60..b9498504ad79 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -75,9 +75,12 @@ properties: - qcom,pm8550ve-rpmh-regulators - qcom,pm8550vs-rpmh-regulators - qcom,pm8998-rpmh-regulators + - qcom,pmc8180-rpmh-regulators + - qcom,pmc8180c-rpmh-regulators - qcom,pmg1110-rpmh-regulators - qcom,pmi8998-rpmh-regulators - qcom,pmm8155au-rpmh-regulators + - qcom,pmm8654au-rpmh-regulators - qcom,pmr735a-rpmh-regulators - qcom,pmx55-rpmh-regulators - qcom,pmx65-rpmh-regulators @@ -105,18 +108,18 @@ properties: bob: type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# description: BOB regulator node. dependencies: - regulator-allow-set-load: ["regulator-allowed-modes"] + regulator-allow-set-load: [ regulator-allowed-modes ] patternProperties: "^(smps|ldo|lvs|bob)[0-9]+$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# description: smps/ldo regulator nodes(s). dependencies: - regulator-allow-set-load: ["regulator-allowed-modes"] + regulator-allow-set-load: [ regulator-allowed-modes ] required: - compatible @@ -144,6 +147,8 @@ allOf: compatible: enum: - qcom,pm6150l-rpmh-regulators + - qcom,pm8150l-rpmh-regulators + - qcom,pmc8180c-rpmh-regulators then: properties: vdd-bob-supply: @@ -232,6 +237,7 @@ allOf: compatible: enum: - qcom,pm8150-rpmh-regulators + - qcom,pmc8180-rpmh-regulators - qcom,pmm8155au-rpmh-regulators then: properties: @@ -248,18 +254,17 @@ allOf: properties: compatible: enum: - - qcom,pm8150l-rpmh-regulators + - qcom,pmm8654au-rpmh-regulators then: properties: - vdd-bob-supply: - description: BOB regulator parent supply phandle. - vdd-l1-l8-supply: true + vdd-l1-supply: true vdd-l2-l3-supply: true - vdd-l4-l5-l6-supply: true - vdd-l7-l11-supply: true - vdd-l9-l10-supply: true + vdd-l4-supply: true + vdd-l5-supply: true + vdd-l6-l7-supply: true + vdd-l8-l9-supply: true patternProperties: - "^vdd-s[1-8]-supply$": true + "^vdd-s[1-9]-supply$": true - if: properties: @@ -308,16 +313,15 @@ allOf: compatible: enum: - qcom,pm8550-rpmh-regulators - - qcom,pm8550ve-rpmh-regulators - - qcom,pm8550vs-rpmh-regulators then: properties: + vdd-l1-l4-l10-supply: true vdd-l2-l13-l14-supply: true vdd-l5-l16-supply: true vdd-l6-l7-supply: true vdd-l8-l9-supply: true patternProperties: - "^vdd-l([1-4]|1[0-7])-supply$": true + "^vdd-l(3|1[1-7])-supply$": true "^vdd-s[1-6]-supply$": true "^vdd-bob[1-2]-supply$": true @@ -325,6 +329,17 @@ allOf: properties: compatible: enum: + - qcom,pm8550ve-rpmh-regulators + - qcom,pm8550vs-rpmh-regulators + then: + patternProperties: + "^vdd-l[1-3]-supply$": true + "^vdd-s[1-6]-supply$": true + + - if: + properties: + compatible: + enum: - qcom,pm8998-rpmh-regulators then: properties: diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index 8c45f53212b1..a8ca8e0b27f8 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, s2 + For mp5496, s1, s2 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/raspberrypi,7inch-touchscreen-panel-regulator.yaml b/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml index 0ae25d119b6f..41678400e63f 100644 --- a/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml @@ -15,7 +15,7 @@ description: | and control the backlight. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index 53b81d8a2d41..e158c2d3d3f9 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -13,7 +13,7 @@ maintainers: properties: regulator-name: description: A string used as a descriptive name for regulator outputs - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string regulator-min-microvolt: description: smallest voltage consumers may set @@ -23,7 +23,7 @@ properties: regulator-microvolt-offset: description: Offset applied to voltages to compensate for voltage drops - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 regulator-min-microamp: description: smallest current consumers may set @@ -59,7 +59,7 @@ properties: description: ramp delay for regulator(in uV/us) For hardware which supports disabling ramp rate, it should be explicitly initialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 regulator-enable-ramp-delay: description: The time taken, in microseconds, for the supply rail to @@ -68,7 +68,7 @@ properties: required due to the combination of internal ramping of the regulator itself, and board design issues such as trace capacitance and load on the supply. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 regulator-settling-time-us: description: Settling time, in microseconds, for voltage change if regulator @@ -95,7 +95,7 @@ properties: description: initial operating mode. The set of possible operating modes depends on the capabilities of every hardware so each device binding documentation explains which values the regulator supports. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 regulator-allowed-modes: description: list of operating modes that software is allowed to configure @@ -103,12 +103,12 @@ properties: The set of possible operating modes depends on the capabilities of every hardware so each device binding document explains which values the regulator supports. - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array regulator-system-load: description: Load in uA present on regulator that is not captured by any consumer request. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 regulator-pull-down: description: Enable pull down resistor when the regulator is disabled. @@ -206,14 +206,14 @@ properties: 0: Disable active discharge. 1: Enable active discharge. Absence of this property will leave configuration to default. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] regulator-coupled-with: description: Regulators with which the regulator is coupled. The linkage is 2-way - all coupled regulators should be linked with each other. A regulator should not be coupled with its supplier. - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: maxItems: 1 @@ -221,7 +221,7 @@ properties: description: Array of maximum spread between voltages of coupled regulators in microvolts, each value in the array relates to the corresponding couple specified by the regulator-coupled-with property. - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array regulator-max-step-microvolt: description: Maximum difference between current and target voltages @@ -269,7 +269,7 @@ patternProperties: of possible operating modes depends on the capabilities of every hardware so the valid modes are documented on each regulator device tree binding document. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt4803.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt4803.yaml new file mode 100644 index 000000000000..6ceba022e550 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt4803.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt4803.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT4803 Boost Regulator + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + RT4803 is a boost regulator that's designed to provide the minimum output + voltage, even if the input voltage is lower than the required voltage. It + supports boost and auto bypass mode that depends on the difference between the + input and output voltage. If the input is lower than the output, mode will + transform to boost mode. Otherwise, turn on bypass switch to enter bypass mode. + + Datasheet is available at + https://www.richtek.com/assets/product_file/RT4803/DS4803-03.pdf + https://www.richtek.com/assets/product_file/RT4803A/DS4803A-06.pdf + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - richtek,rt4803 + + reg: + maxItems: 1 + + richtek,vsel-active-high: + type: boolean + description: Specify the VSEL register group is using when system is active + + regulator-allowed-modes: + description: | + Available operating mode + 1: Auto PFM/PWM + 2: Force PWM + items: + enum: [1, 2] + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@75 { + compatible = "richtek,rt4803"; + reg = <0x75>; + richtek,vsel-active-high; + regulator-name = "rt4803-regulator"; + regulator-min-microvolt = <2850000>; + regulator-max-microvolt = <4400000>; + regulator-allowed-modes = <1 2>; + regulator-always-on; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml new file mode 100644 index 000000000000..358297dd3fb7 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt5739.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT5739 Step-Down Buck Converter + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + The RT5739 is a step-down switching buck converter that can deliver the + programmable output voltage from 300mV to 1300mV with wide input voltage + supply of 2.5V to 5.5V. It can provide up to 3.5A continuous current + capability at over 80% high efficiency. + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - richtek,rt5739 + + reg: + maxItems: 1 + + enable-gpios: + maxItems: 1 + + richtek,vsel-active-high: + description: | + If property is present, use the 'VSEL1' register group for buck control. + Else, use the 'VSEL0' register group. This depends on external hardware + 'VSEL' pin connection. + type: boolean + + regulator-allowed-modes: + description: | + buck allowed operating mode + 0: Auto PFM/PWM mode + 1: Forced PWM mode + items: + enum: [0, 1] + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@50 { + compatible = "richtek,rt5739"; + reg = <0x50>; + enable-gpios = <&gpio26 1 GPIO_ACTIVE_HIGH>; + richtek,vsel-active-high; + regulator-name = "richtek,rt5739-buck"; + regulator-min-microvolt = <300000>; + regulator-max-microvolt = <1300000>; + regulator-allowed-modes = <0 1>; + regulator-boot-on; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml index e983d0e70c9b..b73762e151bb 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml @@ -32,7 +32,7 @@ properties: maxItems: 1 richtek,oc-level-select: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2, 3] description: | Over current level selection. Each respective value means the current @@ -40,7 +40,7 @@ properties: in chip default. richtek,ot-level-select: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2] description: | Over temperature level selection. Each respective value means the degree @@ -48,7 +48,7 @@ properties: default. richtek,pgdly-time-select: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2, 3] description: | Power good signal delay time selection. Each respective value means the @@ -57,7 +57,7 @@ properties: richtek,switch-freq-select: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2] description: | Buck switch frequency selection. Each respective value means 400KHz, diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml index a8ccb5cb8d77..446ec5127d1f 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml @@ -120,7 +120,7 @@ properties: lsw: description: load switch current regulator description. type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml index 027fab3dc181..cc4ceb32e9d6 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml @@ -56,7 +56,7 @@ patternProperties: PMIC "RUN" state voltage in uV when PMIC HW states are used. See comments below for bucks/LDOs which support this. 0 means regulator should be disabled at RUN state. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -67,7 +67,7 @@ patternProperties: keeps regulator enabled. BD71815 does not change voltage level when PMIC transitions to SNVS.SNVS voltage depends on the previous state (from which the PMIC transitioned to SNVS). - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -76,7 +76,7 @@ patternProperties: PMIC "SUSPEND" state voltage in uV when PMIC HW states are used. See comments below for bucks/LDOs which support this. 0 means regulator should be disabled at SUSPEND state. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -85,7 +85,7 @@ patternProperties: PMIC "LPSR" state voltage in uV when PMIC HW states are used. See comments below for bucks/LDOs which support this. 0 means regulator should be disabled at LPSR state. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml index 3cbe3b76ccee..d898800d6bca 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml @@ -52,7 +52,7 @@ patternProperties: description: PMIC default "RUN" state voltage in uV. See below table for bucks which support this. 0 means disabled. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -60,7 +60,7 @@ patternProperties: description: PMIC default "IDLE" state voltage in uV. See below table for bucks which support this. 0 means disabled. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -68,7 +68,7 @@ patternProperties: description: PMIC default "SUSPEND" state voltage in uV. See below table for bucks which support this. 0 means disabled. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -76,26 +76,26 @@ patternProperties: description: PMIC default "LPSR" state voltage in uV. See below table for bucks which support this. 0 means disabled. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 # Supported default DVS states: # buck | run | idle | suspend | lpsr - #-------------------------------------------------------------- + # -------------------------------------------------------------- # 1, 2, 6, and 7 | supported | supported | supported (*) - #-------------------------------------------------------------- + # -------------------------------------------------------------- # 3, 4, and 5 | supported (**) - #-------------------------------------------------------------- + # -------------------------------------------------------------- # - #(*) LPSR and SUSPEND states use same voltage but both states have own - # enable / - # disable settings. Voltage 0 can be specified for a state to make - # regulator disabled on that state. + # (*) LPSR and SUSPEND states use same voltage but both states have own + # enable / + # disable settings. Voltage 0 can be specified for a state to make + # regulator disabled on that state. # - #(**) All states use same voltage but have own enable / disable - # settings. Voltage 0 can be specified for a state to make - # regulator disabled on that state. + # (**) All states use same voltage but have own enable / disable + # settings. Voltage 0 can be specified for a state to make + # regulator disabled on that state. required: - regulator-name diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml index ab842817d847..29b350a4f88a 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml @@ -23,9 +23,9 @@ description: | if they are disabled at startup the voltage monitoring for LDO5/LDO6 will cause PMIC to reset. -#The valid names for BD71837 regulator nodes are: -#BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, BUCK7, BUCK8 -#LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7 +# The valid names for BD71837 regulator nodes are: +# BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, BUCK7, BUCK8 +# LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7 patternProperties: "^LDO[1-7]$": @@ -55,7 +55,7 @@ patternProperties: should be "buck1", ..., "buck8" rohm,dvs-run-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: @@ -63,7 +63,7 @@ patternProperties: bucks which support this. 0 means disabled. rohm,dvs-idle-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: @@ -71,7 +71,7 @@ patternProperties: bucks which support this. 0 means disabled. rohm,dvs-suspend-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml index 65fc3d15f693..7ba4ccf723d8 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml @@ -22,9 +22,9 @@ description: | not be disabled by driver at startup. If BUCK5 is disabled at startup the voltage monitoring for LDO5/LDO6 can cause PMIC to reset. -#The valid names for BD71847 regulator nodes are: -#BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6 -#LDO1, LDO2, LDO3, LDO4, LDO5, LDO6 +# The valid names for BD71847 regulator nodes are: +# BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6 +# LDO1, LDO2, LDO3, LDO4, LDO5, LDO6 patternProperties: "^LDO[1-6]$": @@ -54,7 +54,7 @@ patternProperties: should be "buck1", ..., "buck6" rohm,dvs-run-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: @@ -62,7 +62,7 @@ patternProperties: bucks which support this. 0 means disabled. rohm,dvs-idle-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: @@ -70,7 +70,7 @@ patternProperties: bucks which support this. 0 means disabled. rohm,dvs-suspend-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml index 89b8592db81d..f573128da06f 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml @@ -25,7 +25,7 @@ patternProperties: type: object description: Properties for single regulator. - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: rohm,ocw-fet-ron-micro-ohms: diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml index a6949a581cd1..ddaa112252e5 100644 --- a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml @@ -42,7 +42,7 @@ properties: reset-names: true allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml index c82f6f885d97..c863100f6e7d 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml @@ -14,7 +14,7 @@ description: | to supply ADC analog input switches. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: @@ -23,7 +23,7 @@ properties: - st,stm32mp1-booster st,syscfg: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: phandle to system configuration controller. vdda-supply: diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml index c1bf1f90490a..05f4ad2c7d3a 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml @@ -15,7 +15,7 @@ maintainers: - Fabrice Gasnier <fabrice.gasnier@foss.st.com> allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml index bd07b9c81570..7d53cfa2c288 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml @@ -26,7 +26,7 @@ patternProperties: "^(reg11|reg18|usb33)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml index 12aeddedde05..90c39275c150 100644 --- a/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml +++ b/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml @@ -19,7 +19,7 @@ description: | https://www.ti.com/lit/gpn/tps62360 allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml b/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml index dd7a2f92634c..3b16a25ba3b8 100644 --- a/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml @@ -15,7 +15,7 @@ description: | controller is also embedded. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml index 7b4ae5d23351..011819c10988 100644 --- a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml +++ b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml @@ -21,19 +21,19 @@ properties: wlf,ldoena: description: GPIO specifier for the GPIO controlling LDOENA. - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 ldo1: description: Initial data for the LDO1 regulator. - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object micvdd: description: Initial data for the MICVDD regulator. - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object additionalProperties: true diff --git a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml index 11cb42a3fdd1..3100cb870170 100644 --- a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/remoteproc/amlogic,meson-mx-ao-arc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/remoteproc/amlogic,meson-mx-ao-arc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson AO ARC Remote Processor diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml index ae2eab4452dd..0c3910f152d1 100644 --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/remoteproc/fsl,imx-rproc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/remoteproc/fsl,imx-rproc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NXP i.MX Co-Processor diff --git a/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml b/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml index 85b1e43cab08..8b55dbd909b0 100644 --- a/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ingenic,vpu.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/remoteproc/ingenic,vpu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/remoteproc/ingenic,vpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Ingenic Video Processing Unit diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml index 15e6851e1ff8..7b43ad3daa56 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml @@ -15,7 +15,7 @@ description: properties: $nodename: - const: "glink-edge" + const: glink-edge apr: $ref: /schemas/soc/qcom/qcom,apr.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml index 6e6e69ad9cd7..588b010b2a9e 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml @@ -157,6 +157,7 @@ properties: mba: type: object + additionalProperties: false description: MBA reserved region (prefer using memory-region with two items) properties: @@ -167,6 +168,7 @@ properties: mpss: type: object + additionalProperties: false description: MPSS reserved region (prefer using memory-region with two items) properties: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml index 7ec8a6b6682c..02c85b420c1a 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,smd-edge.yaml @@ -21,7 +21,7 @@ description: properties: $nodename: - const: "smd-edge" + const: smd-edge apr: $ref: /schemas/soc/qcom/qcom,apr.yaml# diff --git a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml index 7e0275d31a3c..4bea679a0f61 100644 --- a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/remoteproc/renesas,rcar-rproc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/remoteproc/renesas,rcar-rproc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas R-Car remote processor controller diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 66b1e3efdaa3..959a56f1b6c7 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/remoteproc/st,stm32-rproc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/remoteproc/st,stm32-rproc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 remote processor controller @@ -29,7 +29,7 @@ properties: st,syscfg-holdboot: description: remote processor reset hold boot - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: Phandle of syscon block @@ -39,7 +39,7 @@ properties: st,syscfg-tz: description: Reference to the system configuration which holds the RCC trust zone mode - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: Phandle of syscon block @@ -72,9 +72,9 @@ properties: ready for shutdown - description: | A channel (d) used by the local proc to notify the remote proc that it - has to stop interprocessor communnication. + has to stop interprocessor communication. Unidirectional channel: - - from local to remote, where ACK from the remote means that communnication + - from local to remote, where ACK from the remote means that communication as been stopped on the remote side. minItems: 1 @@ -95,7 +95,7 @@ properties: (see ../reserved-memory/reserved-memory.txt) st,syscfg-pdds: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array description: | Reference to the system configuration which holds the remote items: @@ -105,7 +105,7 @@ properties: - description: The field mask of the PDDS selection st,syscfg-m4-state: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array description: | Reference to the tamp register which exposes the Cortex-M4 state. items: @@ -115,7 +115,7 @@ properties: - description: The field mask of the Cortex-M4 state st,syscfg-rsc-tbl: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array description: | Reference to the tamp register which references the Cortex-M4 resource table address. diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index fb9605f0655b..fcc3db97fe8f 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -21,6 +21,9 @@ description: | called "Single-CPU" mode, where only Core0 is used, but with ability to use Core1's TCMs as well. + AM62 SoC family support a single R5F core only which runs Device Manager + firmware and can also be used as a remote processor with IPC communication. + Each Dual-Core R5F sub-system is represented as a single DTS node representing the cluster, with a pair of child DT nodes representing the individual R5F cores. Each node has a number of required or optional @@ -34,10 +37,11 @@ properties: compatible: enum: + - ti,am62-r5fss + - ti,am64-r5fss - ti,am654-r5fss - - ti,j721e-r5fss - ti,j7200-r5fss - - ti,am64-r5fss + - ti,j721e-r5fss - ti,j721s2-r5fss power-domains: @@ -64,10 +68,17 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 description: | Configuration Mode for the Dual R5F cores within the R5F cluster. - Should be either a value of 1 (LockStep mode) or 0 (Split mode) on + For most SoCs (AM65x, J721E, J7200, J721s2), + It should be either a value of 1 (LockStep mode) or 0 (Split mode) on most SoCs (AM65x, J721E, J7200, J721s2), default is LockStep mode if - omitted; and should be either a value of 0 (Split mode) or 2 - (Single-CPU mode) on AM64x SoCs, default is Split mode if omitted. + omitted. + For AM64x SoCs, + It should be either a value of 0 (Split mode) or 2 (Single-CPU mode) and + default is Split mode if omitted. + For AM62x SoCs, + It should be set as 3 (Single-Core mode) which is also the default if + omitted. + # R5F Processor Child Nodes: # ========================== @@ -80,7 +91,9 @@ patternProperties: node representing a TI instantiation of the Arm Cortex R5F core. There are some specific integration differences for the IP like the usage of a Region Address Translator (RAT) for translating the larger SoC bus - addresses into a 32-bit address space for the processor. + addresses into a 32-bit address space for the processor. For AM62x, + the R5F Sub-System device node should only define one R5F child node + as it has only one core available. Each R5F core has an associated 64 KB of Tightly-Coupled Memory (TCM) internal memories split between two banks - TCMA and TCMB (further @@ -100,10 +113,11 @@ patternProperties: properties: compatible: enum: + - ti,am62-r5f + - ti,am64-r5f - ti,am654-r5f - - ti,j721e-r5f - ti,j7200-r5f - - ti,am64-r5f + - ti,j721e-r5f - ti,j721s2-r5f reg: @@ -208,19 +222,39 @@ patternProperties: unevaluatedProperties: false -if: - properties: - compatible: - enum: - - ti,am64-r5fss -then: - properties: - ti,cluster-mode: - enum: [0, 2] -else: - properties: - ti,cluster-mode: - enum: [0, 1] +allOf: + - if: + properties: + compatible: + enum: + - ti,am64-r5fss + then: + properties: + ti,cluster-mode: + enum: [0, 2] + + - if: + properties: + compatible: + enum: + - ti,am654-r5fss + - ti,j7200-r5fss + - ti,j721e-r5fss + - ti,j721s2-r5fss + then: + properties: + ti,cluster-mode: + enum: [0, 1] + + - if: + properties: + compatible: + enum: + - ti,am62-r5fss + then: + properties: + ti,cluster-mode: + enum: [3] required: - compatible diff --git a/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml index a924fcfca085..c591ec37d7e8 100644 --- a/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml @@ -16,7 +16,7 @@ maintainers: - David Brazdil <dbrazdil@google.com> allOf: - - $ref: "reserved-memory.yaml" + - $ref: reserved-memory.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml index b1b0421a4255..e2ace3df942a 100644 --- a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml @@ -14,7 +14,7 @@ description: On Tegra210, firmware passes a binary representation of the EMC frequency table via a reserved memory region. allOf: - - $ref: "reserved-memory.yaml" + - $ref: reserved-memory.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/reserved-memory/phram.yaml b/Documentation/devicetree/bindings/reserved-memory/phram.yaml index 6c4db28015f1..65c7cacf9be4 100644 --- a/Documentation/devicetree/bindings/reserved-memory/phram.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/phram.yaml @@ -17,8 +17,8 @@ maintainers: - Vincent Whitchurch <vincent.whitchurch@axis.com> allOf: - - $ref: "reserved-memory.yaml" - - $ref: "/schemas/mtd/mtd.yaml" + - $ref: reserved-memory.yaml + - $ref: /schemas/mtd/mtd.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml index df1b5e0ed3f4..610f8ef37e8d 100644 --- a/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reserved-memory/qcom,cmd-db.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reserved-memory/qcom,cmd-db.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Command DB @@ -20,7 +20,7 @@ maintainers: - Bjorn Andersson <bjorn.andersson@linaro.org> allOf: - - $ref: "reserved-memory.yaml" + - $ref: reserved-memory.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml index 08eb10c25821..bab982f00485 100644 --- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reserved-memory/qcom,rmtfs-mem.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reserved-memory/qcom,rmtfs-mem.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Remote File System Memory @@ -15,7 +15,7 @@ maintainers: - Bjorn Andersson <bjorn.andersson@linaro.org> allOf: - - $ref: "reserved-memory.yaml" + - $ref: reserved-memory.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml b/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml index 0391871cf44d..45cc39ecc9f8 100644 --- a/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/ramoops.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reserved-memory/ramoops.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reserved-memory/ramoops.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Ramoops oops/panic logger @@ -27,7 +27,7 @@ maintainers: - Kees Cook <keescook@chromium.org> allOf: - - $ref: "reserved-memory.yaml" + - $ref: reserved-memory.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml b/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml index 47696073b665..457de0920cd1 100644 --- a/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml @@ -10,7 +10,7 @@ maintainers: - devicetree-spec@vger.kernel.org allOf: - - $ref: "reserved-memory.yaml" + - $ref: reserved-memory.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml index 704a502adc5d..bc1d284785e1 100644 --- a/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml +++ b/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/amlogic,meson-axg-audio-arb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/amlogic,meson-axg-audio-arb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic audio memory arbiter controller diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml index 98db2aa74dc8..d3fdee89d4f8 100644 --- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml +++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/amlogic,meson-reset.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/amlogic,meson-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson SoC Reset Controller diff --git a/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml b/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml index f0aca744388c..1f40b654f6a2 100644 --- a/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml +++ b/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Manivannan Sadhasivam <mani@kernel.org> %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/bitmain,bm1880-reset.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/bitmain,bm1880-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Bitmain BM1880 SoC Reset Controller diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml index 560cf6522cb8..00150b93fca0 100644 --- a/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml +++ b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/brcm,bcm6345-reset.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/brcm,bcm6345-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: BCM6345 reset controller diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml b/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml index dfce6738b033..34cfc642d808 100644 --- a/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml +++ b/Documentation/devicetree/bindings/reset/brcm,bcm7216-pcie-sata-rescal.yaml @@ -2,8 +2,8 @@ # Copyright 2020 Broadcom %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/brcm,bcm7216-pcie-sata-rescal.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/brcm,bcm7216-pcie-sata-rescal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: BCM7216 RESCAL reset controller diff --git a/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml b/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml index e00efa88a198..b115b86e2fe6 100644 --- a/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml +++ b/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/brcm,brcmstb-reset.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/brcm,brcmstb-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Broadcom STB SW_INIT-style reset controller diff --git a/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml b/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml index d71d0f0a13ee..dc86568bfd75 100644 --- a/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml +++ b/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml @@ -2,8 +2,8 @@ # Copyright 2015 Antoine Tenart <atenart@kernel.org> %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/marvell,berlin2-reset.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/marvell,berlin2-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Marvell Berlin reset controller diff --git a/Documentation/devicetree/bindings/reset/microchip,rst.yaml b/Documentation/devicetree/bindings/reset/microchip,rst.yaml index 81cd8c837623..f2da0693b05a 100644 --- a/Documentation/devicetree/bindings/reset/microchip,rst.yaml +++ b/Documentation/devicetree/bindings/reset/microchip,rst.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/microchip,rst.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/microchip,rst.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Microchip Sparx5 Switch Reset Controller @@ -36,7 +36,7 @@ properties: const: 1 cpu-syscon: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: syscon used to access CPU reset required: diff --git a/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml b/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml index 9be60e55cd71..47f8525a9b38 100644 --- a/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml +++ b/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml @@ -2,8 +2,8 @@ # Copyright 2015 Alban Bedel <albeu@free.fr> %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/qca,ar7100-reset.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/qca,ar7100-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Atheros AR7xxx/AR9XXX reset controller diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.yaml b/Documentation/devicetree/bindings/reset/renesas,rst.yaml index 0d1b89e2fe9c..e7e487247751 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rst.yaml +++ b/Documentation/devicetree/bindings/reset/renesas,rst.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/renesas,rst.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/renesas,rst.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas R-Car and RZ/G Reset Controller diff --git a/Documentation/devicetree/bindings/reset/sunplus,reset.yaml b/Documentation/devicetree/bindings/reset/sunplus,reset.yaml index f24646ba9761..205918ce324c 100644 --- a/Documentation/devicetree/bindings/reset/sunplus,reset.yaml +++ b/Documentation/devicetree/bindings/reset/sunplus,reset.yaml @@ -2,8 +2,8 @@ # Copyright (C) Sunplus Co., Ltd. 2021 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/reset/sunplus,reset.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/reset/sunplus,reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Sunplus SoC Reset Controller diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index 001931d526ec..25d6e8dbffb8 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -35,6 +35,7 @@ properties: - sifive,e7 - sifive,e71 - sifive,rocket0 + - sifive,s7 - sifive,u5 - sifive,u54 - sifive,u7 @@ -65,6 +66,7 @@ properties: - riscv,sv32 - riscv,sv39 - riscv,sv48 + - riscv,sv57 - riscv,none riscv,cbom-block-size: @@ -72,6 +74,11 @@ properties: description: The blocksize in bytes for the Zicbom cache operations. + riscv,cboz-block-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The blocksize in bytes for the Zicboz cache operations. + riscv,isa: description: Identifies the specific RISC-V instruction set architecture diff --git a/Documentation/devicetree/bindings/riscv/sunxi.yaml b/Documentation/devicetree/bindings/riscv/sunxi.yaml index 9edb5e5992b1..b36e313e13a6 100644 --- a/Documentation/devicetree/bindings/riscv/sunxi.yaml +++ b/Documentation/devicetree/bindings/riscv/sunxi.yaml @@ -64,6 +64,11 @@ properties: - const: widora,mangopi-mq-pro - const: allwinner,sun20i-d1 + - description: MangoPi MQ-R board + items: + - const: widora,mangopi-mq-r-f133 + - const: allwinner,sun20i-d1s + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml index 09c6c906b1f9..457a6e43d810 100644 --- a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml +++ b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/rng/amlogic,meson-rng.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/rng/amlogic,meson-rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson Random number generator diff --git a/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml index a00e9bc8b609..827983008ecf 100644 --- a/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml +++ b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/rng/brcm,iproc-rng200.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/rng/brcm,iproc-rng200.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: HWRNG support for the iproc-rng200 driver diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml index bb32491ee8ae..7e8dc62e5d3a 100644 --- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/rng/mtk-rng.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/rng/mtk-rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek Random number generator diff --git a/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml b/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml index e749818fc193..06a6791b3356 100644 --- a/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml +++ b/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml @@ -25,7 +25,7 @@ properties: maxItems: 1 ti,syscon-sa-cfg: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: | Phandle to syscon node of the SA configuration registers. These registers are shared between HWRNG and crypto drivers. diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml index dede49431733..054e1e397fc8 100644 --- a/Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Allwinner A10 RTC allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# maintainers: - Chen-Yu Tsai <wens@csie.org> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml index 04947e166cef..4531eec568a6 100644 --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml @@ -61,7 +61,7 @@ properties: - the Internal Oscillator, at index 2. allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml index 0e5f0fcc26b0..4d2bef15fb7a 100644 --- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Atmel AT91 RTC allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# maintainers: - Alexandre Belloni <alexandre.belloni@bootlin.com> diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml b/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml index b5cd20e89daf..b80b85c394ac 100644 --- a/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml +++ b/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Atmel AT91 RTT allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# maintainers: - Alexandre Belloni <alexandre.belloni@bootlin.com> diff --git a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml index c6c57636c729..c5e5c5aec74e 100644 --- a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml +++ b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml @@ -15,7 +15,7 @@ description: optionally generate RTC alarm interrupts. allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml index 056d42daae06..b1c1a0e21318 100644 --- a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml +++ b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml @@ -38,8 +38,8 @@ properties: clock-names: items: - - const: "PCLK" - - const: "EXTCLK" + - const: PCLK + - const: EXTCLK required: - compatible diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml index dd6eebf06ea6..27a9de10f0af 100644 --- a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml +++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Microchip RV-3032 RTC allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# maintainers: - Alexandre Belloni <alexandre.belloni@bootlin.com> diff --git a/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml b/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml index 585c185d1eb3..af4a31cd0954 100644 --- a/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/mstar,msc313-rtc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Mstar MSC313e RTC allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# maintainers: - Daniel Palmer <daniel@0x0f.com> diff --git a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml index 7a1857f5caa8..4f9b5604acd9 100644 --- a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml +++ b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: NUVOTON NCT3018Y Real Time Clock allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# maintainers: - Medad CChien <ctcchien@nuvoton.com> diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml index a1148eb22c24..bcb230027622 100644 --- a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: NXP PCF2127 Real Time Clock allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# maintainers: - Alexandre Belloni <alexandre.belloni@bootlin.com> diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml b/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml index 4f263fa6fd0d..a14b52178c4b 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Real Time Clock of the i.MX SoCs allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# maintainers: - Philippe Reynes <tremyfr@gmail.com> diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml index 2d1a30663d72..e50131c26dc6 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: i.MX53 Secure Real Time Clock (SRTC) allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# maintainers: - Patrick Bruenn <p.bruenn@beckhoff.com> diff --git a/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml b/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml index b04b87ef6f33..a16c355dcd11 100644 --- a/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml @@ -34,8 +34,8 @@ properties: interrupt-names: items: - - const: 'rtc 1Hz' - - const: 'rtc alarm' + - const: rtc 1Hz + - const: rtc alarm required: - compatible diff --git a/Documentation/devicetree/bindings/rtc/snvs-rtc.txt b/Documentation/devicetree/bindings/rtc/snvs-rtc.txt deleted file mode 100644 index fb61ed77ada3..000000000000 --- a/Documentation/devicetree/bindings/rtc/snvs-rtc.txt +++ /dev/null @@ -1 +0,0 @@ -See Documentation/devicetree/bindings/crypto/fsl-sec4.txt for details. diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml index 9e66ed33cda4..4703083d1f11 100644 --- a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml @@ -32,7 +32,7 @@ properties: maxItems: 1 st,syscfg: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: minItems: 3 maxItems: 3 diff --git a/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml b/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml index d995ef04a6eb..df5b4f77f6fb 100644 --- a/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/ti,k3-rtc.yaml @@ -13,7 +13,7 @@ description: | This RTC appears in the AM62x family of SoCs. allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml index eb75861c28c3..a3603e638c37 100644 --- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml @@ -15,7 +15,7 @@ description: | possibly an interrupt line. allOf: - - $ref: "rtc.yaml#" + - $ref: rtc.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml index 3cbdde85ed71..01ec45b3b406 100644 --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/amlogic,meson-uart.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/amlogic,meson-uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson SoC UART Serial Interface @@ -34,6 +34,11 @@ properties: - amlogic,meson-gx-uart - amlogic,meson-s4-uart - const: amlogic,meson-ao-uart + - description: Always-on power domain UART controller on G12A SoCs + items: + - const: amlogic,meson-g12a-uart + - const: amlogic,meson-gx-uart + - const: amlogic,meson-ao-uart - description: Everything-Else power domain UART controller enum: - amlogic,meson6-uart @@ -41,6 +46,10 @@ properties: - amlogic,meson8b-uart - amlogic,meson-gx-uart - amlogic,meson-s4-uart + - description: Everything-Else power domain UART controller on G12A SoCs + items: + - const: amlogic,meson-g12a-uart + - const: amlogic,meson-gx-uart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml index 4cbe76e1715b..40414247d61a 100644 --- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml @@ -49,6 +49,24 @@ properties: reg: maxItems: 1 + clocks: + maxItems: 2 + + clock-names: + items: + - const: ipg + - const: per + + dmas: + items: + - description: DMA controller phandle and request line for RX + - description: DMA controller phandle and request line for TX + + dma-names: + items: + - const: rx + - const: tx + interrupts: maxItems: 1 @@ -86,12 +104,16 @@ properties: required: - compatible - reg + - clocks + - clock-names - interrupts unevaluatedProperties: false examples: - | + #include <dt-bindings/clock/imx5-clock.h> + aliases { serial0 = &uart1; }; @@ -100,6 +122,11 @@ examples: compatible = "fsl,imx51-uart", "fsl,imx21-uart"; reg = <0x73fbc000 0x4000>; interrupts = <31>; + clocks = <&clks IMX5_CLK_UART1_IPG_GATE>, + <&clks IMX5_CLK_UART1_PER_GATE>; + clock-names = "ipg", "per"; + dmas = <&sdma 18 4 1>, <&sdma 19 4 2>; + dma-names = "rx", "tx"; uart-has-rtscts; fsl,dte-mode; }; diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index ab81722293d3..93062403276b 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -65,6 +65,9 @@ properties: - const: rx - const: tx + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/serial/mediatek,uart.yaml b/Documentation/devicetree/bindings/serial/mediatek,uart.yaml index fe098d98af6e..303d02ca4e1b 100644 --- a/Documentation/devicetree/bindings/serial/mediatek,uart.yaml +++ b/Documentation/devicetree/bindings/serial/mediatek,uart.yaml @@ -45,6 +45,7 @@ properties: - mediatek,mt8188-uart - mediatek,mt8192-uart - mediatek,mt8195-uart + - mediatek,mt8365-uart - mediatek,mt8516-uart - const: mediatek,mt6577-uart diff --git a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml index 05a6999808d1..dd33794b3534 100644 --- a/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml +++ b/Documentation/devicetree/bindings/serial/qcom,serial-geni-qcom.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/qcom,serial-geni-qcom.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/qcom,serial-geni-qcom.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Geni based QUP UART interface diff --git a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml index 12d0fa34f9f9..3fc2601f1338 100644 --- a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/renesas,em-uart.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/renesas,em-uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas EMMA Mobile UART Interface diff --git a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml index afedb6edfc34..1c7f1276aed6 100644 --- a/Documentation/devicetree/bindings/serial/renesas,hscif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,hscif.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/renesas,hscif.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/renesas,hscif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas High Speed Serial Communication Interface with FIFO (HSCIF) diff --git a/Documentation/devicetree/bindings/serial/renesas,sci.yaml b/Documentation/devicetree/bindings/serial/renesas,sci.yaml index dc445b327e0b..9f7305200c47 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,sci.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/renesas,sci.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/renesas,sci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas Serial Communication Interface diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index 1989bd67d04e..99030fc18c45 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/renesas,scif.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/renesas,scif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas Serial Communication Interface with FIFO (SCIF) @@ -92,7 +92,7 @@ properties: - description: Error interrupt - description: Receive buffer full interrupt - description: Transmit buffer empty interrupt - - description: Transmit End interrupt + - description: Break interrupt - items: - description: Error interrupt - description: Receive buffer full interrupt @@ -107,7 +107,7 @@ properties: - const: eri - const: rxi - const: txi - - const: tei + - const: bri - items: - const: eri - const: rxi diff --git a/Documentation/devicetree/bindings/serial/renesas,scifa.yaml b/Documentation/devicetree/bindings/serial/renesas,scifa.yaml index 4c3b5e7270da..499507678cdf 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scifa.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scifa.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/renesas,scifa.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/renesas,scifa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas Serial Communications Interface with FIFO A (SCIFA) diff --git a/Documentation/devicetree/bindings/serial/renesas,scifb.yaml b/Documentation/devicetree/bindings/serial/renesas,scifb.yaml index 2f7cbbb48960..810d8a991fdd 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scifb.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scifb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/renesas,scifb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/renesas,scifb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas Serial Communications Interface with FIFO B (SCIFB) diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml index c9231e501f1f..ea277560a596 100644 --- a/Documentation/devicetree/bindings/serial/serial.yaml +++ b/Documentation/devicetree/bindings/serial/serial.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/serial.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/serial.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Serial Interface Generic diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 2becdfab4f15..3862411c77b5 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -68,12 +68,12 @@ properties: - const: apb_pclk dmas: - minItems: 2 + maxItems: 2 dma-names: items: - - const: rx - const: tx + - const: rx snps,uart-16550-compatible: description: reflects the value of UART_16550_COMPATIBLE configuration diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.yaml b/Documentation/devicetree/bindings/serial/sprd-uart.yaml index da0e2745b5fc..28ff77aa86c8 100644 --- a/Documentation/devicetree/bindings/serial/sprd-uart.yaml +++ b/Documentation/devicetree/bindings/serial/sprd-uart.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Unisoc Inc. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/sprd-uart.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/sprd-uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Spreadtrum serial UART diff --git a/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml b/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml index ea1e637661c7..7d0a4bcb88e9 100644 --- a/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml +++ b/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml @@ -2,8 +2,8 @@ # Copyright (C) Sunplus Co., Ltd. 2021 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/serial/sunplus,sp7021-uart.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/serial/sunplus,sp7021-uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Sunplus SoC SP7021 UART Controller diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml index c3c599096353..cd06865e1f2a 100644 --- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/amlogic/amlogic,canvas.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/amlogic/amlogic,canvas.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Canvas Video Lookup Table diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml new file mode 100644 index 000000000000..77c281153010 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/amlogic/amlogic,meson-gx-clk-measure.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Internal Clock Measurer + +description: + The Amlogic SoCs contains an IP to measure the internal clocks. + The precision is multiple of MHz, useful to debug the clock states. + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +properties: + compatible: + enum: + - amlogic,meson-gx-clk-measure + - amlogic,meson8-clk-measure + - amlogic,meson8b-clk-measure + - amlogic,meson-axg-clk-measure + - amlogic,meson-g12a-clk-measure + - amlogic,meson-sm1-clk-measure + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + clock-measure@8758 { + compatible = "amlogic,meson-gx-clk-measure"; + reg = <0x8758 0x10>; + }; diff --git a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt deleted file mode 100644 index 3dd563cec794..000000000000 --- a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt +++ /dev/null @@ -1,21 +0,0 @@ -Amlogic Internal Clock Measurer -=============================== - -The Amlogic SoCs contains an IP to measure the internal clocks. -The precision is multiple of MHz, useful to debug the clock states. - -Required properties: -- compatible: Shall contain one of the following : - "amlogic,meson-gx-clk-measure" for GX SoCs - "amlogic,meson8-clk-measure" for Meson8 SoCs - "amlogic,meson8b-clk-measure" for Meson8b SoCs - "amlogic,meson-axg-clk-measure" for AXG SoCs - "amlogic,meson-g12a-clk-measure" for G12a SoCs - "amlogic,meson-sm1-clk-measure" for SM1 SoCs -- reg: base address and size of the Clock Measurer register space. - -Example: - clock-measure@8758 { - compatible = "amlogic,meson-gx-clk-measure"; - reg = <0x0 0x8758 0x0 0x10>; - }; diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml new file mode 100644 index 000000000000..ec888f48cac8 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml @@ -0,0 +1,162 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PowerQUICC CPM QUICC Multichannel Controller (QMC) + +maintainers: + - Herve Codina <herve.codina@bootlin.com> + +description: + The QMC (QUICC Multichannel Controller) emulates up to 64 channels within one + serial controller using the same TDM physical interface routed from TSA. + +properties: + compatible: + items: + - enum: + - fsl,mpc885-scc-qmc + - fsl,mpc866-scc-qmc + - const: fsl,cpm1-scc-qmc + + reg: + items: + - description: SCC (Serial communication controller) register base + - description: SCC parameter ram base + - description: Dual port ram base + + reg-names: + items: + - const: scc_regs + - const: scc_pram + - const: dpram + + interrupts: + maxItems: 1 + description: SCC interrupt line in the CPM interrupt controller + + fsl,tsa-serial: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to TSA node + - enum: [1, 2, 3] + description: | + TSA serial interface (dt-bindings/soc/cpm1-fsl,tsa.h defines these + values) + - 1: SCC2 + - 2: SCC3 + - 3: SCC4 + description: + Should be a phandle/number pair. The phandle to TSA node and the TSA + serial interface to use. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + '^channel@([0-9]|[1-5][0-9]|6[0-3])$': + description: + A channel managed by this controller + type: object + + properties: + reg: + minimum: 0 + maximum: 63 + description: + The channel number + + fsl,operational-mode: + $ref: /schemas/types.yaml#/definitions/string + enum: [transparent, hdlc] + default: transparent + description: | + The channel operational mode + - hdlc: The channel handles HDLC frames + - transparent: The channel handles raw data without any processing + + fsl,reverse-data: + $ref: /schemas/types.yaml#/definitions/flag + description: + The bit order as seen on the channels is reversed, + transmitting/receiving the MSB of each octet first. + This flag is used only in 'transparent' mode. + + fsl,tx-ts-mask: + $ref: /schemas/types.yaml#/definitions/uint64 + description: + Channel assigned Tx time-slots within the Tx time-slots routed by the + TSA to this cell. + + fsl,rx-ts-mask: + $ref: /schemas/types.yaml#/definitions/uint64 + description: + Channel assigned Rx time-slots within the Rx time-slots routed by the + TSA to this cell. + + required: + - reg + - fsl,tx-ts-mask + - fsl,rx-ts-mask + +required: + - compatible + - reg + - reg-names + - interrupts + - fsl,tsa-serial + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/soc/cpm1-fsl,tsa.h> + + qmc@a60 { + compatible = "fsl,mpc885-scc-qmc", "fsl,cpm1-scc-qmc"; + reg = <0xa60 0x20>, + <0x3f00 0xc0>, + <0x2000 0x1000>; + reg-names = "scc_regs", "scc_pram", "dpram"; + interrupts = <27>; + interrupt-parent = <&CPM_PIC>; + + #address-cells = <1>; + #size-cells = <0>; + + fsl,tsa-serial = <&tsa FSL_CPM_TSA_SCC4>; + + channel@16 { + /* Ch16 : First 4 even TS from all routed from TSA */ + reg = <16>; + fsl,mode = "transparent"; + fsl,reverse-data; + fsl,tx-ts-mask = <0x00000000 0x000000aa>; + fsl,rx-ts-mask = <0x00000000 0x000000aa>; + }; + + channel@17 { + /* Ch17 : First 4 odd TS from all routed from TSA */ + reg = <17>; + fsl,mode = "transparent"; + fsl,reverse-data; + fsl,tx-ts-mask = <0x00000000 0x00000055>; + fsl,rx-ts-mask = <0x00000000 0x00000055>; + }; + + channel@19 { + /* Ch19 : 8 TS (TS 8..15) from all routed from TSA */ + reg = <19>; + fsl,mode = "hdlc"; + fsl,tx-ts-mask = <0x00000000 0x0000ff00>; + fsl,rx-ts-mask = <0x00000000 0x0000ff00>; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml new file mode 100644 index 000000000000..7e51c639a79a --- /dev/null +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml @@ -0,0 +1,205 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,cpm1-tsa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PowerQUICC CPM Time-slot assigner (TSA) controller + +maintainers: + - Herve Codina <herve.codina@bootlin.com> + +description: + The TSA is the time-slot assigner that can be found on some PowerQUICC SoC. + Its purpose is to route some TDM time-slots to other internal serial + controllers. + +properties: + compatible: + items: + - enum: + - fsl,mpc885-tsa + - fsl,mpc866-tsa + - const: fsl,cpm1-tsa + + reg: + items: + - description: SI (Serial Interface) register base + - description: SI RAM base + + reg-names: + items: + - const: si_regs + - const: si_ram + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + '^tdm@[0-1]$': + description: + The TDM managed by this controller + type: object + + additionalProperties: false + + properties: + reg: + minimum: 0 + maximum: 1 + description: + The TDM number for this TDM, 0 for TDMa and 1 for TDMb + + fsl,common-rxtx-pins: + $ref: /schemas/types.yaml#/definitions/flag + description: + The hardware can use four dedicated pins for Tx clock, Tx sync, Rx + clock and Rx sync or use only two pins, Tx/Rx clock and Tx/Rx sync. + Without the 'fsl,common-rxtx-pins' property, the four pins are used. + With the 'fsl,common-rxtx-pins' property, two pins are used. + + clocks: + minItems: 2 + items: + - description: External clock connected to L1RSYNC pin + - description: External clock connected to L1RCLK pin + - description: External clock connected to L1TSYNC pin + - description: External clock connected to L1TCLK pin + + clock-names: + minItems: 2 + items: + - const: l1rsync + - const: l1rclk + - const: l1tsync + - const: l1tclk + + fsl,rx-frame-sync-delay-bits: + enum: [0, 1, 2, 3] + default: 0 + description: | + Receive frame sync delay in number of bits. + Indicates the delay between the Rx sync and the first bit of the Rx + frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay. + + fsl,tx-frame-sync-delay-bits: + enum: [0, 1, 2, 3] + default: 0 + description: | + Transmit frame sync delay in number of bits. + Indicates the delay between the Tx sync and the first bit of the Tx + frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits delay. + + fsl,clock-falling-edge: + $ref: /schemas/types.yaml#/definitions/flag + description: + Data is sent on falling edge of the clock (and received on the rising + edge). If 'clock-falling-edge' is not present, data is sent on the + rising edge (and received on the falling edge). + + fsl,fsync-rising-edge: + $ref: /schemas/types.yaml#/definitions/flag + description: + Frame sync pulses are sampled with the rising edge of the channel + clock. If 'fsync-rising-edge' is not present, pulses are sampled with + the falling edge. + + fsl,double-speed-clock: + $ref: /schemas/types.yaml#/definitions/flag + description: + The channel clock is twice the data rate. + + patternProperties: + '^fsl,[rt]x-ts-routes$': + $ref: /schemas/types.yaml#/definitions/uint32-matrix + description: | + A list of tuple that indicates the Tx or Rx time-slots routes. + items: + items: + - description: + The number of time-slots + minimum: 1 + maximum: 64 + - description: | + The source (Tx) or destination (Rx) serial interface + (dt-bindings/soc/cpm1-fsl,tsa.h defines these values) + - 0: No destination + - 1: SCC2 + - 2: SCC3 + - 3: SCC4 + - 4: SMC1 + - 5: SMC2 + enum: [0, 1, 2, 3, 4, 5] + minItems: 1 + maxItems: 64 + + allOf: + # If fsl,common-rxtx-pins is present, only 2 clocks are needed. + # Else, the 4 clocks must be present. + - if: + required: + - fsl,common-rxtx-pins + then: + properties: + clocks: + maxItems: 2 + clock-names: + maxItems: 2 + else: + properties: + clocks: + minItems: 4 + clock-names: + minItems: 4 + + required: + - reg + - clocks + - clock-names + +required: + - compatible + - reg + - reg-names + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/soc/cpm1-fsl,tsa.h> + + tsa@ae0 { + compatible = "fsl,mpc885-tsa", "fsl,cpm1-tsa"; + reg = <0xae0 0x10>, + <0xc00 0x200>; + reg-names = "si_regs", "si_ram"; + + #address-cells = <1>; + #size-cells = <0>; + + tdm@0 { + /* TDMa */ + reg = <0>; + + clocks = <&clk_l1rsynca>, <&clk_l1rclka>; + clock-names = "l1rsync", "l1rclk"; + + fsl,common-rxtx-pins; + fsl,fsync-rising-edge; + + fsl,tx-ts-routes = <2 0>, /* TS 0..1 */ + <24 FSL_CPM_TSA_SCC4>, /* TS 2..25 */ + <1 0>, /* TS 26 */ + <5 FSL_CPM_TSA_SCC3>; /* TS 27..31 */ + + fsl,rx-ts-routes = <2 0>, /* TS 0..1 */ + <24 FSL_CPM_TSA_SCC4>, /* 2..25 */ + <1 0>, /* TS 26 */ + <5 FSL_CPM_TSA_SCC3>; /* TS 27..31 */ + }; + }; diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml index ecd86cfb3da4..a02a09d574a2 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml @@ -70,7 +70,7 @@ examples: #include <dt-bindings/clock/imx8mm-clock.h> #include <dt-bindings/power/imx8mm-power.h> - disp_blk_ctl: blk_ctrl@32e28000 { + blk-ctrl@32e28000 { compatible = "fsl,imx8mm-disp-blk-ctrl", "syscon"; reg = <0x32e28000 0x100>; power-domains = <&pgc_dispmix>, <&pgc_dispmix>, <&pgc_dispmix>, diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml index d71bb20d4907..25109376d7d4 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml @@ -150,7 +150,7 @@ examples: #include <dt-bindings/clock/imx8mm-clock.h> #include <dt-bindings/power/imx8mm-power.h> - vpu_blk_ctrl: blk-ctrl@38330000 { + blk-ctrl@38330000 { compatible = "fsl,imx8mm-vpu-blk-ctrl", "syscon"; reg = <0x38330000 0x100>; power-domains = <&pgc_vpumix>, <&pgc_vpu_g1>, diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml index fbeaac399c50..eeec9965b091 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml @@ -71,7 +71,7 @@ examples: #include <dt-bindings/clock/imx8mn-clock.h> #include <dt-bindings/power/imx8mn-power.h> - disp_blk_ctl: blk_ctrl@32e28000 { + blk-ctrl@32e28000 { compatible = "fsl,imx8mn-disp-blk-ctrl", "syscon"; reg = <0x32e28000 0x100>; power-domains = <&pgc_dispmix>, <&pgc_dispmix>, diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml index 1fe68b53b1d8..4214c1ab4971 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml @@ -76,7 +76,7 @@ examples: #include <dt-bindings/clock/imx8mp-clock.h> #include <dt-bindings/power/imx8mp-power.h> - hsio_blk_ctrl: blk-ctrl@32f10000 { + blk-ctrl@32f10000 { compatible = "fsl,imx8mp-hsio-blk-ctrl", "syscon"; reg = <0x32f10000 0x24>; clocks = <&clk IMX8MP_CLK_USB_ROOT>, diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml index dadb6108e321..ea9aa876ed13 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml @@ -23,6 +23,12 @@ properties: reg: maxItems: 1 + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + '#power-domain-cells': const: 1 @@ -78,9 +84,16 @@ properties: - const: isp1 - const: dwe + bridge@5c: + type: object + $ref: /schemas/display/bridge/fsl,ldb.yaml# + unevaluatedProperties: false + required: - compatible - reg + - '#address-cells' + - '#size-cells' - '#power-domain-cells' - power-domains - power-domain-names @@ -94,7 +107,7 @@ examples: #include <dt-bindings/clock/imx8mp-clock.h> #include <dt-bindings/power/imx8mp-power.h> - media_blk_ctl: blk-ctl@32ec0000 { + blk-ctrl@32ec0000 { compatible = "fsl,imx8mp-media-blk-ctrl", "syscon"; reg = <0x32ec0000 0x138>; power-domains = <&mediamix_pd>, <&mipi_phy1_pd>, <&mipi_phy1_pd>, @@ -114,5 +127,43 @@ examples: clock-names = "apb", "axi", "cam1", "cam2", "disp1", "disp2", "isp", "phy"; #power-domain-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + + bridge@5c { + compatible = "fsl,imx8mp-ldb"; + reg = <0x5c 0x4>, <0x128 0x4>; + reg-names = "ldb", "lvds"; + clocks = <&clk IMX8MP_CLK_MEDIA_LDB>; + clock-names = "ldb"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + ldb_from_lcdif2: endpoint { + remote-endpoint = <&lcdif2_to_ldb>; + }; + }; + + port@1 { + reg = <1>; + + ldb_lvds_ch0: endpoint { + remote-endpoint = <&ldb_to_lvdsx4panel>; + }; + }; + + port@2 { + reg = <2>; + + ldb_lvds_ch1: endpoint { + }; + }; + }; + }; }; ... diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml index 7263ebedf09f..ea5c90c6a1b6 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml @@ -59,7 +59,7 @@ examples: #include <dt-bindings/clock/imx8mq-clock.h> #include <dt-bindings/power/imx8mq-power.h> - vpu_blk_ctrl: blk-ctrl@38320000 { + blk-ctrl@38320000 { compatible = "fsl,imx8mq-vpu-blk-ctrl"; reg = <0x38320000 0x100>; power-domains = <&pgc_vpu>, <&pgc_vpu>, <&pgc_vpu>; diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml index 792ebecec22d..b3554e7f9e76 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml @@ -60,7 +60,7 @@ examples: #include <dt-bindings/clock/imx93-clock.h> #include <dt-bindings/power/fsl,imx93-power.h> - media_blk_ctrl: system-controller@4ac10000 { + system-controller@4ac10000 { compatible = "fsl,imx93-media-blk-ctrl", "syscon"; reg = <0x4ac10000 0x10000>; power-domains = <&mediamix>; diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-src.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-src.yaml index c1cc69b51981..9ce8d8b427fa 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-src.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-src.yaml @@ -38,8 +38,9 @@ properties: patternProperties: "power-domain@[0-9a-f]+$": - type: object + additionalProperties: false + properties: compatible: items: diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml index d0a4bc3b03e9..99e2caafeadf 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml +++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml @@ -2,8 +2,8 @@ # # Copyright 2020 MediaTek Inc. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/mediatek/devapc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/mediatek/devapc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediaTek Device Access Permission Control driver diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml index 15c133cac315..ba2014a8725c 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml @@ -35,6 +35,8 @@ properties: - mediatek,mt8188-disp-mutex - mediatek,mt8192-disp-mutex - mediatek,mt8195-disp-mutex + - mediatek,mt8195-vpp-mutex + - mediatek,mt8365-disp-mutex reg: maxItems: 1 @@ -70,12 +72,30 @@ properties: 4 arguments defined in this property. Each GCE subsys id is mapping to a client defined in the header include/dt-bindings/gce/<chip>-gce.h. +allOf: + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt2701-disp-mutex + - mediatek,mt2712-disp-mutex + - mediatek,mt6795-disp-mutex + - mediatek,mt8173-disp-mutex + - mediatek,mt8186-disp-mutex + - mediatek,mt8186-mdp3-mutex + - mediatek,mt8192-disp-mutex + - mediatek,mt8195-disp-mutex + then: + required: + - clocks + + required: - compatible - reg - interrupts - power-domains - - clocks additionalProperties: false diff --git a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml index 33748a061898..a46411149571 100644 --- a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml +++ b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml @@ -54,6 +54,7 @@ patternProperties: "^timer@[0-2]$": description: The timer block channels that are used as timers or counters. type: object + additionalProperties: false properties: compatible: items: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml index ab607efbb64c..798f15588ee2 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml @@ -25,6 +25,7 @@ properties: compatible: items: - enum: + - qcom,qdu1000-aoss-qmp - qcom,sc7180-aoss-qmp - qcom,sc7280-aoss-qmp - qcom,sc8180x-aoss-qmp diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml index 6026c21736d8..e51acdcaafaf 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/qcom/qcom,apr.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/qcom/qcom,apr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm APR/GPR (Asynchronous/Generic Packet Router) @@ -62,7 +62,14 @@ properties: maxItems: 1 qcom,intents: - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-matrix + minItems: 1 + maxItems: 32 + items: + items: + - description: size of each intent to preallocate + - description: amount of intents to preallocate + minimum: 1 description: List of (size, amount) pairs describing what intents should be preallocated for this virtual channel. This can be used to tweak the diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml index c98aab209bc5..14dd29471c80 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/qcom/qcom,eud.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/qcom/qcom,eud.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Embedded USB Debugger diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index ab4df0205285..8a4b7ba3aaf6 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/qcom/qcom,geni-se.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/qcom/qcom,geni-se.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: GENI Serial Engine QUP Wrapper Controller diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml index cf863683c21a..6440dc801387 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml @@ -25,6 +25,8 @@ properties: - qcom,sc8180x-pmic-glink - qcom,sc8280xp-pmic-glink - qcom,sm8350-pmic-glink + - qcom,sm8450-pmic-glink + - qcom,sm8550-pmic-glink - const: qcom,pmic-glink '#address-cells': diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index 16fd67c0bd1f..ea86569a40d3 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/qcom/qcom,smd-rpm.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/qcom/qcom,smd-rpm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Resource Power Manager (RPM) over SMD/GLINK @@ -33,6 +33,7 @@ properties: enum: - qcom,rpm-apq8084 - qcom,rpm-ipq6018 + - qcom,rpm-ipq9574 - qcom,rpm-msm8226 - qcom,rpm-msm8909 - qcom,rpm-msm8916 @@ -40,6 +41,7 @@ properties: - qcom,rpm-msm8953 - qcom,rpm-msm8974 - qcom,rpm-msm8976 + - qcom,rpm-msm8994 - qcom,rpm-msm8996 - qcom,rpm-msm8998 - qcom,rpm-sdm660 @@ -84,6 +86,7 @@ if: - qcom,rpm-msm8974 - qcom,rpm-msm8976 - qcom,rpm-msm8953 + - qcom,rpm-msm8994 then: properties: qcom,glink-channels: false diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml index 497614ddf005..bc7815d985e4 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/qcom/qcom,smem.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/qcom/qcom,smem.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Shared Memory Manager diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml index aca3d40bcccb..20c8cd38ff0d 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/qcom/qcom,spm.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/qcom/qcom,spm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Subsystem Power Manager diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml index 0e6fd57d658d..74bb92e31554 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml @@ -20,7 +20,7 @@ properties: firmware-name: $ref: /schemas/types.yaml#/definitions/string - default: "wlan/prima/WCNSS_qcom_wlan_nv.bin" + default: wlan/prima/WCNSS_qcom_wlan_nv.bin description: Relative firmware image path for the WLAN NV blob. diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index 2789022b52eb..53b95f348f8e 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -111,7 +111,7 @@ properties: - description: RZ/G1C (R8A77470) items: - enum: - - iwave,g23s #iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) + - iwave,g23s # iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) - const: renesas,r8a77470 - description: RZ/G2M (R8A774A1) @@ -212,12 +212,12 @@ properties: - renesas,silk # SILK (RTP0RC7794LCB00011S) - const: renesas,r8a7794 - - description: R-Car H3 (R8A77950) + # Note: R-Car H3 ES1.* (R8A77950) is not supported upstream anymore! + + - description: R-Car H3 ES2.0 and later (R8A77951) items: - enum: - # H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) - # H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) - - renesas,h3ulcb + - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) - renesas,salvator-x # Salvator-X (RTP0RC7795SIPB0010S) - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S) - const: renesas,r8a7795 @@ -431,6 +431,13 @@ properties: - renesas,rzn1d400-db # RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package) - const: renesas,r9a06g032 + - description: RZ/N1{D,S} EB + items: + - enum: + - renesas,rzn1d400-eb # RZN1D-EB (Expansion Board when using a RZN1D-DB) + - const: renesas,rzn1d400-db + - const: renesas,r9a06g032 + - description: RZ/Five and RZ/G2UL (R9A07G043) items: - enum: diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index e697c928900d..65a2d5a4f28d 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -80,13 +80,17 @@ allOf: properties: compatible: contains: - const: rockchip,px30-grf + enum: + - rockchip,px30-grf then: properties: lvds: - description: - Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt + type: object + + $ref: /schemas/display/rockchip/rockchip,lvds.yaml# + + unevaluatedProperties: false - if: properties: diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml index f7c141dd11ec..5d8d9497f18e 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml @@ -48,6 +48,9 @@ properties: - const: syscon - items: - enum: + - samsung,exynos3250-pmu + - samsung,exynos4210-pmu + - samsung,exynos4412-pmu - samsung,exynos5250-pmu - samsung,exynos5420-pmu - samsung,exynos5433-pmu @@ -138,18 +141,34 @@ allOf: compatible: contains: enum: + - samsung,exynos3250-pmu + - samsung,exynos4210-pmu + - samsung,exynos4412-pmu - samsung,exynos5250-pmu - samsung,exynos5420-pmu - samsung,exynos5433-pmu then: properties: - dp-phy: true mipi-phy: true else: properties: - dp-phy: false mipi-phy: false + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5250-pmu + - samsung,exynos5420-pmu + - samsung,exynos5433-pmu + then: + properties: + dp-phy: true + else: + properties: + dp-phy: false + examples: - | #include <dt-bindings/clock/exynos5250.h> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index 847873289f25..c402cb2928e8 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -130,6 +130,7 @@ patternProperties: PRU-ICSS configuration space. CFG sub-module represented as a SysCon. type: object + additionalProperties: false properties: compatible: @@ -313,7 +314,7 @@ additionalProperties: false # Due to inability of correctly verifying sub-nodes with an @address through # the "required" list, the required sub-nodes below are commented out for now. -#required: +# required: # - memories # - interrupt-controller # - pru diff --git a/Documentation/devicetree/bindings/sound/adi,adau1372.yaml b/Documentation/devicetree/bindings/sound/adi,adau1372.yaml index 044bcd370d49..ea62e51aba90 100644 --- a/Documentation/devicetree/bindings/sound/adi,adau1372.yaml +++ b/Documentation/devicetree/bindings/sound/adi,adau1372.yaml @@ -32,7 +32,7 @@ properties: maxItems: 1 clock-names: - const: "mclk" + const: mclk powerdown-gpios: description: GPIO used for hardware power-down. diff --git a/Documentation/devicetree/bindings/sound/adi,adau17x1.txt b/Documentation/devicetree/bindings/sound/adi,adau17x1.txt deleted file mode 100644 index 1447dec28125..000000000000 --- a/Documentation/devicetree/bindings/sound/adi,adau17x1.txt +++ /dev/null @@ -1,32 +0,0 @@ -Analog Devices ADAU1361/ADAU1461/ADAU1761/ADAU1961/ADAU1381/ADAU1781 - -Required properties: - - - compatible: Should contain one of the following: - "adi,adau1361" - "adi,adau1461" - "adi,adau1761" - "adi,adau1961" - "adi,adau1381" - "adi,adau1781" - - - reg: The i2c address. Value depends on the state of ADDR0 - and ADDR1, as wired in hardware. - -Optional properties: - - clock-names: If provided must be "mclk". - - clocks: phandle + clock-specifiers for the clock that provides - the audio master clock for the device. - -Examples: -#include <dt-bindings/sound/adau17x1.h> - - i2c_bus { - adau1361@38 { - compatible = "adi,adau1761"; - reg = <0x38>; - - clock-names = "mclk"; - clocks = <&audio_clock>; - }; - }; diff --git a/Documentation/devicetree/bindings/sound/adi,adau17x1.yaml b/Documentation/devicetree/bindings/sound/adi,adau17x1.yaml new file mode 100644 index 000000000000..8ef1e7f6ec91 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/adi,adau17x1.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/adi,adau17x1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADAU1361/ADAU1461/ADAU1761/ADAU1961/ADAU1381/ADAU1781 Codec + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + +properties: + compatible: + enum: + - adi,adau1361 + - adi,adau1381 + - adi,adau1461 + - adi,adau1761 + - adi,adau1781 + - adi,adau1961 + + reg: + maxItems: 1 + description: + The i2c address. Value depends on the state of ADDR0 and ADDR1, + as wired in hardware. + + clock-names: + const: mclk + + clocks: + items: + - description: provides the audio master clock for the device. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + audio-codec@38 { + compatible = "adi,adau1761"; + reg = <0x38>; + clock-names = "mclk"; + clocks = <&audio_clock>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/adi,max98363.yaml b/Documentation/devicetree/bindings/sound/adi,max98363.yaml new file mode 100644 index 000000000000..a844b63f3930 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/adi,max98363.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/adi,max98363.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices MAX98363 SoundWire Amplifier + +maintainers: + - Ryan Lee <ryans.lee@analog.com> + +description: + The MAX98363 is a SoundWire input Class D mono amplifier that + supports MIPI SoundWire v1.2-compatible digital interface for + audio and control data. + SoundWire peripheral device ID of MAX98363 is 0x3*019f836300 + where * is the peripheral device unique ID decoded from pin. + It supports up to 10 peripheral devices(0x0 to 0x9). + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: sdw3019f836300 + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + - "#sound-dai-cells" + +unevaluatedProperties: false + +examples: + - | + soundwire-controller@3250000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x3250000 0x2000>; + + speaker@0,0 { + compatible = "sdw3019f836300"; + reg = <0 0>; + #sound-dai-cells = <0>; + sound-name-prefix = "Speaker Left"; + }; + + speaker@0,1 { + compatible = "sdw3019f836300"; + reg = <0 1>; + #sound-dai-cells = <0>; + sound-name-prefix = "Speaker Right"; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/adi,max98396.yaml b/Documentation/devicetree/bindings/sound/adi,max98396.yaml index fd5aa61b467f..bdc10d4204ec 100644 --- a/Documentation/devicetree/bindings/sound/adi,max98396.yaml +++ b/Documentation/devicetree/bindings/sound/adi,max98396.yaml @@ -41,21 +41,21 @@ properties: adi,vmon-slot-no: description: slot number of the voltage sense monitor - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 15 default: 0 adi,imon-slot-no: description: slot number of the current sense monitor - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 15 default: 1 adi,spkfb-slot-no: description: slot number of speaker DSP monitor - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 15 default: 2 @@ -64,7 +64,7 @@ properties: description: Selects the PCM data input channel that is routed to the speaker audio processing bypass path. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 15 default: 0 diff --git a/Documentation/devicetree/bindings/sound/ak4458.txt b/Documentation/devicetree/bindings/sound/ak4458.txt deleted file mode 100644 index 0416c14895d6..000000000000 --- a/Documentation/devicetree/bindings/sound/ak4458.txt +++ /dev/null @@ -1,28 +0,0 @@ -AK4458 audio DAC - -This device supports I2C mode. - -Required properties: - -- compatible : "asahi-kasei,ak4458" or "asahi-kasei,ak4497" -- reg : The I2C address of the device for I2C - -Optional properties: -- reset-gpios: A GPIO specifier for the power down & reset pin -- mute-gpios: A GPIO specifier for the soft mute pin -- AVDD-supply: Analog power supply -- DVDD-supply: Digital power supply -- dsd-path: Select DSD input pins for ak4497 - 0: select #16, #17, #19 pins - 1: select #3, #4, #5 pins - -Example: - -&i2c { - ak4458: dac@10 { - compatible = "asahi-kasei,ak4458"; - reg = <0x10>; - reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW> - mute-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH> - }; -}; diff --git a/Documentation/devicetree/bindings/sound/ak5558.txt b/Documentation/devicetree/bindings/sound/ak5558.txt deleted file mode 100644 index e28708db6686..000000000000 --- a/Documentation/devicetree/bindings/sound/ak5558.txt +++ /dev/null @@ -1,24 +0,0 @@ -AK5558 8 channel differential 32-bit delta-sigma ADC - -This device supports I2C mode only. - -Required properties: - -- compatible : "asahi-kasei,ak5558" or "asahi-kasei,ak5552". -- reg : The I2C address of the device. - -Optional properties: - -- reset-gpios: A GPIO specifier for the power down & reset pin. -- AVDD-supply: Analog power supply -- DVDD-supply: Digital power supply - -Example: - -&i2c { - ak5558: adc@10 { - compatible = "asahi-kasei,ak5558"; - reg = <0x10>; - reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>; - }; -}; diff --git a/Documentation/devicetree/bindings/sound/alc5632.txt b/Documentation/devicetree/bindings/sound/alc5632.txt deleted file mode 100644 index ffd886d110bd..000000000000 --- a/Documentation/devicetree/bindings/sound/alc5632.txt +++ /dev/null @@ -1,43 +0,0 @@ -ALC5632 audio CODEC - -This device supports I2C only. - -Required properties: - - - compatible : "realtek,alc5632" - - - reg : the I2C address of the device. - - - gpio-controller : Indicates this device is a GPIO controller. - - - #gpio-cells : Should be two. The first cell is the pin number and the - second cell is used to specify optional parameters (currently unused). - -Pins on the device (for linking into audio routes): - - * SPK_OUTP - * SPK_OUTN - * HP_OUT_L - * HP_OUT_R - * AUX_OUT_P - * AUX_OUT_N - * LINE_IN_L - * LINE_IN_R - * PHONE_P - * PHONE_N - * MIC1_P - * MIC1_N - * MIC2_P - * MIC2_N - * MICBIAS1 - * DMICDAT - -Example: - -alc5632: alc5632@1e { - compatible = "realtek,alc5632"; - reg = <0x1a>; - - gpio-controller; - #gpio-cells = <2>; -}; diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml index 320f0002649d..45955d8a26d1 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,axg-tdm-iface.yaml @@ -24,7 +24,7 @@ properties: items: - description: Bit clock - description: Sample clock - - description: Master clock #optional + - description: Master clock # optional clock-names: minItems: 2 diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml new file mode 100644 index 000000000000..4477f84b7acc --- /dev/null +++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/asahi-kasei,ak4458.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AK4458 audio DAC + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + +properties: + compatible: + enum: + - asahi-kasei,ak4458 + - asahi-kasei,ak4497 + + reg: + maxItems: 1 + + avdd-supply: + description: Analog power supply + + dvdd-supply: + description: Digital power supply + + reset-gpios: + maxItems: 1 + + mute-gpios: + maxItems: 1 + description: + GPIO used to mute all the outputs + + dsd-path: + description: Select DSD input pins for ak4497 + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - const: 0 + description: "select #16, #17, #19 pins" + - const: 1 + description: "select #3, #4, #5 pins" + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: asahi-kasei,ak4458 + + then: + properties: + dsd-path: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@10 { + compatible = "asahi-kasei,ak4458"; + reg = <0x10>; + reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>; + mute-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak5558.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak5558.yaml new file mode 100644 index 000000000000..d3d494ae8abf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak5558.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/asahi-kasei,ak5558.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AK5558 8 channel differential 32-bit delta-sigma ADC + +maintainers: + - Junichi Wakasugi <wakasugi.jb@om.asahi-kasei.co.jp> + - Mihai Serban <mihai.serban@nxp.com> + +properties: + compatible: + enum: + - asahi-kasei,ak5552 + - asahi-kasei,ak5558 + + reg: + maxItems: 1 + + avdd-supply: + description: A 1.8V supply that powers up the AVDD pin. + + dvdd-supply: + description: A 1.2V supply that powers up the DVDD pin. + + reset-gpios: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + ak5558: codec@10 { + compatible = "asahi-kasei,ak5558"; + reg = <0x10>; + reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml index 6b4e02a0695a..fa9f9a853365 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml @@ -16,19 +16,19 @@ definitions: $ref: /schemas/graph.yaml#/$defs/port-base properties: convert-rate: - $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-rate" + $ref: /schemas/sound/dai-params.yaml#/$defs/dai-sample-rate convert-channels: - $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-channels" + $ref: /schemas/sound/dai-params.yaml#/$defs/dai-channels convert-sample-format: - $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-format" + $ref: /schemas/sound/dai-params.yaml#/$defs/dai-sample-format mclk-fs: - $ref: "simple-card.yaml#/definitions/mclk-fs" + $ref: simple-card.yaml#/definitions/mclk-fs endpoint-base: $ref: /schemas/graph.yaml#/$defs/endpoint-base properties: mclk-fs: - $ref: "simple-card.yaml#/definitions/mclk-fs" + $ref: simple-card.yaml#/definitions/mclk-fs frame-inversion: description: dai-link uses frame clock inversion $ref: /schemas/types.yaml#/definitions/flag @@ -49,11 +49,11 @@ definitions: description: Indicates system clock $ref: /schemas/types.yaml#/definitions/phandle system-clock-frequency: - $ref: "simple-card.yaml#/definitions/system-clock-frequency" + $ref: simple-card.yaml#/definitions/system-clock-frequency system-clock-direction-out: - $ref: "simple-card.yaml#/definitions/system-clock-direction-out" + $ref: simple-card.yaml#/definitions/system-clock-direction-out system-clock-fixed: - $ref: "simple-card.yaml#/definitions/system-clock-fixed" + $ref: simple-card.yaml#/definitions/system-clock-fixed dai-format: description: audio format. @@ -69,11 +69,11 @@ definitions: - msb - lsb convert-rate: - $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-rate" + $ref: /schemas/sound/dai-params.yaml#/$defs/dai-sample-rate convert-channels: - $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-channels" + $ref: /schemas/sound/dai-params.yaml#/$defs/dai-channels convert-sample-format: - $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-format" + $ref: /schemas/sound/dai-params.yaml#/$defs/dai-sample-format dai-tdm-slot-num: description: Number of slots in use. diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml index d59baedee180..c87eb91de159 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml @@ -15,7 +15,7 @@ properties: label: maxItems: 1 prefix: - description: "device name prefix" + description: device name prefix $ref: /schemas/types.yaml#/definitions/string routing: description: | @@ -27,11 +27,11 @@ properties: description: User specified audio sound widgets. $ref: /schemas/types.yaml#/definitions/non-unique-string-array convert-rate: - $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-rate" + $ref: /schemas/sound/dai-params.yaml#/$defs/dai-sample-rate convert-channels: - $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-channels" + $ref: /schemas/sound/dai-params.yaml#/$defs/dai-channels convert-sample-format: - $ref: "/schemas/sound/dai-params.yaml#/$defs/dai-sample-format" + $ref: /schemas/sound/dai-params.yaml#/$defs/dai-sample-format pa-gpios: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml index 18fb471aa891..14dea1feefc5 100644 --- a/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l41.yaml @@ -85,11 +85,19 @@ properties: boost-cap-microfarad. External Boost must have GPIO1 as GPIO output. GPIO1 will be set high to enable boost voltage. + Shared boost allows two amplifiers to share a single boost circuit by + communicating on the MDSYNC bus. The active amplifier controls the boost + circuit using combined data from both amplifiers. GPIO1 should be + configured for Sync when shared boost is used. Shared boost is not + compatible with External boost. Active amplifier requires + boost-peak-milliamp, boost-ind-nanohenry and boost-cap-microfarad. 0 = Internal Boost 1 = External Boost + 2 = Shared Boost Active + 3 = Shared Boost Passive $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 - maximum: 1 + maximum: 3 cirrus,gpio1-polarity-invert: description: diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml index 88a0ca474c3d..2ab74f995685 100644 --- a/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l45.yaml @@ -45,11 +45,79 @@ properties: Audio serial port SDOUT Hi-Z control. Sets the Hi-Z configuration for SDOUT pin of amplifier. Logical OR of CS35L45_ASP_TX_HIZ_xxx values. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3 default: 2 +patternProperties: + "^cirrus,gpio-ctrl[1-3]$": + description: + GPIO pins configuration. + type: object + additionalProperties: false + properties: + gpio-dir: + description: + GPIO pin direction. Valid only when 'gpio-ctrl' is 1 + 0 = Output + 1 = Input + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1 + default: 1 + gpio-lvl: + description: + GPIO level. Valid only when 'gpio-ctrl' is 1 and 'gpio-dir' is 0 + 0 = Low + 1 = High + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1 + default: 0 + gpio-op-cfg: + description: + GPIO level. Valid only when 'gpio-ctrl' is 1 and 'gpio-dir' is 0 + 0 = CMOS + 1 = Open Drain + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1 + default: 0 + gpio-pol: + description: + GPIO output polarity select. Valid only when 'gpio-ctrl' is 1 + and 'gpio-dir' is 0 + 0 = Non-inverted, Active High + 1 = Inverted, Active Low + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1 + default: 0 + gpio-ctrl: + description: + Defines the function of the GPIO pin. + GPIO1 + 0 = High impedance input + 1 = Pin acts as a GPIO, direction controlled by 'gpio-dir' + 2 = Pin acts as MDSYNC, direction controlled by MDSYNC + 3-7 = Reserved + GPIO2 + 0 = High impedance input + 1 = Pin acts as a GPIO, direction controlled by 'gpio-dir' + 2 = Pin acts as open drain INT + 3 = Reserved + 4 = Pin acts as push-pull output INT. Active low. + 5 = Pin acts as push-pull output INT. Active high. + 6,7 = Reserved + GPIO3 + 0 = High impedance input + 1 = Pin acts as a GPIO, direction controlled by 'gpio-dir' + 2-7 = Reserved + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 7 + default: 0 required: - compatible - reg @@ -74,5 +142,15 @@ examples: reset-gpios = <&gpio 110 0>; cirrus,asp-sdout-hiz-ctrl = <(CS35L45_ASP_TX_HIZ_UNUSED | CS35L45_ASP_TX_HIZ_DISABLED)>; + cirrus,gpio-ctrl1 { + gpio-ctrl = <0x2>; + }; + cirrus,gpio-ctrl2 { + gpio-ctrl = <0x2>; + }; + cirrus,gpio-ctrl3 { + gpio-ctrl = <0x1>; + gpio-dir = <0x1>; + }; }; }; diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml index 7356084a2ca2..af599d8735e2 100644 --- a/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml +++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml @@ -68,7 +68,7 @@ properties: This is "normal tip sense (TS)" in the datasheet. The CS42L42_TS_INV_* defines are available for this. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1 @@ -87,7 +87,7 @@ properties: 7 - 1.5s The CS42L42_TS_DBNCE_* defines are available for this. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 7 @@ -106,7 +106,7 @@ properties: 7 - 1.5s The CS42L42_TS_DBNCE_* defines are available for this. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 7 @@ -120,7 +120,7 @@ properties: 0ms - 200ms, Default = 100ms - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 200 @@ -133,7 +133,7 @@ properties: 0ms - 20ms, Default = 10ms - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 20 @@ -169,7 +169,7 @@ properties: 3 - Slowest The CS42L42_HSBIAS_RAMP_* defines are available for this. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3 diff --git a/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml b/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml new file mode 100644 index 000000000000..453d493c941f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cirrus,ep9301-i2s.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/cirrus,ep9301-i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus EP93xx I2S Controller + +description: | + The I2S controller is used to stream serial audio data between the external + I2S CODECs’, ADCs/DACs, and the ARM Core. The controller supports I2S, Left- + and Right-Justified DSP formats. + +maintainers: + - Alexander Sverdlin <alexander.sverdlin@gmail.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: cirrus,ep9301-i2s + + '#sound-dai-cells': + const: 0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 3 + maxItems: 3 + + clock-names: + items: + - const: mclk + - const: sclk + - const: lrclk + +required: + - compatible + - '#sound-dai-cells' + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + i2s: i2s@80820000 { + compatible = "cirrus,ep9301-i2s"; + #sound-dai-cells = <0>; + reg = <0x80820000 0x100>; + interrupt-parent = <&vic1>; + interrupts = <28>; + clocks = <&syscon 29>, + <&syscon 30>, + <&syscon 31>; + clock-names = "mclk", "sclk", "lrclk"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/everest,es8316.yaml b/Documentation/devicetree/bindings/sound/everest,es8316.yaml index d9f8f0c7f6bb..b6079b3c440d 100644 --- a/Documentation/devicetree/bindings/sound/everest,es8316.yaml +++ b/Documentation/devicetree/bindings/sound/everest,es8316.yaml @@ -28,6 +28,10 @@ properties: items: - const: mclk + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + "#sound-dai-cells": const: 0 @@ -40,7 +44,7 @@ unevaluatedProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; es8316: codec@11 { diff --git a/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml b/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml new file mode 100644 index 000000000000..ff5cd9241941 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,qmc-audio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: QMC audio + +maintainers: + - Herve Codina <herve.codina@bootlin.com> + +description: | + The QMC audio is an ASoC component which uses QMC (QUICC Multichannel + Controller) channels to transfer the audio data. + It provides as many DAI as the number of QMC channel used. + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: fsl,qmc-audio + + '#address-cells': + const: 1 + '#size-cells': + const: 0 + '#sound-dai-cells': + const: 1 + +patternProperties: + '^dai@([0-9]|[1-5][0-9]|6[0-3])$': + description: + A DAI managed by this controller + type: object + + properties: + reg: + minimum: 0 + maximum: 63 + description: + The DAI number + + fsl,qmc-chan: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to QMC node + - description: Channel number + description: + Should be a phandle/number pair. The phandle to QMC node and the QMC + channel to use for this DAI. + + required: + - reg + - fsl,qmc-chan + +required: + - compatible + - '#address-cells' + - '#size-cells' + - '#sound-dai-cells' + +additionalProperties: false + +examples: + - | + audio_controller: audio-controller { + compatible = "fsl,qmc-audio"; + #address-cells = <1>; + #size-cells = <0>; + #sound-dai-cells = <1>; + dai@16 { + reg = <16>; + fsl,qmc-chan = <&qmc 16>; + }; + dai@17 { + reg = <17>; + fsl,qmc-chan = <&qmc 17>; + }; + }; + + sound { + compatible = "simple-audio-card"; + #address-cells = <1>; + #size-cells = <0>; + simple-audio-card,dai-link@0 { + reg = <0>; + format = "dsp_b"; + cpu { + sound-dai = <&audio_controller 16>; + }; + codec { + sound-dai = <&codec1>; + dai-tdm-slot-num = <4>; + dai-tdm-slot-width = <8>; + /* TS 3, 5, 7, 9 */ + dai-tdm-slot-tx-mask = <0 0 0 1 0 1 0 1 0 1>; + dai-tdm-slot-rx-mask = <0 0 0 1 0 1 0 1 0 1>; + }; + }; + simple-audio-card,dai-link@1 { + reg = <1>; + format = "dsp_b"; + cpu { + sound-dai = <&audio_controller 17>; + }; + codec { + sound-dai = <&codec2>; + dai-tdm-slot-num = <4>; + dai-tdm-slot-width = <8>; + /* TS 2, 4, 6, 8 */ + dai-tdm-slot-tx-mask = <0 0 1 0 1 0 1 0 1>; + dai-tdm-slot-rx-mask = <0 0 1 0 1 0 1 0 1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml b/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml index f302fe89a253..4193d17d1c62 100644 --- a/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml +++ b/Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml @@ -60,6 +60,7 @@ properties: properties: endpoint: type: object + additionalProperties: true properties: dai-format: diff --git a/Documentation/devicetree/bindings/sound/max98371.txt b/Documentation/devicetree/bindings/sound/max98371.txt deleted file mode 100644 index 8b2b2704b574..000000000000 --- a/Documentation/devicetree/bindings/sound/max98371.txt +++ /dev/null @@ -1,17 +0,0 @@ -max98371 codec - -This device supports I2C mode only. - -Required properties: - -- compatible : "maxim,max98371" -- reg : The chip select number on the I2C bus - -Example: - -&i2c { - max98371: max98371@31 { - compatible = "maxim,max98371"; - reg = <0x31>; - }; -}; diff --git a/Documentation/devicetree/bindings/sound/max9867.txt b/Documentation/devicetree/bindings/sound/max9867.txt deleted file mode 100644 index b8bd914ee697..000000000000 --- a/Documentation/devicetree/bindings/sound/max9867.txt +++ /dev/null @@ -1,17 +0,0 @@ -max9867 codec - -This device supports I2C mode only. - -Required properties: - -- compatible : "maxim,max9867" -- reg : The chip select number on the I2C bus - -Example: - -&i2c { - max9867: max9867@18 { - compatible = "maxim,max9867"; - reg = <0x18>; - }; -}; diff --git a/Documentation/devicetree/bindings/sound/maxim,max9759.txt b/Documentation/devicetree/bindings/sound/maxim,max9759.txt deleted file mode 100644 index 737a996374d3..000000000000 --- a/Documentation/devicetree/bindings/sound/maxim,max9759.txt +++ /dev/null @@ -1,18 +0,0 @@ -Maxim MAX9759 Speaker Amplifier -=============================== - -Required properties: -- compatible : "maxim,max9759" -- shutdown-gpios : the gpio connected to the shutdown pin -- mute-gpios : the gpio connected to the mute pin -- gain-gpios : the 2 gpios connected to the g1 and g2 pins - -Example: - -max9759: analog-amplifier { - compatible = "maxim,max9759"; - shutdown-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>; - mute-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>; - gain-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>, - <&gpio3 25 GPIO_ACTIVE_LOW>; -}; diff --git a/Documentation/devicetree/bindings/sound/maxim,max9759.yaml b/Documentation/devicetree/bindings/sound/maxim,max9759.yaml new file mode 100644 index 000000000000..a76ee6a635af --- /dev/null +++ b/Documentation/devicetree/bindings/sound/maxim,max9759.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/maxim,max9759.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX9759 Speaker Amplifier + +maintainers: + - Otabek Nazrullaev <otabeknazrullaev1998@gmail.com> + +properties: + compatible: + const: maxim,max9759 + + shutdown-gpios: + maxItems: 1 + description: the gpio connected to the shutdown pin + + mute-gpios: + maxItems: 1 + description: the gpio connected to the mute pin + + gain-gpios: + maxItems: 2 + description: the 2 gpios connected to the g1 and g2 pins + +required: + - compatible + - shutdown-gpios + - mute-gpios + - gain-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + amplifier { + compatible = "maxim,max9759"; + shutdown-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>; + mute-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>; + gain-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>, + <&gpio3 25 GPIO_ACTIVE_LOW>; + }; diff --git a/Documentation/devicetree/bindings/sound/maxim,max98371.yaml b/Documentation/devicetree/bindings/sound/maxim,max98371.yaml new file mode 100644 index 000000000000..14fba34ef81a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/maxim,max98371.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/maxim,max98371.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX98371 audio codec + +maintainers: + - anish kumar <yesanishhere@gmail.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: maxim,max98371 + + '#sound-dai-cells': + const: 0 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@31 { + compatible = "maxim,max98371"; + reg = <0x31>; + #sound-dai-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/maxim,max9867.yaml b/Documentation/devicetree/bindings/sound/maxim,max9867.yaml new file mode 100644 index 000000000000..0b9a84d33b6c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/maxim,max9867.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/maxim,max9867.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim Integrated MAX9867 CODEC + +description: | + This device supports I2C only. + Pins on the device (for linking into audio routes): + * LOUT + * ROUT + * LINL + * LINR + * MICL + * MICR + * DMICL + * DMICR + +maintainers: + - Ladislav Michl <ladis@linux-mips.org> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - maxim,max9867 + + '#sound-dai-cells': + const: 0 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@18 { + compatible = "maxim,max9867"; + #sound-dai-cells = <0>; + reg = <0x18>; + clocks = <&codec_clk>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml index 88f82d096443..7fe85b08f9df 100644 --- a/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml +++ b/Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml @@ -26,15 +26,15 @@ properties: const: audiosys mediatek,apmixedsys: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the mediatek apmixedsys controller mediatek,infracfg: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the mediatek infracfg controller mediatek,topckgen: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the mediatek topckgen controller clocks: diff --git a/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml b/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml index d427f7f623db..9853c11a1330 100644 --- a/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml +++ b/Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml @@ -18,7 +18,7 @@ properties: - mediatek,mt8186-mt6366-da7219-max98357-sound mediatek,platform: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8186 ASoC platform. headset-codec: diff --git a/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml b/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml index aa23b0024c46..d80083df03eb 100644 --- a/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml +++ b/Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml @@ -19,7 +19,7 @@ properties: - mediatek,mt8186-mt6366-rt5682s-max98360-sound mediatek,platform: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8186 ASoC platform. dmic-gpios: diff --git a/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml index 7a25bc9b8060..064ef172bef4 100644 --- a/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml +++ b/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml @@ -24,15 +24,15 @@ properties: const: audiosys mediatek,apmixedsys: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the mediatek apmixedsys controller mediatek,infracfg: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the mediatek infracfg controller mediatek,topckgen: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the mediatek topckgen controller power-domains: diff --git a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml index c6e614c1c30b..7e50f5d65c8f 100644 --- a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml +++ b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml @@ -21,11 +21,11 @@ properties: - mediatek,mt8192_mt6359_rt1015p_rt5682s mediatek,platform: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8192 ASoC platform. mediatek,hdmi-codec: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of HDMI codec. headset-codec: diff --git a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml index 4452a4070eff..d5adf07d46e0 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml @@ -32,7 +32,7 @@ properties: See ../reserved-memory/reserved-memory.txt for details. mediatek,topckgen: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the mediatek topckgen controller power-domains: diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml index ad3447ff8b2c..c1ddbf672ca3 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-mt6359.yaml @@ -24,19 +24,19 @@ properties: description: User specified audio sound card name mediatek,platform: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8195 ASoC platform. mediatek,dptx-codec: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8195 Display Port Tx codec node. mediatek,hdmi-codec: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8195 HDMI codec node. mediatek,adsp: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of MT8195 ADSP platform. mediatek,dai-link: diff --git a/Documentation/devicetree/bindings/sound/nau8825.txt b/Documentation/devicetree/bindings/sound/nau8825.txt index cb861aca8d40..a9c34526f4cb 100644 --- a/Documentation/devicetree/bindings/sound/nau8825.txt +++ b/Documentation/devicetree/bindings/sound/nau8825.txt @@ -74,6 +74,9 @@ Optional properties: - nuvoton,adcout-drive-strong: make the drive strength of ADCOUT IO PIN strong if set. Otherwise, the drive keeps normal strength. + - nuvoton,adc-delay-ms: Delay (in ms) to make input path stable and avoid pop noise. The + default value is 125 and range between 125 to 500 ms. + - clocks: list of phandle and clock specifier pairs according to common clock bindings for the clocks described in clock-names - clock-names: should include "mclk" for the MCLK master clock diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml index 7ef774910e5c..96f2f927a6f5 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml @@ -31,10 +31,10 @@ properties: items: enum: # Board Connectors - - "Headset Stereophone" - - "Int Spk" - - "Headset Mic" - - "Digital Mic" + - Headset Stereophone + - Int Spk + - Headset Mic + - Digital Mic # CODEC Pins - SPKOUT diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml index 82801b4f46dd..7c1e9895ce85 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml @@ -80,4 +80,8 @@ properties: type: boolean description: The Mic Jack represents state of the headset microphone pin + nvidia,coupled-mic-hp-det: + type: boolean + description: The Mic detect GPIO is viable only if HP detect GPIO is active + additionalProperties: true diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml new file mode 100644 index 000000000000..fc89dbd6bf24 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-max9808x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with MAX9808x CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + oneOf: + - items: + - pattern: '^[a-z0-9]+,tegra-audio-max98088(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-max98088 + - items: + - pattern: '^[a-z0-9]+,tegra-audio-max98089(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-max98089 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + minItems: 2 + items: + enum: + # Board Connectors + - "Int Spk" + - "Headphone Jack" + - "Earpiece" + - "Headset Mic" + - "Internal Mic 1" + - "Internal Mic 2" + + # CODEC Pins + - HPL + - HPR + - SPKL + - SPKR + - RECL + - RECR + - INA1 + - INA2 + - INB1 + - INB2 + - MIC1 + - MIC2 + - MICBIAS + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra30-car.h> + #include <dt-bindings/soc/tegra-pmc.h> + sound { + compatible = "lge,tegra-audio-max98089-p895", + "nvidia,tegra-audio-max98089"; + nvidia,model = "LG Optimus Vu MAX98089"; + + nvidia,audio-routing = + "Headphone Jack", "HPL", + "Headphone Jack", "HPR", + "Int Spk", "SPKL", + "Int Spk", "SPKR", + "Earpiece", "RECL", + "Earpiece", "RECR", + "INA1", "Headset Mic", + "MIC1", "MICBIAS", + "MICBIAS", "Internal Mic 1", + "MIC2", "Internal Mic 2"; + + nvidia,i2s-controller = <&tegra_i2s0>; + nvidia,audio-codec = <&codec>; + + clocks = <&tegra_car TEGRA30_CLK_PLL_A>, + <&tegra_car TEGRA30_CLK_PLL_A_OUT0>, + <&tegra_pmc TEGRA_PMC_CLK_OUT_1>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml index ccc2ee77ca30..4d912458b18b 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml @@ -38,10 +38,10 @@ properties: items: enum: # Board Connectors - - "Headphones" - - "Speakers" - - "Mic Jack" - - "Int Mic" + - Headphones + - Speakers + - Mic Jack + - Int Mic # CODEC Pins - MIC1 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml new file mode 100644 index 000000000000..a04487002e88 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5631.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-rt5631.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with RT5631 CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + items: + - pattern: '^[a-z0-9]+,tegra-audio-rt5631(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-rt5631 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + minItems: 2 + items: + enum: + # Board Connectors + - "Int Spk" + - "Headphone Jack" + - "Mic Jack" + - "Int Mic" + + # CODEC Pins + - MIC1 + - MIC2 + - AXIL + - AXIR + - MONOIN_RXN + - MONOIN_RXP + - DMIC + - MIC Bias1 + - MIC Bias2 + - MONO_IN + - AUXO1 + - AUXO2 + - SPOL + - SPOR + - HPOL + - HPOR + - MONO + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra30-car.h> + #include <dt-bindings/soc/tegra-pmc.h> + sound { + compatible = "asus,tegra-audio-rt5631-tf700t", + "nvidia,tegra-audio-rt5631"; + nvidia,model = "Asus Transformer Infinity TF700T RT5631"; + + nvidia,audio-routing = + "Headphone Jack", "HPOL", + "Headphone Jack", "HPOR", + "Int Spk", "SPOL", + "Int Spk", "SPOR", + "MIC1", "MIC Bias1", + "MIC Bias1", "Mic Jack", + "DMIC", "Int Mic"; + + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&rt5631>; + + clocks = <&tegra_car TEGRA30_CLK_PLL_A>, + <&tegra_car TEGRA30_CLK_PLL_A_OUT0>, + <&tegra_pmc TEGRA_PMC_CLK_OUT_1>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml index b1deaf271afa..2638592435b2 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml @@ -31,9 +31,9 @@ properties: items: enum: # Board Connectors - - "Headphones" - - "Speakers" - - "Mic Jack" + - Headphones + - Speakers + - Mic Jack # CODEC Pins - DMIC1 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml index a49997d6028b..09e1d0b18d27 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml @@ -31,11 +31,11 @@ properties: items: enum: # Board Connectors - - "Headphone" - - "Speaker" - - "Headset Mic" - - "Internal Mic 1" - - "Internal Mic 2" + - Headphone + - Speaker + - Headset Mic + - Internal Mic 1 + - Internal Mic 2 # CODEC Pins - IN1P @@ -47,14 +47,14 @@ properties: - DMIC2 - DMIC3 - DMIC4 - - "DMIC L1" - - "DMIC L2" - - "DMIC L3" - - "DMIC L4" - - "DMIC R1" - - "DMIC R2" - - "DMIC R3" - - "DMIC R4" + - DMIC L1 + - DMIC L2 + - DMIC L3 + - DMIC L4 + - DMIC R1 + - DMIC R2 + - DMIC R3 + - DMIC R4 - LOUT1 - LOUT2 - LOUT3 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml index 943e7c01741c..e5bc6a6ade24 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml @@ -31,9 +31,9 @@ properties: items: enum: # Board Connectors - - "Headphone Jack" - - "Line In Jack" - - "Mic Jack" + - Headphone Jack + - Line In Jack + - Mic Jack # CODEC Pins - HP_OUT diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml index a5b431d7d0c2..3323d6a438f5 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml @@ -31,8 +31,8 @@ properties: items: enum: # Board Connectors - - "Headphone Jack" - - "Mic Jack" + - Headphone Jack + - Mic Jack # CODEC Pins - LOUT1 @@ -53,7 +53,7 @@ properties: - MIC1 - MIC2N - MIC2 - - "Mic Bias" + - Mic Bias required: - nvidia,i2s-controller diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml index 1b836acab980..1be25ce4514b 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml @@ -35,10 +35,10 @@ properties: items: enum: # Board Connectors - - "Headphone Jack" - - "Int Spk" - - "Mic Jack" - - "Int Mic" + - Headphone Jack + - Int Spk + - Mic Jack + - Int Mic # CODEC Pins - IN1L diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml index a1448283344b..397306b8800d 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml @@ -31,9 +31,9 @@ properties: items: enum: # Board Connectors - - "Headphone" - - "LineIn" - - "Mic" + - Headphone + - LineIn + - Mic # CODEC Pins - MONOOUT @@ -48,7 +48,7 @@ properties: - PCBEEP - MIC1 - MIC2 - - "Mic Bias" + - Mic Bias required: - nvidia,ac97-controller diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml index 79c6f8da1319..ec4b0ac8ad68 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml @@ -9,15 +9,13 @@ title: LPASS(Low Power Audio Subsystem) RX Macro audio codec maintainers: - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> -allOf: - - $ref: dai-common.yaml# - properties: compatible: enum: - qcom,sc7280-lpass-rx-macro - qcom,sm8250-lpass-rx-macro - qcom,sm8450-lpass-rx-macro + - qcom,sm8550-lpass-rx-macro - qcom,sc8280xp-lpass-rx-macro reg: @@ -30,20 +28,12 @@ properties: const: 0 clocks: + minItems: 3 maxItems: 5 clock-names: - oneOf: - - items: #for ADSP based platforms - - const: mclk - - const: npl - - const: macro - - const: dcodec - - const: fsgen - - items: #for ADSP bypass based platforms - - const: mclk - - const: npl - - const: fsgen + minItems: 3 + maxItems: 5 clock-output-names: maxItems: 1 @@ -61,6 +51,65 @@ required: - reg - "#sound-dai-cells" +allOf: + - $ref: dai-common.yaml# + - if: + properties: + compatible: + enum: + - qcom,sc7280-lpass-rx-macro + then: + properties: + clock-names: + oneOf: + - items: # for ADSP based platforms + - const: mclk + - const: npl + - const: macro + - const: dcodec + - const: fsgen + - items: # for ADSP bypass based platforms + - const: mclk + - const: npl + - const: fsgen + + - if: + properties: + compatible: + enum: + - qcom,sc8280xp-lpass-rx-macro + - qcom,sm8250-lpass-rx-macro + - qcom,sm8450-lpass-rx-macro + then: + properties: + clocks: + minItems: 5 + maxItems: 5 + clock-names: + items: + - const: mclk + - const: npl + - const: macro + - const: dcodec + - const: fsgen + + - if: + properties: + compatible: + enum: + - qcom,sm8550-lpass-rx-macro + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: mclk + - const: macro + - const: dcodec + - const: fsgen + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml index da5f70910da5..4156981fe02b 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml @@ -9,15 +9,13 @@ title: LPASS(Low Power Audio Subsystem) TX Macro audio codec maintainers: - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> -allOf: - - $ref: dai-common.yaml# - properties: compatible: enum: - qcom,sc7280-lpass-tx-macro - qcom,sm8250-lpass-tx-macro - qcom,sm8450-lpass-tx-macro + - qcom,sm8550-lpass-tx-macro - qcom,sc8280xp-lpass-tx-macro reg: @@ -30,22 +28,12 @@ properties: const: 0 clocks: - oneOf: - - maxItems: 3 - - maxItems: 5 + minItems: 3 + maxItems: 5 clock-names: - oneOf: - - items: #for ADSP based platforms - - const: mclk - - const: npl - - const: macro - - const: dcodec - - const: fsgen - - items: #for ADSP bypass based platforms - - const: mclk - - const: npl - - const: fsgen + minItems: 3 + maxItems: 5 clock-output-names: maxItems: 1 @@ -67,6 +55,65 @@ required: - reg - "#sound-dai-cells" +allOf: + - $ref: dai-common.yaml# + - if: + properties: + compatible: + enum: + - qcom,sc7280-lpass-tx-macro + then: + properties: + clock-names: + oneOf: + - items: # for ADSP based platforms + - const: mclk + - const: npl + - const: macro + - const: dcodec + - const: fsgen + - items: # for ADSP bypass based platforms + - const: mclk + - const: npl + - const: fsgen + + - if: + properties: + compatible: + enum: + - qcom,sc8280xp-lpass-tx-macro + - qcom,sm8250-lpass-tx-macro + - qcom,sm8450-lpass-tx-macro + then: + properties: + clocks: + minItems: 5 + maxItems: 5 + clock-names: + items: + - const: mclk + - const: npl + - const: macro + - const: dcodec + - const: fsgen + + - if: + properties: + compatible: + enum: + - qcom,sm8550-lpass-tx-macro + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: mclk + - const: macro + - const: dcodec + - const: fsgen + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml index 0a3c688ef1ec..4a56108c444b 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml @@ -9,15 +9,13 @@ title: LPASS(Low Power Audio Subsystem) VA Macro audio codec maintainers: - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> -allOf: - - $ref: dai-common.yaml# - properties: compatible: enum: - qcom,sc7280-lpass-va-macro - qcom,sm8250-lpass-va-macro - qcom,sm8450-lpass-va-macro + - qcom,sm8550-lpass-va-macro - qcom,sc8280xp-lpass-va-macro reg: @@ -30,16 +28,12 @@ properties: const: 0 clocks: - maxItems: 3 + minItems: 1 + maxItems: 4 clock-names: - oneOf: - - items: #for ADSP based platforms - - const: mclk - - const: macro - - const: dcodec - - items: #for ADSP bypass based platforms - - const: mclk + minItems: 1 + maxItems: 4 clock-output-names: maxItems: 1 @@ -63,6 +57,76 @@ required: - compatible - reg - "#sound-dai-cells" + - clock-names + - clocks + +allOf: + - $ref: dai-common.yaml# + + - if: + properties: + compatible: + contains: + const: qcom,sc7280-lpass-va-macro + then: + properties: + clocks: + maxItems: 1 + clock-names: + items: + - const: mclk + + - if: + properties: + compatible: + contains: + const: qcom,sm8250-lpass-va-macro + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: mclk + - const: macro + - const: dcodec + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc8280xp-lpass-va-macro + - qcom,sm8450-lpass-va-macro + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: mclk + - const: macro + - const: dcodec + - const: npl + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8550-lpass-va-macro + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: mclk + - const: macro + - const: dcodec unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml index 66cbb1f5e31a..eea7609d1b33 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml @@ -15,6 +15,7 @@ properties: - qcom,sc7280-lpass-wsa-macro - qcom,sm8250-lpass-wsa-macro - qcom,sm8450-lpass-wsa-macro + - qcom,sm8550-lpass-wsa-macro - qcom,sc8280xp-lpass-wsa-macro reg: @@ -27,11 +28,11 @@ properties: const: 0 clocks: - minItems: 5 + minItems: 4 maxItems: 6 clock-names: - minItems: 5 + minItems: 4 maxItems: 6 clock-output-names: @@ -62,6 +63,7 @@ allOf: then: properties: clocks: + minItems: 5 maxItems: 5 clock-names: items: @@ -89,6 +91,23 @@ allOf: - const: va - const: fsgen + - if: + properties: + compatible: + enum: + - qcom,sm8550-lpass-wsa-macro + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: mclk + - const: macro + - const: dcodec + - const: fsgen + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml index 0110b38f6de9..ce811942a9f1 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml @@ -56,7 +56,7 @@ patternProperties: Compress offload dai. dependencies: - is-compress-dai: ["direction"] + is-compress-dai: [ direction ] required: - reg diff --git a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml index d06f188030a3..044e77718a1b 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml @@ -26,7 +26,7 @@ properties: '#size-cells': const: 0 -#Digital Audio Interfaces +# Digital Audio Interfaces patternProperties: '^dai@[0-9]+$': type: object diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt b/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt deleted file mode 100644 index 1f75feec3dec..000000000000 --- a/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt +++ /dev/null @@ -1,123 +0,0 @@ -QCOM WCD9335 Codec - -Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC, supports -Qualcomm Technologies, Inc. (QTI) multimedia solutions, including -the MSM8996, MSM8976, and MSM8956 chipsets. It has in-built -Soundwire controller, interrupt mux. It supports both I2S/I2C and -SLIMbus audio interfaces. - -Required properties with SLIMbus Interface: - -- compatible: - Usage: required - Value type: <stringlist> - Definition: For SLIMbus interface it should be "slimMID,PID", - textual representation of Manufacturer ID, Product Code, - shall be in lower case hexadecimal with leading zeroes - suppressed. Refer to slimbus/bus.txt for details. - Should be: - "slim217,1a0" for MSM8996 and APQ8096 SoCs with SLIMbus. - -- reg - Usage: required - Value type: <u32 u32> - Definition: Should be ('Device index', 'Instance ID') - -- interrupts - Usage: required - Value type: <prop-encoded-array> - Definition: Interrupts via WCD INTR1 and INTR2 pins - -- interrupt-names: - Usage: required - Value type: <String array> - Definition: Interrupt names of WCD INTR1 and INTR2 - Should be: "intr1", "intr2" - -- reset-gpios: - Usage: required - Value type: <String Array> - Definition: Reset gpio line - -- slim-ifc-dev: - Usage: required - Value type: <phandle> - Definition: SLIM interface device - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: See clock-bindings.txt section "consumers". List of - three clock specifiers for mclk, mclk2 and slimbus clock. - -- clock-names: - Usage: required - Value type: <string> - Definition: Must contain "mclk", "mclk2" and "slimbus" strings. - -- vdd-buck-supply: - Usage: required - Value type: <phandle> - Definition: Should contain a reference to the 1.8V buck supply - -- vdd-buck-sido-supply: - Usage: required - Value type: <phandle> - Definition: Should contain a reference to the 1.8V SIDO buck supply - -- vdd-rx-supply: - Usage: required - Value type: <phandle> - Definition: Should contain a reference to the 1.8V rx supply - -- vdd-tx-supply: - Usage: required - Value type: <phandle> - Definition: Should contain a reference to the 1.8V tx supply - -- vdd-vbat-supply: - Usage: Optional - Value type: <phandle> - Definition: Should contain a reference to the vbat supply - -- vdd-micbias-supply: - Usage: required - Value type: <phandle> - Definition: Should contain a reference to the micbias supply - -- vdd-io-supply: - Usage: required - Value type: <phandle> - Definition: Should contain a reference to the 1.8V io supply - -- interrupt-controller: - Usage: required - Definition: Indicating that this is a interrupt controller - -- #interrupt-cells: - Usage: required - Value type: <int> - Definition: should be 1 - -#sound-dai-cells - Usage: required - Value type: <u32> - Definition: Must be 1 - -audio-codec@1{ - compatible = "slim217,1a0"; - reg = <1 0>; - interrupts = <&msmgpio 54 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "intr2" - reset-gpios = <&msmgpio 64 GPIO_ACTIVE_LOW>; - slim-ifc-dev = <&wc9335_ifd>; - clock-names = "mclk", "native"; - clocks = <&rpmcc RPM_SMD_DIV_CLK1>, - <&rpmcc RPM_SMD_BB_CLK1>; - vdd-buck-supply = <&pm8994_s4>; - vdd-rx-supply = <&pm8994_s4>; - vdd-buck-sido-supply = <&pm8994_s4>; - vdd-tx-supply = <&pm8994_s4>; - vdd-io-supply = <&pm8994_s4>; - #sound-dai-cells = <1>; -} diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd9335.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd9335.yaml new file mode 100644 index 000000000000..34f8fe4da9d4 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wcd9335.yaml @@ -0,0 +1,156 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wcd9335.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm WCD9335 Audio Codec + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: + Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC with in-built + Soundwire controller and interrupt mux. It supports both I2S/I2C and SLIMbus + audio interfaces. + +properties: + compatible: + const: slim217,1a0 + + reg: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: mclk + - const: slimbus + + interrupts: + maxItems: 2 + + interrupt-names: + items: + - const: intr1 + - const: intr2 + + interrupt-controller: true + + '#interrupt-cells': + const: 1 + + reset-gpios: + maxItems: 1 + + slim-ifc-dev: + description: SLIM IFC device interface + $ref: /schemas/types.yaml#/definitions/phandle + + '#sound-dai-cells': + const: 1 + + vdd-buck-supply: + description: 1.8V buck supply + + vdd-buck-sido-supply: + description: 1.8V SIDO buck supply + + vdd-io-supply: + description: 1.8V I/O supply + + vdd-micbias-supply: + description: micbias supply + + vdd-rx-supply: + description: 1.8V rx supply + + vdd-tx-supply: + description: 1.8V tx supply + + vdd-vbat-supply: + description: vbat supply + +required: + - compatible + - reg + +allOf: + - $ref: dai-common.yaml# + - if: + required: + - slim-ifc-dev + then: + required: + - clocks + - clock-names + - interrupts + - interrupt-names + - interrupt-controller + - '#interrupt-cells' + - reset-gpios + - slim-ifc-dev + - '#sound-dai-cells' + - vdd-buck-supply + - vdd-buck-sido-supply + - vdd-io-supply + - vdd-rx-supply + - vdd-tx-supply + else: + properties: + clocks: false + clock-names: false + interrupts: false + interrupt-names: false + interrupt-controller: false + '#interrupt-cells': false + reset-gpios: false + slim-ifc-dev: false + '#sound-dai-cells': false + vdd-buck-supply: false + vdd-buck-sido-supply: false + vdd-io-supply: false + vdd-micbias-supply: false + vdd-rx-supply: false + vdd-tx-supply: false + vdd-vbat-supply: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + tasha_ifd: codec@0,0 { + compatible = "slim217,1a0"; + reg = <0 0>; + }; + + codec@1,0 { + compatible = "slim217,1a0"; + reg = <1 0>; + + clock-names = "mclk", "slimbus"; + clocks = <&div1_mclk>, <&rpmcc RPM_SMD_BB_CLK1>; + + interrupt-parent = <&tlmm>; + interrupts = <54 IRQ_TYPE_LEVEL_HIGH>, + <53 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "intr1", "intr2"; + interrupt-controller; + #interrupt-cells = <1>; + + reset-gpios = <&tlmm 64 GPIO_ACTIVE_LOW>; + slim-ifc-dev = <&tasha_ifd>; + #sound-dai-cells = <1>; + + vdd-buck-supply = <&vreg_s4a_1p8>; + vdd-buck-sido-supply = <&vreg_s4a_1p8>; + vdd-tx-supply = <&vreg_s4a_1p8>; + vdd-rx-supply = <&vreg_s4a_1p8>; + vdd-io-supply = <&vreg_s4a_1p8>; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml index ea09590bfa30..4df59f3b7b01 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml @@ -134,6 +134,7 @@ properties: patternProperties: "^.*@[0-9a-f]+$": type: object + additionalProperties: true description: | WCD934x subnode for each slave devices. Bindings of each subnodes depends on the specific driver providing the functionality and @@ -151,6 +152,7 @@ required: - reg allOf: + - $ref: dai-common.yaml# - if: required: - slim-ifc-dev diff --git a/Documentation/devicetree/bindings/sound/realtek,alc5632.yaml b/Documentation/devicetree/bindings/sound/realtek,alc5632.yaml new file mode 100644 index 000000000000..fb05988ff7ea --- /dev/null +++ b/Documentation/devicetree/bindings/sound/realtek,alc5632.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/realtek,alc5632.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ALC5632 audio CODEC + +description: | + Pins on the device (for linking into audio routes): + * SPK_OUTP + * SPK_OUTN + * HP_OUT_L + * HP_OUT_R + * AUX_OUT_P + * AUX_OUT_N + * LINE_IN_L + * LINE_IN_R + * PHONE_P + * PHONE_N + * MIC1_P + * MIC1_N + * MIC2_P + * MIC2_N + * MICBIAS1 + * DMICDAT + +maintainers: + - Leon Romanovsky <leon@leon.nu> + +properties: + compatible: + const: realtek,alc5632 + + reg: + maxItems: 1 + + '#gpio-cells': + const: 2 + + gpio-controller: true + +required: + - compatible + - reg + - '#gpio-cells' + - gpio-controller + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1a { + compatible = "realtek,alc5632"; + reg = <0x1a>; + gpio-controller; + #gpio-cells = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 12ccf29338d9..8a821dec9526 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -101,17 +101,7 @@ properties: clock-names: description: List of necessary clock names. - minItems: 1 - maxItems: 31 - items: - oneOf: - - const: ssi-all - - pattern: '^ssi\.[0-9]$' - - pattern: '^src\.[0-9]$' - - pattern: '^mix\.[0-1]$' - - pattern: '^ctu\.[0-1]$' - - pattern: '^dvc\.[0-1]$' - - pattern: '^clk_(a|b|c|i)$' + # details are defined below ports: $ref: audio-graph-port.yaml#/definitions/port-base @@ -155,7 +145,7 @@ properties: dmas: maxItems: 1 dma-names: - const: "tx" + const: tx required: - dmas - dma-names @@ -288,6 +278,11 @@ required: allOf: - $ref: dai-common.yaml# + + # -------------------- + # reg/reg-names + # -------------------- + # for Gen1 - if: properties: compatible: @@ -303,7 +298,15 @@ allOf: - scu - ssi - adg - else: + # for Gen2/Gen3 + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar_sound-gen2 + - renesas,rcar_sound-gen3 + then: properties: reg: minItems: 5 @@ -315,35 +318,87 @@ allOf: - ssiu - ssi - audmapp + # for Gen4 + - if: + properties: + compatible: + contains: + const: renesas,rcar_sound-gen4 + then: + properties: + reg: + maxItems: 4 + reg-names: + items: + enum: + - adg + - ssiu + - ssi + - sdmc + + # -------------------- + # clock-names + # -------------------- + - if: + properties: + compatible: + contains: + const: renesas,rcar_sound-gen4 + then: + properties: + clock-names: + maxItems: 3 + items: + enum: + - ssi.0 + - ssiu.0 + - clkin + else: + properties: + clock-names: + minItems: 1 + maxItems: 31 + items: + oneOf: + - const: ssi-all + - pattern: '^ssi\.[0-9]$' + - pattern: '^src\.[0-9]$' + - pattern: '^mix\.[0-1]$' + - pattern: '^ctu\.[0-1]$' + - pattern: '^dvc\.[0-1]$' + - pattern: '^clk_(a|b|c|i)$' unevaluatedProperties: false examples: - | + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> rcar_sound: sound@ec500000 { #sound-dai-cells = <1>; compatible = "renesas,rcar_sound-r8a7790", "renesas,rcar_sound-gen2"; reg = <0xec500000 0x1000>, /* SCU */ <0xec5a0000 0x100>, /* ADG */ <0xec540000 0x1000>, /* SSIU */ - <0xec541000 0x1280>, /* SSI */ + <0xec541000 0x280>, /* SSI */ <0xec740000 0x200>; /* Audio DMAC peri peri*/ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp"; - clocks = <&mstp10_clks 1005>, /* SSI-ALL */ - <&mstp10_clks 1006>, <&mstp10_clks 1007>, /* SSI9, SSI8 */ - <&mstp10_clks 1008>, <&mstp10_clks 1009>, /* SSI7, SSI6 */ - <&mstp10_clks 1010>, <&mstp10_clks 1011>, /* SSI5, SSI4 */ - <&mstp10_clks 1012>, <&mstp10_clks 1013>, /* SSI3, SSI2 */ - <&mstp10_clks 1014>, <&mstp10_clks 1015>, /* SSI1, SSI0 */ - <&mstp10_clks 1022>, <&mstp10_clks 1023>, /* SRC9, SRC8 */ - <&mstp10_clks 1024>, <&mstp10_clks 1025>, /* SRC7, SRC6 */ - <&mstp10_clks 1026>, <&mstp10_clks 1027>, /* SRC5, SRC4 */ - <&mstp10_clks 1028>, <&mstp10_clks 1029>, /* SRC3, SRC2 */ - <&mstp10_clks 1030>, <&mstp10_clks 1031>, /* SRC1, SRC0 */ - <&mstp10_clks 1020>, <&mstp10_clks 1021>, /* MIX1, MIX0 */ - <&mstp10_clks 1020>, <&mstp10_clks 1021>, /* CTU1, CTU0 */ - <&mstp10_clks 1019>, <&mstp10_clks 1018>, /* DVC0, DVC1 */ + clocks = <&cpg CPG_MOD 1005>, /* SSI-ALL */ + <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>, /* SSI9, SSI8 */ + <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>, /* SSI7, SSI6 */ + <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>, /* SSI5, SSI4 */ + <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>, /* SSI3, SSI2 */ + <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>, /* SSI1, SSI0 */ + <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>, /* SRC9, SRC8 */ + <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>, /* SRC7, SRC6 */ + <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>, /* SRC5, SRC4 */ + <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>, /* SRC3, SRC2 */ + <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>, /* SRC1, SRC0 */ + <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>, /* MIX1, MIX0 */ + <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>, /* CTU1, CTU0 */ + <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>, /* DVC0, DVC1 */ <&audio_clk_a>, <&audio_clk_b>, /* CLKA, CLKB */ <&audio_clk_c>, <&audio_clk_i>; /* CLKC, CLKI */ @@ -364,6 +419,17 @@ examples: "clk_a", "clk_b", "clk_c", "clk_i"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + + resets = <&cpg 1005>, + <&cpg 1006>, <&cpg 1007>, <&cpg 1008>, <&cpg 1009>, + <&cpg 1010>, <&cpg 1011>, <&cpg 1012>, <&cpg 1013>, + <&cpg 1014>, <&cpg 1015>; + reset-names = "ssi-all", + "ssi.9", "ssi.8", "ssi.7", "ssi.6", + "ssi.5", "ssi.4", "ssi.3", "ssi.2", + "ssi.1", "ssi.0"; + rcar_sound,dvc { dvc0: dvc-0 { dmas = <&audma0 0xbc>; @@ -396,7 +462,7 @@ examples: status = "disabled"; }; src1: src-1 { - interrupts = <0 353 0>; + interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>; dmas = <&audma0 0x87>, <&audma1 0x9c>; dma-names = "rx", "tx"; }; @@ -417,12 +483,12 @@ examples: rcar_sound,ssi { ssi0: ssi-0 { - interrupts = <0 370 1>; + interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>; dmas = <&audma0 0x01>, <&audma1 0x02>; dma-names = "rx", "tx"; }; ssi1: ssi-1 { - interrupts = <0 371 1>; + interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>; dmas = <&audma0 0x03>, <&audma1 0x04>; dma-names = "rx", "tx"; }; @@ -464,7 +530,6 @@ examples: }; }; - /* assume audio-graph */ codec { port { diff --git a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml index 196881d94396..3b5ae45eee4a 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml @@ -25,14 +25,18 @@ properties: maxItems: 1 interrupts: - maxItems: 4 + minItems: 2 + maxItems: 3 interrupt-names: - items: - - const: int_req - - const: dma_rx - - const: dma_tx - - const: dma_rt + oneOf: + - items: + - const: int_req + - const: dma_rx + - const: dma_tx + - items: + - const: int_req + - const: dma_rt clocks: maxItems: 4 @@ -106,9 +110,8 @@ examples: reg = <0x10049c00 0x400>; interrupts = <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 327 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 328 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 329 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "int_req", "dma_rx", "dma_tx", "dma_rt"; + <GIC_SPI 328 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "int_req", "dma_rx", "dma_tx"; clocks = <&cpg CPG_MOD R9A07G044_SSI0_PCLK2>, <&cpg CPG_MOD R9A07G044_SSI0_PCLK_SFR>, <&audio_clk1>, diff --git a/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml b/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml index 4c95895de75e..7bb6c5dff786 100644 --- a/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml +++ b/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml @@ -86,6 +86,13 @@ properties: - tx-m - rx-m + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + + power-domains: + maxItems: 1 + rockchip,grf: $ref: /schemas/types.yaml#/definitions/phandle description: diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml index 1cb4da300607..fcb01abffa97 100644 --- a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml @@ -34,6 +34,7 @@ properties: - rockchip,rk3366-i2s - rockchip,rk3368-i2s - rockchip,rk3399-i2s + - rockchip,rk3588-i2s - rockchip,rv1126-i2s - const: rockchip,rk3066-i2s @@ -82,6 +83,10 @@ properties: resets: maxItems: 2 + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + rockchip,capture-channels: $ref: /schemas/types.yaml#/definitions/uint32 default: 2 diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml index 7774543b8819..c6751c40e63f 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml @@ -35,12 +35,14 @@ properties: cpu: type: object + additionalProperties: false properties: sound-dai: description: phandles to the I2S controllers codec: type: object + additionalProperties: false properties: sound-dai: minItems: 1 diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml index 02059d66b084..1353c051488f 100644 --- a/Documentation/devicetree/bindings/sound/sgtl5000.yaml +++ b/Documentation/devicetree/bindings/sound/sgtl5000.yaml @@ -50,7 +50,7 @@ properties: description: The bias voltage to be used in mVolts. The voltage can take values from 1.25V to 3V by 250mV steps. If this node is not mentioned or the value is unknown, then the value is set to 1.25V. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000 ] lrclk-strength: @@ -63,7 +63,7 @@ properties: 1 = 1.66 mA 2.87 mA 4.02 mA 2 = 3.33 mA 5.74 mA 8.03 mA 3 = 4.99 mA 8.61 mA 12.05 mA - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 0, 1, 2, 3 ] sclk-strength: @@ -76,7 +76,7 @@ properties: 1 = 1.66 mA 2.87 mA 4.02 mA 2 = 3.33 mA 5.74 mA 8.03 mA 3 = 4.99 mA 8.61 mA 12.05 mA - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 0, 1, 2, 3 ] port: diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml index f0d81bfe2598..b05e05c81cc4 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.yaml +++ b/Documentation/devicetree/bindings/sound/simple-card.yaml @@ -78,7 +78,7 @@ definitions: $ref: /schemas/types.yaml#/definitions/uint32 prefix: - description: "device name prefix" + description: device name prefix $ref: /schemas/types.yaml#/definitions/string label: @@ -262,9 +262,9 @@ required: additionalProperties: false examples: -#-------------------- +# -------------------- # single DAI link -#-------------------- +# -------------------- - | sound { compatible = "simple-audio-card"; @@ -291,9 +291,9 @@ examples: }; }; -#-------------------- +# -------------------- # Multi DAI links -#-------------------- +# -------------------- - | sound { compatible = "simple-audio-card"; @@ -334,10 +334,10 @@ examples: }; }; -#-------------------- +# -------------------- # route audio from IMX6 SSI2 through TLV320DAC3100 codec # through TPA6130A2 amplifier to headphones: -#-------------------- +# -------------------- - | sound { compatible = "simple-audio-card"; @@ -359,9 +359,9 @@ examples: }; }; -#-------------------- +# -------------------- # Sampling Rate Conversion -#-------------------- +# -------------------- - | sound { compatible = "simple-audio-card"; @@ -387,9 +387,9 @@ examples: }; }; -#-------------------- +# -------------------- # 2 CPU 1 Codec (Mixing) -#-------------------- +# -------------------- - | sound { compatible = "simple-audio-card"; @@ -424,7 +424,7 @@ examples: }; }; -#-------------------- +# -------------------- # Multi DAI links with DPCM: # # CPU0 ------ ak4613 @@ -433,7 +433,7 @@ examples: # CPU3 --/ /* DPCM 5ch/6ch */ # CPU4 --/ /* DPCM 7ch/8ch */ # CPU5 ------ PCM3168A-c -#-------------------- +# -------------------- - | sound { compatible = "simple-audio-card"; diff --git a/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml b/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml index 9cf0efaed88e..8600520d7c47 100644 --- a/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml +++ b/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml @@ -42,7 +42,7 @@ properties: Specifies a phandle to soc-glue, which is used for changing mode of S/PDIF signal pin to output from Hi-Z. This property is optional if you use I2S signal pins only. - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle "#sound-dai-cells": const: 1 diff --git a/Documentation/devicetree/bindings/sound/tas2562.yaml b/Documentation/devicetree/bindings/sound/tas2562.yaml index 1085592cefcc..a5bb561bfcfb 100644 --- a/Documentation/devicetree/bindings/sound/tas2562.yaml +++ b/Documentation/devicetree/bindings/sound/tas2562.yaml @@ -66,7 +66,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; codec: codec@4c { diff --git a/Documentation/devicetree/bindings/sound/tas2770.yaml b/Documentation/devicetree/bindings/sound/tas2770.yaml index 982949ba8a4b..26088adb9dc2 100644 --- a/Documentation/devicetree/bindings/sound/tas2770.yaml +++ b/Documentation/devicetree/bindings/sound/tas2770.yaml @@ -68,7 +68,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; codec: codec@41 { diff --git a/Documentation/devicetree/bindings/sound/tas27xx.yaml b/Documentation/devicetree/bindings/sound/tas27xx.yaml index 0957dd435bb4..8cba01316855 100644 --- a/Documentation/devicetree/bindings/sound/tas27xx.yaml +++ b/Documentation/devicetree/bindings/sound/tas27xx.yaml @@ -61,7 +61,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; codec: codec@38 { diff --git a/Documentation/devicetree/bindings/sound/tas571x.txt b/Documentation/devicetree/bindings/sound/tas571x.txt index 7c8fd37c2f9e..1addc75989d5 100644 --- a/Documentation/devicetree/bindings/sound/tas571x.txt +++ b/Documentation/devicetree/bindings/sound/tas571x.txt @@ -12,6 +12,7 @@ Required properties: - "ti,tas5717", - "ti,tas5719", - "ti,tas5721" + - "ti,tas5733" - reg: The I2C address of the device - #sound-dai-cells: must be equal to 0 diff --git a/Documentation/devicetree/bindings/sound/tas5805m.yaml b/Documentation/devicetree/bindings/sound/tas5805m.yaml index 3aade02d8a96..63edf52f061c 100644 --- a/Documentation/devicetree/bindings/sound/tas5805m.yaml +++ b/Documentation/devicetree/bindings/sound/tas5805m.yaml @@ -39,7 +39,7 @@ properties: examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; tas5805m: tas5805m@2c { diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index 6b8214071115..c16e1760cf85 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -192,7 +192,7 @@ additionalProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; codec: codec@4c { diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8510.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8510.yaml new file mode 100644 index 000000000000..6d12b0ac37e2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8510.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8510.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8510 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8510 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "wlf,wm8510"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8523.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8523.yaml new file mode 100644 index 000000000000..decc395bb873 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8523.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8523.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8523 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8523 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1a { + compatible = "wlf,wm8523"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml new file mode 100644 index 000000000000..4d951ece394e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8524.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8524.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wolfson WM8524 24-bit 192KHz Stereo DAC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8524 + + "#sound-dai-cells": + const: 0 + + wlf,mute-gpios: + maxItems: 1 + description: + a GPIO spec for the MUTE pin. + +required: + - compatible + - wlf,mute-gpios + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + wm8524: codec { + compatible = "wlf,wm8524"; + wlf,mute-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8580.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8580.yaml new file mode 100644 index 000000000000..2f27852cdc20 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8580.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8580.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8580 and WM8581 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - wlf,wm8580 + - wlf,wm8581 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1a { + compatible = "wlf,wm8580"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8711.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8711.yaml new file mode 100644 index 000000000000..ecaac2818b44 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8711.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8711.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8711 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8711 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1a { + compatible = "wlf,wm8711"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8728.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8728.yaml new file mode 100644 index 000000000000..fc89475a051e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8728.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8728.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8728 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8728 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1a { + compatible = "wlf,wm8728"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8737.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8737.yaml new file mode 100644 index 000000000000..12d8765726d8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8737.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8737.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8737 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8737 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1a { + compatible = "wlf,wm8737"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8753.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8753.yaml new file mode 100644 index 000000000000..9eebe7d7f0b7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8753.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8753.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8753 audio CODEC + +description: | + Pins on the device (for linking into audio routes): + * LOUT1 + * LOUT2 + * ROUT1 + * ROUT2 + * MONO1 + * MONO2 + * OUT3 + * OUT4 + * LINE1 + * LINE2 + * RXP + * RXN + * ACIN + * ACOP + * MIC1N + * MIC1 + * MIC2N + * MIC2 + * Mic Bias + +maintainers: + - patches@opensource.cirrus.com + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8753 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1a { + compatible = "wlf,wm8753"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml new file mode 100644 index 000000000000..ee8eba7f0104 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8960.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wolfson WM8960 audio codec + +maintainers: + - patches@opensource.cirrus.com + +properties: + compatible: + const: wlf,wm8960 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: mclk + + '#sound-dai-cells': + const: 0 + + wlf,capless: + type: boolean + description: + If present, OUT3 pin will be enabled and disabled together with HP_L and + HP_R pins in response to jack detect events. + + wlf,gpio-cfg: + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 2 + description: | + A list of GPIO configuration register values. + - gpio-cfg[0]: ALRCGPIO of R9 (Audio interface) + - gpio-cfg[1]: {GPIOPOL:GPIOSEL[2:0]} of R48 (Additional Control 4). + + wlf,hp-cfg: + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 3 + description: | + A list of headphone jack detect configuration register values: + - hp-cfg[0]: HPSEL[1:0] of R48 (Additional Control 4). + - hp-cfg[1]: {HPSWEN:HPSWPOL} of R24 (Additional Control 2). + - hp-cfg[2]: {TOCLKSEL:TOEN} of R23 (Additional Control 1). + + wlf,shared-lrclk: + type: boolean + description: + If present, the LRCM bit of R24 (Additional control 2) gets set, + indicating that ADCLRC and DACLRC pins will be disabled only when ADC + (Left and Right) and DAC (Left and Right) are disabled. + When WM8960 works on synchronize mode and DACLRC pin is used to supply + frame clock, it will no frame clock for captrue unless enable DAC to + enable DACLRC pin. If shared-lrclk is present, no need to enable DAC for + captrue. + +required: + - compatible + - reg + +allOf: + - $ref: dai-common.yaml# + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + audio-codec@1a { + compatible = "wlf,wm8960"; + reg = <0x1a>; + clocks = <&clks 0>; + clock-names = "mclk"; + #sound-dai-cells = <0>; + wlf,hp-cfg = <3 2 3>; + wlf,gpio-cfg = <1 3>; + wlf,shared-lrclk; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8994.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8994.yaml new file mode 100644 index 000000000000..8f045de02850 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8994.yaml @@ -0,0 +1,194 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8994.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wolfson WM1811/WM8994/WM8958 audio codecs + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - patches@opensource.cirrus.com + +description: | + These devices support both I2C and SPI (configured with pin strapping on the + board). + + Pins on the device (for linking into audio routes): + IN1LN, IN1LP, IN2LN, IN2LP:VXRN, IN1RN, IN1RP, IN2RN, IN2RP:VXRP, SPKOUTLP, + SPKOUTLN, SPKOUTRP, SPKOUTRN, HPOUT1L, HPOUT1R, HPOUT2P, HPOUT2N, LINEOUT1P, + LINEOUT1N, LINEOUT2P, LINEOUT2N. + +properties: + compatible: + enum: + - wlf,wm1811 + - wlf,wm8994 + - wlf,wm8958 + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: MCLK1 + - const: MCLK2 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + description: + The first cell is the IRQ number. The second cell is the flags, encoded + as the trigger masks. + + AVDD1-supply: true + AVDD2-supply: true + CPVDD-supply: true + DBVDD-supply: true + DBVDD1-supply: true + DBVDD2-supply: true + DBVDD3-supply: true + DCVDD-supply: true + LDO1VDD-supply: true + LDO2VDD-supply: true + SPKVDD1-supply: true + SPKVDD2-supply: true + + '#sound-dai-cells': + const: 0 + + wlf,gpio-cfg: + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 11 + description: + A list of GPIO configuration register values. If absent, no configuration + of these registers is performed. If any value is over 0xffff then the + register will be left as default. If present 11 values must be supplied. + + wlf,micbias-cfg: + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 2 + description: + Two MICBIAS register values for WM1811 or WM8958. If absent the register + defaults will be used. + + wlf,ldo1ena-gpios: + maxItems: 1 + description: + Control of LDO1ENA input to device. + + wlf,ldo2ena-gpios: + maxItems: 1 + description: + Control of LDO2ENA input to device. + + wlf,lineout1-se: + type: boolean + description: + LINEOUT1 is in single ended mode. + + wlf,lineout2-se: + type: boolean + description: + INEOUT2 is in single ended mode. + + wlf,lineout1-feedback: + type: boolean + description: + LINEOUT1 has common mode feedback connected. + + wlf,lineout2-feedback: + type: boolean + description: + LINEOUT2 has common mode feedback connected. + + wlf,ldoena-always-driven: + type: boolean + description: + LDOENA is always driven. + + wlf,spkmode-pu: + type: boolean + description: + Enable the internal pull-up resistor on the SPKMODE pin. + + wlf,csnaddr-pd: + type: boolean + description: + Enable the internal pull-down resistor on the CS/ADDR pin. + +required: + - compatible + - reg + - AVDD2-supply + - CPVDD-supply + - SPKVDD1-supply + - SPKVDD2-supply + +allOf: + - $ref: dai-common.yaml# + - if: + properties: + compatible: + enum: + - wlf,wm1811 + - wlf,wm8958 + then: + properties: + DBVDD-supply: false + LDO2VDD-supply: false + required: + - DBVDD1-supply + - DBVDD2-supply + - DBVDD3-supply + else: + properties: + DBVDD1-supply: false + DBVDD2-supply: false + DBVDD3-supply: false + required: + - DBVDD-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + audio-codec@1a { + compatible = "wlf,wm1811"; + reg = <0x1a>; + clocks = <&i2s0 0>; + clock-names = "MCLK1"; + + AVDD2-supply = <&main_dc_reg>; + CPVDD-supply = <&main_dc_reg>; + DBVDD1-supply = <&main_dc_reg>; + DBVDD2-supply = <&main_dc_reg>; + DBVDD3-supply = <&main_dc_reg>; + LDO1VDD-supply = <&main_dc_reg>; + SPKVDD1-supply = <&main_dc_reg>; + SPKVDD2-supply = <&main_dc_reg>; + + wlf,ldo1ena-gpios = <&gpb0 0 GPIO_ACTIVE_HIGH>; + wlf,ldo2ena-gpios = <&gpb0 1 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wm8510.txt b/Documentation/devicetree/bindings/sound/wm8510.txt deleted file mode 100644 index e6b6cc041f89..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8510.txt +++ /dev/null @@ -1,18 +0,0 @@ -WM8510 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8510" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Example: - -wm8510: codec@1a { - compatible = "wlf,wm8510"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8523.txt b/Documentation/devicetree/bindings/sound/wm8523.txt deleted file mode 100644 index f3a6485f4b8a..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8523.txt +++ /dev/null @@ -1,16 +0,0 @@ -WM8523 audio CODEC - -This device supports I2C only. - -Required properties: - - - compatible : "wlf,wm8523" - - - reg : the I2C address of the device. - -Example: - -wm8523: codec@1a { - compatible = "wlf,wm8523"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8524.txt b/Documentation/devicetree/bindings/sound/wm8524.txt deleted file mode 100644 index f6c0c263b135..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8524.txt +++ /dev/null @@ -1,16 +0,0 @@ -WM8524 audio CODEC - -This device does not use I2C or SPI but a simple Hardware Control Interface. - -Required properties: - - - compatible : "wlf,wm8524" - - - wlf,mute-gpios: a GPIO spec for the MUTE pin. - -Example: - -wm8524: codec { - compatible = "wlf,wm8524"; - wlf,mute-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8580.txt b/Documentation/devicetree/bindings/sound/wm8580.txt deleted file mode 100644 index ff3f9f5f2111..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8580.txt +++ /dev/null @@ -1,16 +0,0 @@ -WM8580 and WM8581 audio CODEC - -This device supports I2C only. - -Required properties: - - - compatible : "wlf,wm8580", "wlf,wm8581" - - - reg : the I2C address of the device. - -Example: - -wm8580: codec@1a { - compatible = "wlf,wm8580"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8711.txt b/Documentation/devicetree/bindings/sound/wm8711.txt deleted file mode 100644 index c30a1387c4bf..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8711.txt +++ /dev/null @@ -1,18 +0,0 @@ -WM8711 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8711" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Example: - -wm8711: codec@1a { - compatible = "wlf,wm8711"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8728.txt b/Documentation/devicetree/bindings/sound/wm8728.txt deleted file mode 100644 index a3608b4c78b9..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8728.txt +++ /dev/null @@ -1,18 +0,0 @@ -WM8728 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8728" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Example: - -wm8728: codec@1a { - compatible = "wlf,wm8728"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8737.txt b/Documentation/devicetree/bindings/sound/wm8737.txt deleted file mode 100644 index eda1ec6a7563..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8737.txt +++ /dev/null @@ -1,18 +0,0 @@ -WM8737 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8737" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Example: - -wm8737: codec@1a { - compatible = "wlf,wm8737"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8753.txt b/Documentation/devicetree/bindings/sound/wm8753.txt deleted file mode 100644 index eca9e5a825a9..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8753.txt +++ /dev/null @@ -1,40 +0,0 @@ -WM8753 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8753" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Pins on the device (for linking into audio routes): - - * LOUT1 - * LOUT2 - * ROUT1 - * ROUT2 - * MONO1 - * MONO2 - * OUT3 - * OUT4 - * LINE1 - * LINE2 - * RXP - * RXN - * ACIN - * ACOP - * MIC1N - * MIC1 - * MIC2N - * MIC2 - * Mic Bias - -Example: - -wm8753: codec@1a { - compatible = "wlf,wm8753"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8960.txt b/Documentation/devicetree/bindings/sound/wm8960.txt deleted file mode 100644 index 85d3b287108c..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8960.txt +++ /dev/null @@ -1,42 +0,0 @@ -WM8960 audio CODEC - -This device supports I2C only. - -Required properties: - - - compatible : "wlf,wm8960" - - - reg : the I2C address of the device. - -Optional properties: - - wlf,shared-lrclk: This is a boolean property. If present, the LRCM bit of - R24 (Additional control 2) gets set, indicating that ADCLRC and DACLRC pins - will be disabled only when ADC (Left and Right) and DAC (Left and Right) - are disabled. - When wm8960 works on synchronize mode and DACLRC pin is used to supply - frame clock, it will no frame clock for captrue unless enable DAC to enable - DACLRC pin. If shared-lrclk is present, no need to enable DAC for captrue. - - - wlf,capless: This is a boolean property. If present, OUT3 pin will be - enabled and disabled together with HP_L and HP_R pins in response to jack - detect events. - - - wlf,hp-cfg: A list of headphone jack detect configuration register values. - The list must be 3 entries long. - hp-cfg[0]: HPSEL[1:0] of R48 (Additional Control 4). - hp-cfg[1]: {HPSWEN:HPSWPOL} of R24 (Additional Control 2). - hp-cfg[2]: {TOCLKSEL:TOEN} of R23 (Additional Control 1). - - - wlf,gpio-cfg: A list of GPIO configuration register values. - The list must be 2 entries long. - gpio-cfg[0]: ALRCGPIO of R9 (Audio interface) - gpio-cfg[1]: {GPIOPOL:GPIOSEL[2:0]} of R48 (Additional Control 4). - -Example: - -wm8960: codec@1a { - compatible = "wlf,wm8960"; - reg = <0x1a>; - - wlf,shared-lrclk; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt b/Documentation/devicetree/bindings/sound/wm8994.txt deleted file mode 100644 index 8fa947509c10..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8994.txt +++ /dev/null @@ -1,112 +0,0 @@ -WM1811/WM8994/WM8958 audio CODEC - -These devices support both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : One of "wlf,wm1811", "wlf,wm8994" or "wlf,wm8958". - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - - - gpio-controller : Indicates this device is a GPIO controller. - - #gpio-cells : Must be 2. The first cell is the pin number and the - second cell is used to specify optional parameters (currently unused). - - - power supplies for the device, as covered in - Documentation/devicetree/bindings/regulator/regulator.txt, depending - on compatible: - - for wlf,wm1811 and wlf,wm8958: - AVDD1-supply, AVDD2-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, - DCVDD-supply, CPVDD-supply, SPKVDD1-supply, SPKVDD2-supply - - for wlf,wm8994: - AVDD1-supply, AVDD2-supply, DBVDD-supply, DCVDD-supply, CPVDD-supply, - SPKVDD1-supply, SPKVDD2-supply - -Optional properties: - - - interrupts : The interrupt line the IRQ signal for the device is - connected to. This is optional, if it is not connected then none - of the interrupt related properties should be specified. - - interrupt-controller : These devices contain interrupt controllers - and may provide interrupt services to other devices if they have an - interrupt line connected. - - #interrupt-cells: the number of cells to describe an IRQ, this should be 2. - The first cell is the IRQ number. - The second cell is the flags, encoded as the trigger masks from - Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - - - clocks : A list of up to two phandle and clock specifier pairs - - clock-names : A list of clock names sorted in the same order as clocks. - Valid clock names are "MCLK1" and "MCLK2". - - - wlf,gpio-cfg : A list of GPIO configuration register values. If absent, - no configuration of these registers is performed. If any value is - over 0xffff then the register will be left as default. If present 11 - values must be supplied. - - - wlf,micbias-cfg : Two MICBIAS register values for WM1811 or - WM8958. If absent the register defaults will be used. - - - wlf,ldo1ena : GPIO specifier for control of LDO1ENA input to device. - - wlf,ldo2ena : GPIO specifier for control of LDO2ENA input to device. - - - wlf,lineout1-se : If present LINEOUT1 is in single ended mode. - - wlf,lineout2-se : If present LINEOUT2 is in single ended mode. - - - wlf,lineout1-feedback : If present LINEOUT1 has common mode feedback - connected. - - wlf,lineout2-feedback : If present LINEOUT2 has common mode feedback - connected. - - - wlf,ldoena-always-driven : If present LDOENA is always driven. - - - wlf,spkmode-pu : If present enable the internal pull-up resistor on - the SPKMODE pin. - - - wlf,csnaddr-pd : If present enable the internal pull-down resistor on - the CS/ADDR pin. - -Pins on the device (for linking into audio routes): - - * IN1LN - * IN1LP - * IN2LN - * IN2LP:VXRN - * IN1RN - * IN1RP - * IN2RN - * IN2RP:VXRP - * SPKOUTLP - * SPKOUTLN - * SPKOUTRP - * SPKOUTRN - * HPOUT1L - * HPOUT1R - * HPOUT2P - * HPOUT2N - * LINEOUT1P - * LINEOUT1N - * LINEOUT2P - * LINEOUT2N - -Example: - -wm8994: codec@1a { - compatible = "wlf,wm8994"; - reg = <0x1a>; - - gpio-controller; - #gpio-cells = <2>; - - lineout1-se; - - AVDD1-supply = <®ulator>; - AVDD2-supply = <®ulator>; - CPVDD-supply = <®ulator>; - DBVDD-supply = <®ulator>; - DCVDD-supply = <®ulator>; - SPKVDD1-supply = <®ulator>; - SPKVDD2-supply = <®ulator>; -}; diff --git a/Documentation/devicetree/bindings/sound/zl38060.yaml b/Documentation/devicetree/bindings/sound/zl38060.yaml index 2c5c02e34573..8bd201e573aa 100644 --- a/Documentation/devicetree/bindings/sound/zl38060.yaml +++ b/Documentation/devicetree/bindings/sound/zl38060.yaml @@ -56,7 +56,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/gpio/gpio.h> - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml index 3efdc192ab01..e4dba825ab11 100644 --- a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml +++ b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml @@ -200,6 +200,7 @@ properties: patternProperties: "^.*@[0-9a-f],[0-9a-f]$": type: object + additionalProperties: true description: Child nodes for a standalone audio codec or speaker amplifier IC. It has RX and TX Soundwire secondary devices. diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml index eb0567b2971a..2155478bfc4d 100644 --- a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml +++ b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml @@ -51,6 +51,7 @@ properties: patternProperties: "^.*@[0-9a-f]+": type: object + additionalProperties: true properties: reg: items: diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml index acf218507d22..de36c6a34a0f 100644 --- a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml +++ b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml @@ -63,6 +63,7 @@ properties: patternProperties: "^.*@[0-9a-f]+": type: object + additionalProperties: true properties: reg: items: diff --git a/Documentation/devicetree/bindings/spi/amlogic,a1-spifc.yaml b/Documentation/devicetree/bindings/spi/amlogic,a1-spifc.yaml new file mode 100644 index 000000000000..ea47d30eef43 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/amlogic,a1-spifc.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/amlogic,a1-spifc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic A1 SPI Flash Controller + +maintainers: + - Martin Kurbanov <mmkurbanov@sberdevices.ru> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + enum: + - amlogic,a1-spifc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +unevaluatedProperties: false + +examples: + - | + spi@fd000400 { + compatible = "amlogic,a1-spifc"; + reg = <0xfd000400 0x290>; + clocks = <&clkc_clkid_spifc>; + #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 5c01db128be0..b310069762dd 100644 --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml @@ -19,6 +19,33 @@ allOf: then: required: - power-domains + - if: + properties: + compatible: + contains: + const: starfive,jh7110-qspi + then: + properties: + resets: + minItems: 2 + maxItems: 3 + + reset-names: + minItems: 2 + maxItems: 3 + items: + enum: [ qspi, qspi-ocp, rstc_ref ] + + else: + properties: + resets: + maxItems: 2 + + reset-names: + minItems: 1 + maxItems: 2 + items: + enum: [ qspi, qspi-ocp ] properties: compatible: @@ -30,6 +57,7 @@ properties: - intel,lgm-qspi - xlnx,versal-ospi-1.0 - intel,socfpga-qspi + - starfive,jh7110-qspi - const: cdns,qspi-nor - const: cdns,qspi-nor @@ -79,13 +107,14 @@ properties: maxItems: 1 resets: - maxItems: 2 + minItems: 2 + maxItems: 3 reset-names: - minItems: 1 - maxItems: 2 + minItems: 2 + maxItems: 3 items: - enum: [ qspi, qspi-ocp ] + enum: [ qspi, qspi-ocp, rstc_ref ] required: - compatible diff --git a/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml b/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml index 1051690e3753..74a817cc7d94 100644 --- a/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml +++ b/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml @@ -22,7 +22,7 @@ properties: - items: - const: microchip,mpfs-qspi - const: microchip,coreqspi-rtl-v2 - - const: microchip,coreqspi-rtl-v2 #FPGA QSPI + - const: microchip,coreqspi-rtl-v2 # FPGA QSPI - const: microchip,mpfs-spi reg: diff --git a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml index 491a695a2deb..00acbbb0f65d 100644 --- a/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml @@ -149,23 +149,38 @@ required: - compatible - reg - interrupts + - clocks + - power-domains - '#address-cells' - '#size-cells' +if: + not: + properties: + compatible: + contains: + const: renesas,sh-mobile-msiof +then: + required: + - resets + unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/r8a7791-clock.h> - #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/r8a7791-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7791-sysc.h> msiof0: spi@e6e20000 { compatible = "renesas,msiof-r8a7791", "renesas,rcar-gen2-msiof"; reg = <0xe6e20000 0x0064>; - interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp0_clks R8A7791_CLK_MSIOF0>; + interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 000>; dmas = <&dmac0 0x51>, <&dmac0 0x52>; dma-names = "tx", "rx"; + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; + resets = <&cpg 0>; #address-cells = <1>; #size-cells = <0>; }; diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml index a132b5fc56e0..12ca108864c6 100644 --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml @@ -37,6 +37,17 @@ allOf: else: required: - interrupts + - if: + properties: + compatible: + contains: + const: amd,pensando-elba-spi + then: + required: + - amd,pensando-elba-syscon + else: + properties: + amd,pensando-elba-syscon: false properties: compatible: @@ -63,6 +74,8 @@ properties: const: intel,keembay-ssi - description: Intel Thunder Bay SPI Controller const: intel,thunderbay-ssi + - description: AMD Pensando Elba SoC SPI Controller + const: amd,pensando-elba-spi - description: Baikal-T1 SPI Controller const: baikal,bt1-ssi - description: Baikal-T1 System Boot SPI Controller @@ -136,6 +149,12 @@ properties: of the designware controller, and the upper limit is also subject to controller configuration. + amd,pensando-elba-syscon: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Block address to control SPI chip-selects. The Elba SoC system controller + provides an interface to override the native DWC SSI CS control. + patternProperties: "^.*@[0-9a-f]+$": type: object diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 5a7c72cadf76..90945f59b7e8 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -94,6 +94,7 @@ patternProperties: "^.*@[0-9a-f]+$": type: object $ref: spi-peripheral-props.yaml + additionalProperties: true properties: spi-3wire: diff --git a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml index 98a7dc7f467d..a1c96985951f 100644 --- a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml +++ b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml @@ -57,17 +57,17 @@ properties: patternProperties: "^sram@[a-z0-9]+": - type: object - - properties: - compatible: - const: mmio-sram + $ref: /schemas/sram/sram.yaml# + unevaluatedProperties: false patternProperties: "^sram-section?@[a-f0-9]+$": type: object + additionalProperties: false properties: + reg: true + compatible: oneOf: - const: allwinner,sun4i-a10-sram-a3-a4 diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml index ba694ce4a037..0548e8e0d30b 100644 --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml @@ -26,6 +26,7 @@ properties: - qcom,sdm845-imem - qcom,sdx55-imem - qcom,sdx65-imem + - qcom,sm6375-imem - qcom,sm8450-imem - const: syscon - const: simple-mfd diff --git a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml index 071f2d676196..4bbf6db0b6bd 100644 --- a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml +++ b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml @@ -61,6 +61,7 @@ additionalProperties: false patternProperties: "-sram@[0-9a-f]+$": type: object + additionalProperties: false description: A region of reserved memory. properties: diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml index 999c6b365f1d..20f8f9b3b971 100644 --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml @@ -30,7 +30,7 @@ properties: amlogic,ao-secure: description: phandle to the ao-secure syscon - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle '#thermal-sensor-cells': const: 0 diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml index b22c8b59d5c7..fe599e443eaf 100644 --- a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml @@ -40,11 +40,11 @@ properties: - const: temp_grade fsl,tempmon: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: Phandle to anatop system controller node. fsl,tempmon-data: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | Deprecated property, phandle pointer to fuse controller that contains TEMPMON calibration data, e.g. OCOTP on imx6q. The details about diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt index 38b32bb447e3..ac39c7156fde 100644 --- a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt @@ -16,6 +16,7 @@ Required properties: - "mediatek,mt7981-thermal", "mediatek,mt7986-thermal" : For MT7981 SoC - "mediatek,mt7986-thermal" : For MT7986 SoC - "mediatek,mt8183-thermal" : For MT8183 family of SoCs + - "mediatek,mt8365-thermal" : For MT8365 family of SoCs - "mediatek,mt8516-thermal", "mediatek,mt2701-thermal : For MT8516 family of SoCs - reg: Address range of the thermal controller - interrupts: IRQ for the thermal controller diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml index f09e8723ca2b..145744027234 100644 --- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml @@ -29,14 +29,14 @@ properties: maxItems: 1 fsl,tmu-range: - $ref: '/schemas/types.yaml#/definitions/uint32-array' + $ref: /schemas/types.yaml#/definitions/uint32-array description: | The values to be programmed into TTRnCR, as specified by the SoC reference manual. The first cell is TTR0CR, the second is TTR1CR, etc. maxItems: 4 fsl,tmu-calibration: - $ref: '/schemas/types.yaml#/definitions/uint32-matrix' + $ref: /schemas/types.yaml#/definitions/uint32-matrix description: | A list of cell pairs containing temperature calibration data, as specified by the SoC reference manual. The first cell of each pair diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml index f6c1be226aaa..55f8ec0bec01 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml @@ -19,6 +19,7 @@ properties: - rockchip,rk3368-tsadc - rockchip,rk3399-tsadc - rockchip,rk3568-tsadc + - rockchip,rk3588-tsadc - rockchip,rv1108-tsadc reg: diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml index 8581821fa4e1..4f3acdc4dec0 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml @@ -171,6 +171,7 @@ patternProperties: cooling-maps: type: object + additionalProperties: false description: This node describes the action to be taken when a thermal zone crosses one of the temperature thresholds described in the trips diff --git a/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.txt b/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.txt deleted file mode 100644 index a9da22bda912..000000000000 --- a/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.txt +++ /dev/null @@ -1,22 +0,0 @@ -Amlogic Meson6 SoCs Timer Controller - -Required properties: - -- compatible : should be "amlogic,meson6-timer" -- reg : Specifies base physical address and size of the registers. -- interrupts : The four interrupts, one for each timer event -- clocks : phandles to the pclk (system clock) and XTAL clocks -- clock-names : must contain "pclk" and "xtal" - -Example: - -timer@c1109940 { - compatible = "amlogic,meson6-timer"; - reg = <0xc1109940 0x14>; - interrupts = <GIC_SPI 10 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 11 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 29 IRQ_TYPE_EDGE_RISING>; - clocks = <&xtal>, <&clk81>; - clock-names = "xtal", "pclk"; -}; diff --git a/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.yaml b/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.yaml new file mode 100644 index 000000000000..8381a5404ef7 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/amlogic,meson6-timer.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/amlogic,meson6-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson6 SoCs Timer Controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + - Martin Blumenstingl <martin.blumenstingl@googlemail.com> + +properties: + compatible: + const: amlogic,meson6-timer + + reg: + maxItems: 1 + + interrupts: + maxItems: 4 + description: per-timer event interrupts + + clocks: + maxItems: 2 + + clock-names: + items: + - const: xtal + - const: pclk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + timer@c1109940 { + compatible = "amlogic,meson6-timer"; + reg = <0xc1109940 0x14>; + interrupts = <GIC_SPI 10 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 11 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 29 IRQ_TYPE_EDGE_RISING>; + clocks = <&xtal>, <&clk81>; + clock-names = "xtal", "pclk"; + }; diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml index f6efa48c4256..7a4a6ab85970 100644 --- a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml @@ -66,7 +66,7 @@ patternProperties: description: A timer node has up to 8 frame sub-nodes, each with the following properties. properties: frame-number: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 7 diff --git a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml index 7d821fd480f6..bc5e6f226295 100644 --- a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml +++ b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml @@ -28,7 +28,7 @@ properties: maxItems: 1 timer-width: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: | Bit width of the timer, necessary if not 16. diff --git a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml index f32575d4b5aa..526b8db4d575 100644 --- a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml +++ b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml @@ -2,8 +2,8 @@ # Copyright 2018 Linaro Ltd. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/timer/intel,ixp4xx-timer.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/timer/intel,ixp4xx-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel IXP4xx XScale Networking Processors Timers diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml b/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml index b78209cd0f28..9ea2ea3a7599 100644 --- a/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml +++ b/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only %YAML 1.2 --- -$id: "http://devicetree.org/schemas/timer/nvidia,tegra-timer.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/timer/nvidia,tegra-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra timer diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml b/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml index db8b5595540f..76516e18e042 100644 --- a/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml +++ b/Documentation/devicetree/bindings/timer/nvidia,tegra186-timer.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/timer/nvidia,tegra186-timer.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/timer/nvidia,tegra186-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra186 timer diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml index 65e59836a660..19e56b7577a0 100644 --- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml +++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml @@ -23,8 +23,8 @@ properties: - rockchip,rk3188-timer - rockchip,rk3228-timer - rockchip,rk3229-timer - - rockchip,rk3288-timer - rockchip,rk3368-timer + - rockchip,rk3588-timer - rockchip,px30-timer - const: rockchip,rk3288-timer reg: diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index aada6957216c..94bef9424df1 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -31,6 +31,7 @@ properties: - enum: - sifive,fu540-c000-clint - starfive,jh7100-clint + - starfive,jh7110-clint - canaan,k210-clint - const: sifive,clint0 - items: diff --git a/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml b/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml index 901848d298ec..fa65878b3571 100644 --- a/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml +++ b/Documentation/devicetree/bindings/timer/st,nomadik-mtu.yaml @@ -2,8 +2,8 @@ # Copyright 2022 Linaro Ltd. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/timer/st,nomadik-mtu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/timer/st,nomadik-mtu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: ST Microelectronics Nomadik Multi-Timer Unit MTU Timer diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 6f482a254a1d..246863a9bc7e 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -29,6 +29,8 @@ properties: compatible: items: - enum: + # Acbel fsg032 power supply + - acbel,fsg032 # SMBus/I2C Digital Temperature Sensor in 6-Pin SOT with SMBus Alert and Over Temperature Pin - ad,ad7414 # ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems diff --git a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml index f38a2be07eda..da757c1155d4 100644 --- a/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml +++ b/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/amlogic,meson-g12a-usb-ctrl.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/amlogic,meson-g12a-usb-ctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson G12A DWC3 USB SoC Controller Glue diff --git a/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml b/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml index ad075407d85e..1536cbec6334 100644 --- a/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/brcm,bcm7445-ehci.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Broadcom STB USB EHCI Controller allOf: - - $ref: "usb-hcd.yaml" + - $ref: usb-hcd.yaml maintainers: - Al Cooper <alcooperx@gmail.com> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt deleted file mode 100644 index 72ceea575d58..000000000000 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt +++ /dev/null @@ -1,159 +0,0 @@ -* USB2 ChipIdea USB controller for ci13xxx - -Required properties: -- compatible: should be one of: - "fsl,imx23-usb" - "fsl,imx27-usb" - "fsl,imx28-usb" - "fsl,imx6q-usb" - "fsl,imx6sl-usb" - "fsl,imx6sx-usb" - "fsl,imx6ul-usb" - "fsl,imx7d-usb" - "fsl,imx7ulp-usb" - "fsl,imx8mm-usb" - "lsi,zevio-usb" - "qcom,ci-hdrc" - "chipidea,usb2" - "xlnx,zynq-usb-2.20a" - "nvidia,tegra20-udc" - "nvidia,tegra30-udc" - "nvidia,tegra114-udc" - "nvidia,tegra124-udc" -- reg: base address and length of the registers -- interrupts: interrupt for the USB controller - -Recommended properies: -- phy_type: the type of the phy connected to the core. Should be one - of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this - property the PORTSC register won't be touched. -- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg" - -Deprecated properties: -- usb-phy: phandle for the PHY device. Use "phys" instead. -- fsl,usbphy: phandle of usb phy that connects to the port. Use "phys" instead. - -Optional properties: -- clocks: reference to the USB clock -- phys: reference to the USB PHY -- phy-names: should be "usb-phy" -- vbus-supply: reference to the VBUS regulator -- maximum-speed: limit the maximum connection speed to "full-speed". -- tpl-support: TPL (Targeted Peripheral List) feature for targeted hosts -- itc-setting: interrupt threshold control register control, the setting - should be aligned with ITC bits at register USBCMD. -- ahb-burst-config: it is vendor dependent, the required value should be - aligned with AHBBRST at SBUSCFG, the range is from 0x0 to 0x7. This - property is used to change AHB burst configuration, check the chipidea - spec for meaning of each value. If this property is not existed, it - will use the reset value. -- tx-burst-size-dword: it is vendor dependent, the tx burst size in dword - (4 bytes), This register represents the maximum length of a the burst - in 32-bit words while moving data from system memory to the USB - bus, the value of this property will only take effect if property - "ahb-burst-config" is set to 0, if this property is missing the reset - default of the hardware implementation will be used. -- rx-burst-size-dword: it is vendor dependent, the rx burst size in dword - (4 bytes), This register represents the maximum length of a the burst - in 32-bit words while moving data from the USB bus to system memory, - the value of this property will only take effect if property - "ahb-burst-config" is set to 0, if this property is missing the reset - default of the hardware implementation will be used. -- extcon: phandles to external connector devices. First phandle should point to - external connector, which provide "USB" cable events, the second should point - to external connector device, which provide "USB-HOST" cable events. If one - of the external connector devices is not required, empty <0> phandle should - be specified. -- phy-clkgate-delay-us: the delay time (us) between putting the PHY into - low power mode and gating the PHY clock. -- non-zero-ttctrl-ttha: after setting this property, the value of register - ttctrl.ttha will be 0x7f; if not, the value will be 0x0, this is the default - value. It needs to be very carefully for setting this property, it is - recommended that consult with your IC engineer before setting this value. - On the most of chipidea platforms, the "usage_tt" flag at RTL is 0, so this - property only affects siTD. - If this property is not set, the max packet size is 1023 bytes, and if - the total of packet size for pervious transactions are more than 256 bytes, - it can't accept any transactions within this frame. The use case is single - transaction, but higher frame rate. - If this property is set, the max packet size is 188 bytes, it can handle - more transactions than above case, it can accept transactions until it - considers the left room size within frame is less than 188 bytes, software - needs to make sure it does not send more than 90% - maximum_periodic_data_per_frame. The use case is multiple transactions, but - less frame rate. -- mux-controls: The mux control for toggling host/device output of this - controller. It's expected that a mux state of 0 indicates device mode and a - mux state of 1 indicates host mode. -- mux-control-names: Shall be "usb_switch" if mux-controls is specified. -- pinctrl-names: Names for optional pin modes in "default", "host", "device". - In case of HSIC-mode, "idle" and "active" pin modes are mandatory. In this - case, the "idle" state needs to pull down the data and strobe pin - and the "active" state needs to pull up the strobe pin. -- pinctrl-n: alternate pin modes - -i.mx specific properties -- fsl,usbmisc: phandler of non-core register device, with one - argument that indicate usb controller index -- disable-over-current: disable over current detect -- over-current-active-low: over current signal polarity is active low. -- over-current-active-high: over current signal polarity is active high. - It's recommended to specify the over current polarity. -- power-active-high: power signal polarity is active high -- external-vbus-divider: enables off-chip resistor divider for Vbus -- samsung,picophy-pre-emp-curr-control: HS Transmitter Pre-Emphasis Current - Control. This signal controls the amount of current sourced to the - USB_OTG*_DP and USB_OTG*_DN pins after a J-to-K or K-to-J transition. - The range is from 0x0 to 0x3, the default value is 0x1. - Details can refer to TXPREEMPAMPTUNE0 bits of USBNC_n_PHY_CFG1. -- samsung,picophy-dc-vol-level-adjust: HS DC Voltage Level Adjustment. - Adjust the high-speed transmitter DC level voltage. - The range is from 0x0 to 0xf, the default value is 0x3. - Details can refer to TXVREFTUNE0 bits of USBNC_n_PHY_CFG1. - -Example: - - usb@f7ed0000 { - compatible = "chipidea,usb2"; - reg = <0xf7ed0000 0x10000>; - interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&chip CLKID_USB0>; - phys = <&usb_phy0>; - phy-names = "usb-phy"; - vbus-supply = <®_usb0_vbus>; - itc-setting = <0x4>; /* 4 micro-frames */ - /* Incremental burst of unspecified length */ - ahb-burst-config = <0x0>; - tx-burst-size-dword = <0x10>; /* 64 bytes */ - rx-burst-size-dword = <0x10>; - extcon = <0>, <&usb_id>; - phy-clkgate-delay-us = <400>; - mux-controls = <&usb_switch>; - mux-control-names = "usb_switch"; - }; - -Example for HSIC: - - usb@2184400 { - compatible = "fsl,imx6q-usb", "fsl,imx27-usb"; - reg = <0x02184400 0x200>; - interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks IMX6QDL_CLK_USBOH3>; - fsl,usbphy = <&usbphynop1>; - fsl,usbmisc = <&usbmisc 2>; - phy_type = "hsic"; - dr_mode = "host"; - ahb-burst-config = <0x0>; - tx-burst-size-dword = <0x10>; - rx-burst-size-dword = <0x10>; - pinctrl-names = "idle", "active"; - pinctrl-0 = <&pinctrl_usbh2_idle>; - pinctrl-1 = <&pinctrl_usbh2_active>; - #address-cells = <1>; - #size-cells = <0>; - - usbnet: ethernet@1 { - compatible = "usb424,9730"; - reg = <1>; - }; - }; diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml new file mode 100644 index 000000000000..b26d26c2b023 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml @@ -0,0 +1,448 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/ci-hdrc-usb2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: USB2 ChipIdea USB controller + +maintainers: + - Xu Yang <xu.yang_2@nxp.com> + - Peng Fan <peng.fan@nxp.com> + +properties: + compatible: + oneOf: + - enum: + - chipidea,usb2 + - lsi,zevio-usb + - nvidia,tegra20-ehci + - nvidia,tegra20-udc + - nvidia,tegra30-ehci + - nvidia,tegra30-udc + - nvidia,tegra114-udc + - nvidia,tegra124-udc + - qcom,ci-hdrc + - items: + - enum: + - nvidia,tegra114-ehci + - nvidia,tegra124-ehci + - nvidia,tegra210-ehci + - const: nvidia,tegra30-ehci + - items: + - enum: + - fsl,imx23-usb + - fsl,imx25-usb + - fsl,imx28-usb + - fsl,imx50-usb + - fsl,imx51-usb + - fsl,imx53-usb + - fsl,imx6q-usb + - fsl,imx6sl-usb + - fsl,imx6sx-usb + - fsl,imx6ul-usb + - fsl,imx7d-usb + - fsl,vf610-usb + - const: fsl,imx27-usb + - items: + - const: fsl,imx8dxl-usb + - const: fsl,imx7ulp-usb + - const: fsl,imx6ul-usb + - items: + - enum: + - fsl,imx8mm-usb + - fsl,imx8mn-usb + - const: fsl,imx7d-usb + - const: fsl,imx27-usb + - items: + - enum: + - fsl,imx6sll-usb + - fsl,imx7ulp-usb + - const: fsl,imx6ul-usb + - const: fsl,imx27-usb + - items: + - const: xlnx,zynq-usb-2.20a + - const: chipidea,usb2 + + reg: + minItems: 1 + maxItems: 2 + + interrupts: + minItems: 1 + maxItems: 2 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + + dr_mode: true + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + maxItems: 1 + + "#reset-cells": + const: 1 + + phy_type: true + + itc-setting: + description: + interrupt threshold control register control, the setting should be + aligned with ITC bits at register USBCMD. + $ref: /schemas/types.yaml#/definitions/uint32 + + ahb-burst-config: + description: + it is vendor dependent, the required value should be aligned with + AHBBRST at SBUSCFG, the range is from 0x0 to 0x7. This property is + used to change AHB burst configuration, check the chipidea spec for + meaning of each value. If this property is not existed, it will use + the reset value. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x7 + + tx-burst-size-dword: + description: + it is vendor dependent, the tx burst size in dword (4 bytes), This + register represents the maximum length of a the burst in 32-bit + words while moving data from system memory to the USB bus, the value + of this property will only take effect if property "ahb-burst-config" + is set to 0, if this property is missing the reset default of the + hardware implementation will be used. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x20 + + rx-burst-size-dword: + description: + it is vendor dependent, the rx burst size in dword (4 bytes), This + register represents the maximum length of a the burst in 32-bit words + while moving data from the USB bus to system memory, the value of + this property will only take effect if property "ahb-burst-config" + is set to 0, if this property is missing the reset default of the + hardware implementation will be used. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x20 + + extcon: + description: + Phandles to external connector devices. First phandle should point + to external connector, which provide "USB" cable events, the second + should point to external connector device, which provide "USB-HOST" + cable events. If one of the external connector devices is not + required, empty <0> phandle should be specified. + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + items: + - description: vbus extcon + - description: id extcon + + phy-clkgate-delay-us: + description: + The delay time (us) between putting the PHY into low power mode and + gating the PHY clock. + + non-zero-ttctrl-ttha: + description: + After setting this property, the value of register ttctrl.ttha + will be 0x7f; if not, the value will be 0x0, this is the default + value. It needs to be very carefully for setting this property, it + is recommended that consult with your IC engineer before setting + this value. On the most of chipidea platforms, the "usage_tt" flag + at RTL is 0, so this property only affects siTD. + + If this property is not set, the max packet size is 1023 bytes, and + if the total of packet size for pervious transactions are more than + 256 bytes, it can't accept any transactions within this frame. The + use case is single transaction, but higher frame rate. + + If this property is set, the max packet size is 188 bytes, it can + handle more transactions than above case, it can accept transactions + until it considers the left room size within frame is less than 188 + bytes, software needs to make sure it does not send more than 90% + maximum_periodic_data_per_frame. The use case is multiple + transactions, but less frame rate. + type: boolean + + mux-controls: + description: + The mux control for toggling host/device output of this controller. + It's expected that a mux state of 0 indicates device mode and a mux + state of 1 indicates host mode. + maxItems: 1 + + mux-control-names: + const: usb_switch + + operating-points-v2: + description: A phandle to the OPP table containing the performance states. + $ref: /schemas/types.yaml#/definitions/phandle + + pinctrl-names: + description: + Names for optional pin modes in "default", "host", "device". + In case of HSIC-mode, "idle" and "active" pin modes are mandatory. + In this case, the "idle" state needs to pull down the data and + strobe pin and the "active" state needs to pull up the strobe pin. + oneOf: + - items: + - const: idle + - const: active + - items: + - const: default + - enum: + - host + - device + - items: + - const: default + + pinctrl-0: + maxItems: 1 + + pinctrl-1: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + const: usb-phy + + phy-select: + description: + Phandler of TCSR node with two argument that indicate register + offset, and phy index + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - description: phandle to TCSR node + - description: register offset + - description: phy index + + vbus-supply: + description: reference to the VBUS regulator. + + fsl,usbmisc: + description: + Phandler of non-core register device, with one argument that + indicate usb controller index + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to usbmisc node + - description: index of usb controller + + fsl,anatop: + description: phandle for the anatop node. + $ref: /schemas/types.yaml#/definitions/phandle + + disable-over-current: + type: boolean + description: disable over current detect + + over-current-active-low: + type: boolean + description: over current signal polarity is active low + + over-current-active-high: + type: boolean + description: + Over current signal polarity is active high. It's recommended to + specify the over current polarity. + + power-active-high: + type: boolean + description: power signal polarity is active high + + external-vbus-divider: + type: boolean + description: enables off-chip resistor divider for Vbus + + samsung,picophy-pre-emp-curr-control: + description: + HS Transmitter Pre-Emphasis Current Control. This signal controls + the amount of current sourced to the USB_OTG*_DP and USB_OTG*_DN + pins after a J-to-K or K-to-J transition. The range is from 0x0 to + 0x3, the default value is 0x1. Details can refer to TXPREEMPAMPTUNE0 + bits of USBNC_n_PHY_CFG1. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x3 + + samsung,picophy-dc-vol-level-adjust: + description: + HS DC Voltage Level Adjustment. Adjust the high-speed transmitter DC + level voltage. The range is from 0x0 to 0xf, the default value is + 0x3. Details can refer to TXVREFTUNE0 bits of USBNC_n_PHY_CFG1. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0xf + + usb-phy: + description: phandle for the PHY device. Use "phys" instead. + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + + fsl,usbphy: + description: phandle of usb phy that connects to the port. Use "phys" instead. + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + + nvidia,phy: + description: phandle of usb phy that connects to the port. Use "phys" instead. + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + + nvidia,needs-double-reset: + description: Indicates double reset or not. + type: boolean + deprecated: true + + port: + description: + Any connector to the data bus of this controller should be modelled + using the OF graph bindings specified, if the "usb-role-switch" + property is used. + $ref: /schemas/graph.yaml#/properties/port + + reset-gpios: + maxItems: 1 + + ulpi: + type: object + additionalProperties: false + patternProperties: + "^phy(-[0-9])?$": + description: The phy child node for Qcom chips. + type: object + $ref: /schemas/phy/qcom,usb-hs-phy.yaml + +dependencies: + port: [ usb-role-switch ] + mux-controls: [ mux-control-names ] + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: usb-hcd.yaml# + - $ref: usb-drd.yaml# + - if: + properties: + phy_type: + const: hsic + required: + - phy_type + then: + properties: + pinctrl-names: + items: + - const: idle + - const: active + else: + properties: + pinctrl-names: + minItems: 1 + maxItems: 2 + oneOf: + - items: + - const: default + - enum: + - host + - device + - items: + - const: default + - if: + properties: + compatible: + contains: + enum: + - chipidea,usb2 + - lsi,zevio-usb + - nvidia,tegra20-udc + - nvidia,tegra30-udc + - nvidia,tegra114-udc + - nvidia,tegra124-udc + - qcom,ci-hdrc + - xlnx,zynq-usb-2.20a + then: + properties: + fsl,usbmisc: false + disable-over-current: false + over-current-active-low: false + over-current-active-high: false + power-active-high: false + external-vbus-divider: false + samsung,picophy-pre-emp-curr-control: false + samsung,picophy-dc-vol-level-adjust: false + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/berlin2.h> + + usb@f7ed0000 { + compatible = "chipidea,usb2"; + reg = <0xf7ed0000 0x10000>; + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&chip CLKID_USB0>; + phys = <&usb_phy0>; + phy-names = "usb-phy"; + vbus-supply = <®_usb0_vbus>; + itc-setting = <0x4>; /* 4 micro-frames */ + /* Incremental burst of unspecified length */ + ahb-burst-config = <0x0>; + tx-burst-size-dword = <0x10>; /* 64 bytes */ + rx-burst-size-dword = <0x10>; + extcon = <0>, <&usb_id>; + phy-clkgate-delay-us = <400>; + mux-controls = <&usb_switch>; + mux-control-names = "usb_switch"; + }; + + # Example for HSIC: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx6qdl-clock.h> + + usb@2184400 { + compatible = "fsl,imx6q-usb", "fsl,imx27-usb"; + reg = <0x02184400 0x200>; + interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks IMX6QDL_CLK_USBOH3>; + fsl,usbphy = <&usbphynop1>; + fsl,usbmisc = <&usbmisc 2>; + phy_type = "hsic"; + dr_mode = "host"; + ahb-burst-config = <0x0>; + tx-burst-size-dword = <0x10>; + rx-burst-size-dword = <0x10>; + pinctrl-names = "idle", "active"; + pinctrl-0 = <&pinctrl_usbh2_idle>; + pinctrl-1 = <&pinctrl_usbh2_active>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet@1 { + compatible = "usb424,9730"; + reg = <1>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 371ba93f3ce5..d3506090f8b1 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -75,11 +75,14 @@ properties: maxItems: 1 clocks: - maxItems: 1 + minItems: 1 + maxItems: 2 clock-names: items: - const: otg + - const: utmi + minItems: 1 disable-over-current: type: boolean diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml index 51120fe90322..f6e7a5c1ff0b 100644 --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/fcs,fsa4480.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/fcs,fsa4480.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: ON Semiconductor Analog Audio Switch diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mq-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mq-dwc3.yaml new file mode 100644 index 000000000000..50569d3ee767 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/fsl,imx8mq-dwc3.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/fsl,imx8mq-dwc3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP iMX8MQ Soc USB Controller + +maintainers: + - Li Jun <jun.li@nxp.com> + - Peng Fan <peng.fan@nxp.com> + +select: + properties: + compatible: + contains: + enum: + - fsl,imx8mq-dwc3 + required: + - compatible + +properties: + compatible: + items: + - const: fsl,imx8mq-dwc3 + - const: snps,dwc3 + +allOf: + - $ref: snps,dwc3.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mq-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + usb_dwc3_1: usb@38200000 { + compatible = "fsl,imx8mq-dwc3", "snps,dwc3"; + reg = <0x38200000 0x10000>; + clocks = <&clk IMX8MQ_CLK_USB2_CTRL_ROOT>, + <&clk IMX8MQ_CLK_USB_CORE_REF>, + <&clk IMX8MQ_CLK_32K>; + clock-names = "bus_early", "ref", "suspend"; + interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>; + phys = <&usb3_phy1>, <&usb3_phy1>; + phy-names = "usb2-phy", "usb3-phy"; + }; diff --git a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml new file mode 100644 index 000000000000..2d3589d284b2 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/fsl,usbmisc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX wrapper module for Chipidea USB2 controller + +maintainers: + - Xu Yang <xu.yang_2@nxp.com> + - Peng Fan <peng.fan@nxp.com> + +properties: + compatible: + oneOf: + - enum: + - fsl,imx25-usbmisc + - fsl,imx27-usbmisc + - fsl,imx35-usbmisc + - fsl,imx51-usbmisc + - fsl,imx53-usbmisc + - fsl,imx6q-usbmisc + - fsl,vf610-usbmisc + - items: + - enum: + - fsl,imx6ul-usbmisc + - fsl,imx6sl-usbmisc + - fsl,imx6sx-usbmisc + - fsl,imx7d-usbmisc + - const: fsl,imx6q-usbmisc + - items: + - enum: + - fsl,imx7ulp-usbmisc + - fsl,imx8mm-usbmisc + - fsl,imx8mn-usbmisc + - const: fsl,imx7d-usbmisc + - const: fsl,imx6q-usbmisc + - items: + - const: fsl,imx6sll-usbmisc + - const: fsl,imx6ul-usbmisc + - const: fsl,imx6q-usbmisc + + clocks: + maxItems: 1 + + reg: + maxItems: 1 + + '#index-cells': + const: 1 + description: Cells used to describe usb controller index. + deprecated: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + usbmisc@2184800 { + compatible = "fsl,imx6q-usbmisc"; + reg = <0x02184800 0x200>; + #index-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index 050cfd5acdaa..9445764bd8de 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -10,7 +10,7 @@ maintainers: - Greg Kroah-Hartman <gregkh@linuxfoundation.org> allOf: - - $ref: "usb-hcd.yaml" + - $ref: usb-hcd.yaml - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml index a9ba7257b884..d06d1e7d8876 100644 --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml @@ -148,7 +148,7 @@ allOf: properties: transceiver: false -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml index db841589fc33..594ebb3ee432 100644 --- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml @@ -10,7 +10,7 @@ maintainers: - Mathias Nyman <mathias.nyman@intel.com> allOf: - - $ref: "usb-xhci.yaml#" + - $ref: usb-xhci.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml index bf4b1d016e1f..f196beb826d8 100644 --- a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml +++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/gpio-sbu-mux.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/gpio-sbu-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: GPIO-based SBU mux diff --git a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml index 8e513a6af378..276bf7554215 100644 --- a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml +++ b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/maxim,max33359.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/maxim,max33359.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim TCPCI Type-C PD controller @@ -40,7 +40,7 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/usb/pd.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml index 1d893d3d3432..8e0f4ecc010d 100644 --- a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml +++ b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml @@ -52,7 +52,7 @@ examples: - | #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml index c72257c19220..053264e60583 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller @@ -43,7 +43,7 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/usb/pd.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6370-tcpc.yaml b/Documentation/devicetree/bindings/usb/mediatek,mt6370-tcpc.yaml index 72f56cc88457..747d0f16d9b6 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mt6370-tcpc.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6370-tcpc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/mediatek,mt6370-tcpc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/mediatek,mt6370-tcpc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: MediatTek MT6370 Type-C Port Switch and Power Delivery controller diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index c119caa9ad16..e9644e333d78 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -11,7 +11,7 @@ maintainers: - Chunfeng Yun <chunfeng.yun@mediatek.com> allOf: - - $ref: "usb-xhci.yaml" + - $ref: usb-xhci.yaml description: | There are two scenarios: @@ -77,6 +77,7 @@ properties: - description: Mcu bus clock for register access - description: DMA bus clock for data transfer - description: controller clock + - description: frame count clock clock-names: minItems: 1 @@ -86,14 +87,7 @@ properties: - const: mcu_ck - const: dma_ck - const: xhci_ck - - assigned-clocks: - minItems: 1 - maxItems: 5 - - assigned-clock-parents: - minItems: 1 - maxItems: 5 + - const: frmcnt_ck phys: description: diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index d2655173e108..478214ab045e 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -11,7 +11,7 @@ maintainers: - Chunfeng Yun <chunfeng.yun@mediatek.com> allOf: - - $ref: "usb-drd.yaml" + - $ref: usb-drd.yaml description: | The DRD controller has a glue layer IPPC (IP Port Control), and its host is @@ -66,6 +66,8 @@ properties: - description: Reference clock used by low power mode etc - description: Mcu bus clock for register access - description: DMA bus clock for data transfer + - description: DRD controller clock + - description: Frame count clock clock-names: minItems: 1 @@ -74,6 +76,8 @@ properties: - const: ref_ck - const: mcu_ck - const: dma_ck + - const: xhci_ck + - const: frmcnt_ck phys: description: @@ -204,9 +208,9 @@ patternProperties: example if the host mode is enabled. dependencies: - connector: [ 'usb-role-switch' ] - port: [ 'usb-role-switch' ] - role-switch-default-mode: [ 'usb-role-switch' ] + connector: [ usb-role-switch ] + port: [ usb-role-switch ] + role-switch-default-mode: [ usb-role-switch ] wakeup-source: [ 'mediatek,syscon-wakeup' ] required: diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml index f16ab30a95d2..a39d38db7714 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml @@ -68,8 +68,8 @@ properties: type: object dependencies: - usb-role-switch: [ 'connector' ] - connector: [ 'usb-role-switch' ] + usb-role-switch: [ connector ] + connector: [ usb-role-switch ] required: - compatible diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml index e638f77658fc..e2270ce0c56b 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/nvidia,tegra-xudc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/nvidia,tegra-xudc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra XUSB device mode controller (XUDC) diff --git a/Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml b/Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml new file mode 100644 index 000000000000..28eb25ecba74 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PTN5110 Typec Port Cotroller + +maintainers: + - Li Jun <jun.li@nxp.com> + +properties: + compatible: + const: nxp,ptn5110 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + connector: + type: object + $ref: /schemas/connector/usb-connector.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - connector + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/usb/pd.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + tcpci@50 { + compatible = "nxp,ptn5110"; + reg = <0x50>; + interrupt-parent = <&gpio3>; + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; + + usb_con: connector { + compatible = "usb-c-connector"; + label = "USB-C"; + data-role = "dual"; + power-role = "dual"; + try-power-role = "sink"; + source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>; + sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM) PDO_VAR(5000, 12000, 2000)>; + op-sink-microwatt = <10000000>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + typec1_dr_sw: endpoint { + remote-endpoint = <&usb1_drd_sw>; + }; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index 4875c5b7d5b5..d84281926f10 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -21,6 +21,7 @@ properties: - qcom,msm8994-dwc3 - qcom,msm8996-dwc3 - qcom,msm8998-dwc3 + - qcom,qcm2290-dwc3 - qcom,qcs404-dwc3 - qcom,sc7180-dwc3 - qcom,sc7280-dwc3 @@ -121,6 +122,7 @@ properties: patternProperties: "^usb@[0-9a-f]+$": $ref: snps,dwc3.yaml# + unevaluatedProperties: false properties: wakeup-source: false @@ -300,6 +302,7 @@ allOf: compatible: contains: enum: + - qcom,qcm2290-dwc3 - qcom,sm6115-dwc3 - qcom,sm6125-dwc3 - qcom,sm8150-dwc3 diff --git a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml index 623d04a88a81..9309f003cd07 100644 --- a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml +++ b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml @@ -26,7 +26,7 @@ properties: phandle to the regulator that provides power to the hub. peer-hub: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: phandle to the peer hub on the controller. diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml index 1999f614c89b..8da4d2ad1a91 100644 --- a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml +++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/richtek,rt1711h.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/richtek,rt1711h.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Richtek RT1711H Type-C Port Switch and Power Delivery controller @@ -51,7 +51,7 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/usb/pd.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml index e3e87e4d3292..4ced2f68e2a9 100644 --- a/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml +++ b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/richtek,rt1719.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/richtek,rt1719.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Richtek RT1719 sink-only Type-C PD controller @@ -48,7 +48,7 @@ required: examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml b/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml index a09f4528aea3..6156dc26e65c 100644 --- a/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml +++ b/Documentation/devicetree/bindings/usb/smsc,usb3503.yaml @@ -14,6 +14,7 @@ properties: enum: - smsc,usb3503 - smsc,usb3503a + - smsc,usb3803 reg: maxItems: 1 @@ -33,6 +34,12 @@ properties: description: > GPIO for reset + bypass-gpios: + maxItems: 1 + description: > + GPIO for bypass. + Control signal to select between HUB MODE and BYPASS MODE. + disabled-ports: $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 @@ -46,9 +53,10 @@ properties: initial-mode: $ref: /schemas/types.yaml#/definitions/uint32 - enum: [1, 2] description: > - Specifies initial mode. 1 for Hub mode, 2 for standby mode. + Specifies initial mode. 1 for Hub mode, 2 for standby mode and 3 for bypass mode. + In bypass mode the downstream port 3 is connected to the upstream port with low + switch resistance R_on. clocks: maxItems: 1 @@ -71,6 +79,29 @@ properties: required: - compatible +allOf: + - if: + not: + properties: + compatible: + enum: + - smsc,usb3803 + then: + properties: + bypass-gpios: false + + - if: + required: + - bypass-gpios + then: + properties: + initial-mode: + enum: [1, 2, 3] + else: + properties: + initial-mode: + enum: [1, 2] + additionalProperties: false examples: @@ -93,6 +124,25 @@ examples: }; - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + usb-hub@8 { + compatible = "smsc,usb3803"; + reg = <0x08>; + connect-gpios = <&gpx3 0 1>; + disabled-ports = <2 3>; + intn-gpios = <&gpx3 4 1>; + reset-gpios = <&gpx3 5 1>; + bypass-gpios = <&gpx3 6 1>; + initial-mode = <3>; + clocks = <&clks 80>; + clock-names = "refclk"; + }; + }; + + - | #include <dt-bindings/gpio/gpio.h> usb-hub { diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index be36956af53b..50edc4da780e 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -70,6 +70,10 @@ properties: dma-coherent: true + extcon: + maxItems: 1 + deprecated: true + iommus: maxItems: 1 @@ -232,6 +236,11 @@ properties: When set, all SuperSpeed bus instances in park mode are disabled. type: boolean + snps,parkmode-disable-hs-quirk: + description: + When set, all HighSpeed bus instances in park mode are disabled. + type: boolean + snps,dis_metastability_quirk: description: When set, disable metastability workaround. CAUTION! Use only if you are @@ -256,6 +265,14 @@ properties: of resume. This option is to support certain legacy ULPI PHYs. type: boolean + snps,ulpi-ext-vbus-drv: + description: + Some ULPI USB PHY does not support internal VBUS supply, and driving + the CPEN pin, requires the configuration of the ulpi DRVVBUSEXTERNAL + bit. When set, the xhci host will configure the USB2 PHY drives VBUS + with an external supply. + type: boolean + snps,is-utmi-l1-suspend: description: True when DWC3 asserts output signal utmi_l1_suspend_n, false when @@ -365,6 +382,22 @@ properties: This port is used with the 'usb-role-switch' property to connect the dwc3 to type C connector. + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + Those ports should be used with any connector to the data bus of this + controller using the OF graph bindings specified if the "usb-role-switch" + property is used. + + 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. + wakeup-source: $ref: /schemas/types.yaml#/definitions/flag description: diff --git a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml index ffcd9897ea38..acda2f47fbc9 100644 --- a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml +++ b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/st,stusb160x.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/st,stusb160x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STUSB160x Type-C controller @@ -56,7 +56,7 @@ additionalProperties: false examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c4 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml index a1cffb70c621..54c6586cb56d 100644 --- a/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml +++ b/Documentation/devicetree/bindings/usb/ti,hd3ss3220.yaml @@ -51,7 +51,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index f81ba3e90297..95ff9791baea 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/ti,j721e-usb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/ti,j721e-usb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI wrapper module for the Cadence USBSS-DRD controller @@ -53,12 +53,6 @@ properties: VBUS pin of the SoC via a 1/3 voltage divider. type: boolean - assigned-clocks: - maxItems: 1 - - assigned-clock-parents: - maxItems: 1 - '#address-cells': const: 2 diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index c1f0194ad0d5..9252d893f694 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -34,14 +34,6 @@ properties: minItems: 1 maxItems: 2 - assigned-clocks: - minItems: 1 - maxItems: 2 - - assigned-clock-parents: - minItems: 1 - maxItems: 2 - power-domains: maxItems: 1 description: Should contain a phandle to a PM domain provider node diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml index 348a715d61f4..5497a60cddbc 100644 --- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml +++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/usb/ti,tps6598x.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/usb/ti,tps6598x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments 6598x Type-C Port Switch and Power Delivery controller @@ -35,15 +35,13 @@ properties: required: - compatible - reg - - interrupts - - interrupt-names additionalProperties: true examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/usb/typec-tcpci.txt b/Documentation/devicetree/bindings/usb/typec-tcpci.txt deleted file mode 100644 index 2082522b1c32..000000000000 --- a/Documentation/devicetree/bindings/usb/typec-tcpci.txt +++ /dev/null @@ -1,49 +0,0 @@ -TCPCI(Typec port cotroller interface) binding ---------------------------------------------- - -Required properties: -- compatible: should be set one of following: - - "nxp,ptn5110" for NXP USB PD TCPC PHY IC ptn5110. - -- reg: the i2c slave address of typec port controller device. -- interrupt-parent: the phandle to the interrupt controller which provides - the interrupt. -- interrupts: interrupt specification for tcpci alert. - -Required sub-node: -- connector: The "usb-c-connector" attached to the tcpci chip, the bindings - of connector node are specified in - Documentation/devicetree/bindings/connector/usb-connector.yaml - -Example: - -ptn5110@50 { - compatible = "nxp,ptn5110"; - reg = <0x50>; - interrupt-parent = <&gpio3>; - interrupts = <3 IRQ_TYPE_LEVEL_LOW>; - - usb_con: connector { - compatible = "usb-c-connector"; - label = "USB-C"; - data-role = "dual"; - power-role = "dual"; - try-power-role = "sink"; - source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>; - sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM) - PDO_VAR(5000, 12000, 2000)>; - op-sink-microwatt = <10000000>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@1 { - reg = <1>; - usb_con_ss: endpoint { - remote-endpoint = <&usb3_data_ss>; - }; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/usb/usb-device.yaml b/Documentation/devicetree/bindings/usb/usb-device.yaml index 7a771125ec76..da890ee60ce6 100644 --- a/Documentation/devicetree/bindings/usb/usb-device.yaml +++ b/Documentation/devicetree/bindings/usb/usb-device.yaml @@ -76,7 +76,6 @@ patternProperties: maxItems: 1 required: - - compatible - reg additionalProperties: true diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml index 921b986adc47..6734f4d3aa78 100644 --- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.yaml @@ -27,6 +27,9 @@ properties: vcc-supply: description: phandle to the regulator that provides power to the PHY. + power-domains: + maxItems: 1 + reset-gpios: maxItems: 1 diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.yaml b/Documentation/devicetree/bindings/usb/usb-xhci.yaml index f2139a9f35fb..180a261c3e8f 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/usb-xhci.yaml @@ -10,7 +10,7 @@ maintainers: - Mathias Nyman <mathias.nyman@intel.com> allOf: - - $ref: "usb-hcd.yaml#" + - $ref: usb-hcd.yaml# properties: usb2-lpm-disable: diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt deleted file mode 100644 index 29b8f65ff849..000000000000 --- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt +++ /dev/null @@ -1,19 +0,0 @@ -* Freescale i.MX non-core registers - -Required properties: -- #index-cells: Cells used to describe usb controller index. Should be <1> -- compatible: Should be one of below: - "fsl,imx6q-usbmisc" for imx6q - "fsl,vf610-usbmisc" for Vybrid vf610 - "fsl,imx6sx-usbmisc" for imx6sx - "fsl,imx7d-usbmisc" for imx7d - "fsl,imx7ulp-usbmisc" for imx7ulp - "fsl,imx8mm-usbmisc" for imx8mm -- reg: Should contain registers location and length - -Examples: -usbmisc@2184800 { - #index-cells = <1>; - compatible = "fsl,imx6q-usbmisc"; - reg = <0x02184800 0x200>; -}; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index ed64e06ecca4..82d39ab0231b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -37,6 +37,8 @@ patternProperties: description: Abracon Corporation "^abt,.*": description: ShenZhen Asia Better Technology Ltd. + "^acbel,.*": + description: Acbel Polytech Inc. "^acer,.*": description: Acer Inc. "^acme,.*": @@ -240,6 +242,8 @@ patternProperties: description: CellWise Microelectronics Co., Ltd "^ceva,.*": description: Ceva, Inc. + "^chargebyte,.*": + description: chargebyte GmbH "^checkpoint,.*": description: Check Point Software Technologies Ltd. "^chefree,.*": @@ -516,6 +520,8 @@ patternProperties: description: GlobalTop Technology, Inc. "^gmt,.*": description: Global Mixed-mode Technology, Inc. + "^goldelico,.*": + description: Golden Delicious Computers GmbH & Co. KG "^goodix,.*": description: Shenzhen Huiding Technology Co., Ltd. "^google,.*": @@ -721,6 +727,8 @@ patternProperties: description: Lantiq Semiconductor "^lattice,.*": description: Lattice Semiconductor + "^lctech,.*": + description: Shenzen LC Technology Co., Ltd. "^leadtek,.*": description: Shenzhen Leadtek Technology Co., Ltd. "^leez,.*": @@ -769,6 +777,8 @@ patternProperties: description: Lontium Semiconductor Corporation "^loongson,.*": description: Loongson Technology Corporation Limited + "^loongmasses,.*": + description: Nanjing Loongmasses Ltd. "^lsi,.*": description: LSI Corp. (LSI Logic) "^lwn,.*": @@ -933,6 +943,8 @@ patternProperties: description: Nokia "^nordic,.*": description: Nordic Semiconductor + "^novatek,.*": + description: Novatek "^novtech,.*": description: NovTech, Inc. "^nutsboard,.*": @@ -977,6 +989,8 @@ patternProperties: description: OpenCores.org "^openembed,.*": description: OpenEmbed + "^openpandora,.*": + description: OpenPandora GmbH "^openrisc,.*": description: OpenRISC.io "^option,.*": @@ -1243,6 +1257,8 @@ patternProperties: description: Solomon Systech Limited "^sony,.*": description: Sony Corporation + "^sourceparts,.*": + description: Source Parts Inc. "^spansion,.*": description: Spansion Inc. "^sparkfun,.*": @@ -1528,6 +1544,8 @@ patternProperties: description: Yes Optoelectronics Co.,Ltd. "^yic,.*": description: YIC System Co., Ltd. + "^yiming,.*": + description: Henan Yiming Technology Co., Ltd. "^ylm,.*": description: Shenzhen Yangliming Electronic Technology Co., Ltd. "^yna,.*": diff --git a/Documentation/devicetree/bindings/w1/maxim,ds2482.yaml b/Documentation/devicetree/bindings/w1/maxim,ds2482.yaml new file mode 100644 index 000000000000..422becc6e1fa --- /dev/null +++ b/Documentation/devicetree/bindings/w1/maxim,ds2482.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/w1/maxim,ds2482.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim One wire bus master controller + +maintainers: + - Stefan Wahren <stefan.wahren@chargebyte.com> + +description: | + I2C to 1-wire bridges + + https://www.analog.com/media/en/technical-documentation/data-sheets/ds2482-100.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/DS2482-800.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/DS2484.pdf + +properties: + compatible: + enum: + - maxim,ds2482 + - maxim,ds2484 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: + type: object + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + onewire@18 { + compatible = "maxim,ds2484"; + reg = <0x18>; + }; + }; diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml index 026c2e5e77aa..274519fc24fd 100644 --- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Allwinner A10 Watchdog allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# maintainers: - Chen-Yu Tsai <wens@csie.org> diff --git a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml index e58c56a6fdf6..929681127df0 100644 --- a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Apple SoC Watchdog allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# maintainers: - Sven Peter <sven@svenpeter.dev> @@ -17,6 +17,7 @@ properties: items: - enum: - apple,t8103-wdt + - apple,t8112-wdt - apple,t6000-wdt - const: apple,wdt diff --git a/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml b/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml index e3a1d79574e2..fa05d6252982 100644 --- a/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ARM Secure Monitor Call based watchdog allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# maintainers: - Julius Werner <jwerner@chromium.org> diff --git a/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml index a9635c03761c..b28f7b57c36b 100644 --- a/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml @@ -10,7 +10,7 @@ maintainers: - Eugen Hristev <eugen.hristev@microchip.com> allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml index a926809352b8..428004e7f0c3 100644 --- a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: BCM63xx and BCM7038 watchdog timer allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# maintainers: - Florian Fainelli <f.fainelli@gmail.com> diff --git a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml index 6ecd429f76b5..6e135f48b3ba 100644 --- a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml +++ b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml @@ -15,7 +15,7 @@ description: | SoCs and others. allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml index 8562978aa0c8..d3790f1a96a2 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml @@ -10,7 +10,7 @@ maintainers: - Anson Huang <Anson.Huang@nxp.com> allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml b/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml index 38079e1b6a44..1a6490c43d89 100644 --- a/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml +++ b/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Maxim 63xx Watchdog Timers allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml# maintainers: diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml index e2c9bf1aec38..50c5c48ee6fb 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml @@ -115,7 +115,7 @@ required: - clocks allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# - if: not: diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml index 92df6e453f64..39139586611b 100644 --- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Synopsys Designware Watchdog Timer allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# maintainers: - Jamie Iles <jamie@jamieiles.com> @@ -29,6 +29,7 @@ properties: - rockchip,rk3368-wdt - rockchip,rk3399-wdt - rockchip,rk3568-wdt + - rockchip,rk3588-wdt - rockchip,rv1108-wdt - const: snps,dw-wdt diff --git a/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml index 70c005fdd197..ba0709314360 100644 --- a/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml @@ -10,7 +10,7 @@ maintainers: - Keiji Hayashibara <hayashibara.keiji@socionext.com> allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml index a8e266f80c20..2cb1a2ed0f7b 100644 --- a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml +++ b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml @@ -11,7 +11,7 @@ maintainers: - Christophe Roullier <christophe.roullier@foss.st.com> allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml b/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml index 2f33635876ff..fc553211e42d 100644 --- a/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml @@ -18,7 +18,7 @@ description: to directly reset the SoC. allOf: - - $ref: "watchdog.yaml#" + - $ref: watchdog.yaml# properties: compatible: diff --git a/Documentation/driver-api/clk.rst b/Documentation/driver-api/clk.rst index 3cad45d14187..93bab5336dfd 100644 --- a/Documentation/driver-api/clk.rst +++ b/Documentation/driver-api/clk.rst @@ -258,6 +258,11 @@ clocks properly but rely on them being on from the bootloader, bypassing the disabling means that the driver will remain functional while the issues are sorted out. +You can see which clocks have been disabled by booting your kernel with these +parameters:: + + tp_printk trace_event=clk:clk_disable + To bypass this disabling, include "clk_ignore_unused" in the bootargs to the kernel. diff --git a/Documentation/driver-api/device-io.rst b/Documentation/driver-api/device-io.rst index 4d2baac0311c..2c7abd234f4e 100644 --- a/Documentation/driver-api/device-io.rst +++ b/Documentation/driver-api/device-io.rst @@ -410,7 +410,7 @@ ioremap_uc() ioremap_uc() behaves like ioremap() except that on the x86 architecture without 'PAT' mode, it marks memory as uncached even when the MTRR has designated -it as cacheable, see Documentation/x86/pat.rst. +it as cacheable, see Documentation/arch/x86/pat.rst. Portable drivers should avoid the use of ioremap_uc(). diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 2e8dfd1a66b6..f92a32d095d9 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations .. kernel-doc:: drivers/dma-buf/dma-fence.c :doc: fence signalling annotation +DMA Fence Deadline Hints +~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :doc: deadline hints + DMA Fences Functions Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -197,8 +203,8 @@ DMA Fence unwrap .. kernel-doc:: include/linux/dma-fence-unwrap.h :internal: -DMA Fence uABI/Sync File -~~~~~~~~~~~~~~~~~~~~~~~~ +DMA Fence Sync File +~~~~~~~~~~~~~~~~~~~ .. kernel-doc:: drivers/dma-buf/sync_file.c :export: @@ -206,6 +212,12 @@ DMA Fence uABI/Sync File .. kernel-doc:: include/linux/sync_file.h :internal: +DMA Fence Sync File uABI +~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/uapi/linux/sync_file.h + :internal: + Indefinite DMA Fences ~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/driver-api/driver-model/bus.rst b/Documentation/driver-api/driver-model/bus.rst index 016b15a6e8ea..9709ab62a468 100644 --- a/Documentation/driver-api/driver-model/bus.rst +++ b/Documentation/driver-api/driver-model/bus.rst @@ -125,8 +125,8 @@ Exporting Attributes struct bus_attribute { struct attribute attr; - ssize_t (*show)(struct bus_type *, char * buf); - ssize_t (*store)(struct bus_type *, const char * buf, size_t count); + ssize_t (*show)(const struct bus_type *, char * buf); + ssize_t (*store)(const struct bus_type *, const char * buf, size_t count); }; Bus drivers can export attributes using the BUS_ATTR_RW macro that works diff --git a/Documentation/driver-api/firmware/fw_search_path.rst b/Documentation/driver-api/firmware/fw_search_path.rst index a360f1009fa3..d7cb1e8f0076 100644 --- a/Documentation/driver-api/firmware/fw_search_path.rst +++ b/Documentation/driver-api/firmware/fw_search_path.rst @@ -22,5 +22,10 @@ can use the file: * /sys/module/firmware_class/parameters/path -You would echo into it your custom path and firmware requested will be -searched for there first. +You would echo into it your custom path and firmware requested will be searched +for there first. Be aware that newline characters will be taken into account +and may not produce the intended effects. For instance you might want to use: + +echo -n /path/to/script > /sys/module/firmware_class/parameters/path + +to ensure that your script is being used. diff --git a/Documentation/driver-api/firmware/fw_upload.rst b/Documentation/driver-api/firmware/fw_upload.rst index 76922591e446..edf1d0c5e7c3 100644 --- a/Documentation/driver-api/firmware/fw_upload.rst +++ b/Documentation/driver-api/firmware/fw_upload.rst @@ -57,7 +57,8 @@ function calls firmware_upload_unregister() such as:: len = (truncate) ? truncate - fw_name : strlen(fw_name); sec->fw_name = kmemdup_nul(fw_name, len, GFP_KERNEL); - fwl = firmware_upload_register(sec->dev, sec->fw_name, &m10bmc_ops, sec); + fwl = firmware_upload_register(THIS_MODULE, sec->dev, sec->fw_name, + &m10bmc_ops, sec); if (IS_ERR(fwl)) { dev_err(sec->dev, "Firmware Upload driver failed to start\n"); kfree(sec->fw_name); diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 6baaeab79534..bf6319cc531b 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -218,10 +218,10 @@ not support open drain/open source in hardware, the GPIO library will instead use a trick: when a line is set as output, if the line is flagged as open drain, and the IN output value is low, it will be driven low as usual. But if the IN output value is set to high, it will instead *NOT* be driven high, -instead it will be switched to input, as input mode is high impedance, thus -achieving an "open drain emulation" of sorts: electrically the behaviour will -be identical, with the exception of possible hardware glitches when switching -the mode of the line. +instead it will be switched to input, as input mode is an equivalent to +high impedance, thus achieving an "open drain emulation" of sorts: electrically +the behaviour will be identical, with the exception of possible hardware glitches +when switching the mode of the line. For open source configuration the same principle is used, just that instead of actively driving the line low, it is set to input. diff --git a/Documentation/driver-api/gpio/legacy.rst b/Documentation/driver-api/gpio/legacy.rst index a0559d93efd1..78372853c6d4 100644 --- a/Documentation/driver-api/gpio/legacy.rst +++ b/Documentation/driver-api/gpio/legacy.rst @@ -238,8 +238,6 @@ setup or driver probe/teardown code, so this is an easy constraint.):: ## gpio_free_array() gpio_free() - gpio_set_debounce() - Claiming and Releasing GPIOs @@ -716,27 +714,6 @@ gpiochip nodes (possibly in conjunction with schematics) to determine the correct GPIO number to use for a given signal. -Exporting from Kernel code --------------------------- -Kernel code can explicitly manage exports of GPIOs which have already been -requested using gpio_request():: - - /* export the GPIO to userspace */ - int gpio_export(unsigned gpio, bool direction_may_change); - - /* reverse gpio_export() */ - void gpio_unexport(); - -After a kernel driver requests a GPIO, it may only be made available in -the sysfs interface by gpio_export(). The driver can control whether the -signal direction may change. This helps drivers prevent userspace code -from accidentally clobbering important system state. - -This explicit exporting can help with debugging (by making some kinds -of experiments easier), or can provide an always-there interface that's -suitable for documenting as part of a board support package. - - API Reference ============= diff --git a/Documentation/driver-api/media/drivers/ccs/ccs.rst b/Documentation/driver-api/media/drivers/ccs/ccs.rst index b461c8aa2a16..7389204afcb8 100644 --- a/Documentation/driver-api/media/drivers/ccs/ccs.rst +++ b/Documentation/driver-api/media/drivers/ccs/ccs.rst @@ -56,6 +56,28 @@ analogue data is never read from the pixel matrix that are outside the configured selection rectangle that designates crop. The difference has an effect in device timing and likely also in power consumption. +CCS static data +--------------- + +The MIPI CCS driver supports CCS static data for all compliant devices, +including not just those compliant with CCS 1.1 but also CCS 1.0 and SMIA(++). +For CCS the file names are formed as + + ccs/ccs-sensor-vvvv-mmmm-rrrr.fw (sensor) and + ccs/ccs-module-vvvv-mmmm-rrrr.fw (module). + +For SMIA++ compliant devices the corresponding file names are + + ccs/smiapp-sensor-vv-mmmm-rr.fw (sensor) and + ccs/smiapp-module-vv-mmmm-rrrr.fw (module). + +For SMIA (non-++) compliant devices the static data file name is + + ccs/smia-sensor-vv-mmmm-rr.fw (sensor). + +vvvv or vv denotes MIPI and SMIA manufacturer IDs respectively, mmmm model ID +and rrrr or rr revision number. + Register definition generator ----------------------------- diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst index 4a3adca417fd..c22f8c0f7950 100644 --- a/Documentation/driver-api/mtd/spi-nor.rst +++ b/Documentation/driver-api/mtd/spi-nor.rst @@ -63,6 +63,3 @@ The main API is spi_nor_scan(). Before you call the hook, a driver should initialize the necessary fields for spi_nor{}. Please see drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to spi-fsl-qspi.c when you want to write a new driver for a SPI NOR controller. -Another API is spi_nor_restore(), this is used to restore the status of SPI -flash chip such as addressing mode. Call it whenever detach the driver from -device or reboot the system. diff --git a/Documentation/driver-api/nvmem.rst b/Documentation/driver-api/nvmem.rst index e3366322d46c..de221e91c8e3 100644 --- a/Documentation/driver-api/nvmem.rst +++ b/Documentation/driver-api/nvmem.rst @@ -185,3 +185,18 @@ ex:: ===================== See Documentation/devicetree/bindings/nvmem/nvmem.txt + +8. NVMEM layouts +================ + +NVMEM layouts are yet another mechanism to create cells. With the device +tree binding it is possible to specify simple cells by using an offset +and a length. Sometimes, the cells doesn't have a static offset, but +the content is still well defined, e.g. tag-length-values. In this case, +the NVMEM device content has to be first parsed and the cells need to +be added accordingly. Layouts let you read the content of the NVMEM device +and let you add cells dynamically. + +Another use case for layouts is the post processing of cells. With layouts, +it is possible to associate a custom post processing hook to a cell. It +even possible to add this hook to cells not created by the layout itself. diff --git a/Documentation/driver-api/thermal/intel_dptf.rst b/Documentation/driver-api/thermal/intel_dptf.rst index f5c193cccbda..9ab4316322a1 100644 --- a/Documentation/driver-api/thermal/intel_dptf.rst +++ b/Documentation/driver-api/thermal/intel_dptf.rst @@ -184,8 +184,9 @@ ABI. DPTF Processor thermal RFIM interface -------------------------------------------- -RFIM interface allows adjustment of FIVR (Fully Integrated Voltage Regulator) -and DDR (Double Data Rate)frequencies to avoid RF interference with WiFi and 5G. +RFIM interface allows adjustment of FIVR (Fully Integrated Voltage Regulator), +DDR (Double Data Rate) and DLVR (Digital Linear Voltage Regulator) +frequencies to avoid RF interference with WiFi and 5G. Switching voltage regulators (VR) generate radiated EMI or RFI at the fundamental frequency and its harmonics. Some harmonics may interfere @@ -196,6 +197,15 @@ small % and shift away the switching noise harmonic interference from radio channels. OEM or ODMs can use the driver to control SOC IVR operation within the range where it does not impact IVR performance. +Some products use DLVR instead of FIVR as switching voltage regulator. +In this case attributes of DLVR must be adjusted instead of FIVR. + +While shifting the frequencies additional clock noise can be introduced, +which is compensated by adjusting Spread spectrum percent. This helps +to reduce the clock noise to meet regulatory compliance. This spreading +% increases bandwidth of signal transmission and hence reduces the +effects of interference, noise and signal fading. + DRAM devices of DDR IO interface and their power plane can generate EMI at the data rates. Similar to IVR control mechanism, Intel offers a mechanism by which DDR data rates can be changed if several conditions @@ -264,6 +274,38 @@ DVFS attributes ``rfi_disable (RW)`` Disable DDR rate change feature +DLVR attributes + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/dlvr/` + +``dlvr_hardware_rev`` (RO) + DLVR hardware revision. + +``dlvr_freq_mhz`` (RO) + Current DLVR PLL frequency in MHz. + +``dlvr_freq_select`` (RW) + Sets DLVR PLL clock frequency. Once set, and enabled via + dlvr_rfim_enable, the dlvr_freq_mhz will show the current + DLVR PLL frequency. + +``dlvr_pll_busy`` (RO) + PLL can't accept frequency change when set. + +``dlvr_rfim_enable`` (RW) + 0: Disable RF frequency hopping, 1: Enable RF frequency hopping. + +``dlvr_spread_spectrum_pct`` (RW) + Sets DLVR spread spectrum percent value. + +``dlvr_control_mode`` (RW) + Specifies how frequencies are spread using spread spectrum. + 0: Down spread, + 1: Spread in the Center. + +``dlvr_control_lock`` (RW) + 1: future writes are ignored. + DPTF Power supply and Battery Interface ---------------------------------------- diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst index 2e0f79a9e2ee..6c1175c6afba 100644 --- a/Documentation/driver-api/thermal/sysfs-api.rst +++ b/Documentation/driver-api/thermal/sysfs-api.rst @@ -306,42 +306,6 @@ temperature) and throttle appropriate devices. :: - struct thermal_bind_params - - This structure defines the following parameters that are used to bind - a zone with a cooling device for a particular trip point. - - .cdev: - The cooling device pointer - .weight: - The 'influence' of a particular cooling device on this - zone. This is relative to the rest of the cooling - devices. For example, if all cooling devices have a - weight of 1, then they all contribute the same. You can - use percentages if you want, but it's not mandatory. A - weight of 0 means that this cooling device doesn't - contribute to the cooling of this zone unless all cooling - devices have a weight of 0. If all weights are 0, then - they all contribute the same. - .trip_mask: - This is a bit mask that gives the binding relation between - this thermal zone and cdev, for a particular trip point. - If nth bit is set, then the cdev and thermal zone are bound - for trip point n. - .binding_limits: - This is an array of cooling state limits. Must have - exactly 2 * thermal_zone.number_of_trip_points. It is an - array consisting of tuples <lower-state upper-state> of - state limits. Each trip will be associated with one state - limit tuple when binding. A NULL pointer means - <THERMAL_NO_LIMITS THERMAL_NO_LIMITS> on all trips. - These limits are used when binding a cdev to a trip point. - .match: - This call back returns success(0) if the 'tz and cdev' need to - be bound, as per platform data. - - :: - struct thermal_zone_params This structure defines the platform level parameters for a thermal zone. @@ -357,10 +321,6 @@ temperature) and throttle appropriate devices. will be created. when no_hwmon == true, nothing will be done. In case the thermal_zone_params is NULL, the hwmon interface will be created (for backward compatibility). - .num_tbps: - Number of thermal_bind_params entries for this zone - .tbp: - thermal_bind_params entries 2. sysfs attributes structure ============================= diff --git a/Documentation/driver-api/tty/n_gsm.rst b/Documentation/driver-api/tty/n_gsm.rst index 9447b8a3b8e2..120317ec990f 100644 --- a/Documentation/driver-api/tty/n_gsm.rst +++ b/Documentation/driver-api/tty/n_gsm.rst @@ -29,6 +29,8 @@ Config Initiator #. Configure the mux using ``GSMIOC_GETCONF``/``GSMIOC_SETCONF`` ioctl. +#. Configure DLCs using ``GSMIOC_GETCONF_DLCI``/``GSMIOC_SETCONF_DLCI`` ioctl for non-defaults. + #. Obtain base gsmtty number for the used serial port. Major parts of the initialization program @@ -45,6 +47,7 @@ Config Initiator int ldisc = N_GSM0710; struct gsm_config c; struct gsm_config_ext ce; + struct gsm_dlci_config dc; struct termios configuration; uint32_t first; @@ -81,6 +84,13 @@ Config Initiator c.mtu = 127; /* set the new configuration */ ioctl(fd, GSMIOC_SETCONF, &c); + /* get DLC 1 configuration */ + dc.channel = 1; + ioctl(fd, GSMIOC_GETCONF_DLCI, &dc); + /* the first user channel gets a higher priority */ + dc.priority = 1; + /* set the new DLC 1 specific configuration */ + ioctl(fd, GSMIOC_SETCONF_DLCI, &dc); /* get first gsmtty device node */ ioctl(fd, GSMIOC_GETFIRST, &first); printf("first muxed line: /dev/gsmtty%i\n", first); @@ -120,6 +130,8 @@ Config Requester #. Configure the mux using ``GSMIOC_GETCONF``/``GSMIOC_SETCONF`` ioctl. +#. Configure DLCs using ``GSMIOC_GETCONF_DLCI``/``GSMIOC_SETCONF_DLCI`` ioctl for non-defaults. + #. Obtain base gsmtty number for the used serial port:: #include <stdio.h> @@ -132,6 +144,7 @@ Config Requester int ldisc = N_GSM0710; struct gsm_config c; struct gsm_config_ext ce; + struct gsm_dlci_config dc; struct termios configuration; uint32_t first; @@ -161,6 +174,13 @@ Config Requester c.mtu = 127; /* set the new configuration */ ioctl(fd, GSMIOC_SETCONF, &c); + /* get DLC 1 configuration */ + dc.channel = 1; + ioctl(fd, GSMIOC_GETCONF_DLCI, &dc); + /* the first user channel gets a higher priority */ + dc.priority = 1; + /* set the new DLC 1 specific configuration */ + ioctl(fd, GSMIOC_SETCONF_DLCI, &dc); /* get first gsmtty device node */ ioctl(fd, GSMIOC_GETFIRST, &first); printf("first muxed line: /dev/gsmtty%i\n", first); diff --git a/Documentation/driver-api/vfio.rst b/Documentation/driver-api/vfio.rst index 50b690f7f663..68abc089d6dd 100644 --- a/Documentation/driver-api/vfio.rst +++ b/Documentation/driver-api/vfio.rst @@ -242,7 +242,7 @@ group and can access them as follows:: VFIO User API ------------------------------------------------------------------------------- -Please see include/linux/vfio.h for complete API documentation. +Please see include/uapi/linux/vfio.h for complete API documentation. VFIO bus driver API ------------------------------------------------------------------------------- diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst index 08e420e10973..b64809514b0f 100644 --- a/Documentation/fault-injection/fault-injection.rst +++ b/Documentation/fault-injection/fault-injection.rst @@ -52,6 +52,14 @@ Available fault injection capabilities status code is NVME_SC_INVALID_OPCODE with no retry. The status code and retry flag can be set via the debugfs. +- Null test block driver fault injection + + inject IO timeouts by setting config items under + /sys/kernel/config/nullb/<disk>/timeout_inject, + inject requeue requests by setting config items under + /sys/kernel/config/nullb/<disk>/requeue_inject, and + inject init_hctx() errors by setting config items under + /sys/kernel/config/nullb/<disk>/init_hctx_fault_inject. Configure fault-injection capabilities behavior ----------------------------------------------- diff --git a/Documentation/features/sched/membarrier-sync-core/arch-support.txt b/Documentation/features/sched/membarrier-sync-core/arch-support.txt index 1e51614c136e..23260ca44946 100644 --- a/Documentation/features/sched/membarrier-sync-core/arch-support.txt +++ b/Documentation/features/sched/membarrier-sync-core/arch-support.txt @@ -5,7 +5,7 @@ # # Architecture requirements # -# * arm/arm64/powerpc +# * arm/arm64/powerpc/s390 # # Rely on implicit context synchronization as a result of exception return # when returning from IPI handler, and when returning to user-space. @@ -45,7 +45,7 @@ | parisc: | TODO | | powerpc: | ok | | riscv: | TODO | - | s390: | TODO | + | s390: | ok | | sh: | TODO | | sparc: | TODO | | um: | TODO | diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index a43aacf1494e..4654ee57c1d5 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -40,8 +40,8 @@ Here are the main features of EROFS: - Support multiple devices to refer to external blobs, which can be used for container images; - - 4KiB block size and 32-bit block addresses for each device, therefore - 16TiB address space at most for now; + - 32-bit block addresses for each device, therefore 16TiB address space at + most with 4KiB block size for now; - Two inode layouts for different requirements: diff --git a/Documentation/filesystems/ext4/blockgroup.rst b/Documentation/filesystems/ext4/blockgroup.rst index 46d78f860623..ed5a5cac6d40 100644 --- a/Documentation/filesystems/ext4/blockgroup.rst +++ b/Documentation/filesystems/ext4/blockgroup.rst @@ -105,9 +105,9 @@ descriptors. Instead, the superblock and a single block group descriptor block is placed at the beginning of the first, second, and last block groups in a meta-block group. A meta-block group is a collection of block groups which can be described by a single block group descriptor -block. Since the size of the block group descriptor structure is 32 -bytes, a meta-block group contains 32 block groups for filesystems with -a 1KB block size, and 128 block groups for filesystems with a 4KB +block. Since the size of the block group descriptor structure is 64 +bytes, a meta-block group contains 16 block groups for filesystems with +a 1KB block size, and 64 block groups for filesystems with a 4KB blocksize. Filesystems can either be created using this new block group descriptor layout, or existing filesystems can be resized on-line, and the field s_first_meta_bg in the superblock will indicate the first diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index 2055e72871fe..c57745375edb 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -264,7 +264,7 @@ checkpoint=%s[:%u[%]] Set to "disable" to turn off checkpointing. Set to "enabl disabled, any unmounting or unexpected shutdowns will cause the filesystem contents to appear as they did when the filesystem was mounted with that option. - While mounting with checkpoint=disabled, the filesystem must + While mounting with checkpoint=disable, the filesystem must run garbage collection to ensure that all available space can be used. If this takes too much time, the mount may return EAGAIN. You may optionally add a value to indicate how much diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst index b9b31066aef2..ad6d21640576 100644 --- a/Documentation/filesystems/idmappings.rst +++ b/Documentation/filesystems/idmappings.rst @@ -241,7 +241,7 @@ according to the filesystem's idmapping as this would give the wrong owner if the caller is using an idmapping. So the kernel will map the id back up in the idmapping of the caller. Let's -assume the caller has the slighly unconventional idmapping +assume the caller has the somewhat unconventional idmapping ``u3000:k20000:r10000`` then ``k21000`` would map back up to ``u4000``. Consequently the user would see that this file is owned by ``u4000``. @@ -320,6 +320,10 @@ and equally wrong:: from_kuid(u20000:k0:r10000, u1000) = k21000 ~~~~~ +Since userspace ids have type ``uid_t`` and ``gid_t`` and kernel ids have type +``kuid_t`` and ``kgid_t`` the compiler will throw an error when they are +conflated. So the two examples above would cause a compilation failure. + Idmappings when creating filesystem objects ------------------------------------------- @@ -623,42 +627,105 @@ privileged users in the initial user namespace. However, it is perfectly possible to combine idmapped mounts with filesystems mountable inside user namespaces. We will touch on this further below. +Filesystem types vs idmapped mount types +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +With the introduction of idmapped mounts we need to distinguish between +filesystem ownership and mount ownership of a VFS object such as an inode. The +owner of a inode might be different when looked at from a filesystem +perspective than when looked at from an idmapped mount. Such fundamental +conceptual distinctions should almost always be clearly expressed in the code. +So, to distinguish idmapped mount ownership from filesystem ownership separate +types have been introduced. + +If a uid or gid has been generated using the filesystem or caller's idmapping +then we will use the ``kuid_t`` and ``kgid_t`` types. However, if a uid or gid +has been generated using a mount idmapping then we will be using the dedicated +``vfsuid_t`` and ``vfsgid_t`` types. + +All VFS helpers that generate or take uids and gids as arguments use the +``vfsuid_t`` and ``vfsgid_t`` types and we will be able to rely on the compiler +to catch errors that originate from conflating filesystem and VFS uids and gids. + +The ``vfsuid_t`` and ``vfsgid_t`` types are often mapped from and to ``kuid_t`` +and ``kgid_t`` types similar how ``kuid_t`` and ``kgid_t`` types are mapped +from and to ``uid_t`` and ``gid_t`` types:: + + uid_t <--> kuid_t <--> vfsuid_t + gid_t <--> kgid_t <--> vfsgid_t + +Whenever we report ownership based on a ``vfsuid_t`` or ``vfsgid_t`` type, +e.g., during ``stat()``, or store ownership information in a shared VFS object +based on a ``vfsuid_t`` or ``vfsgid_t`` type, e.g., during ``chown()`` we can +use the ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()`` helpers. + +To illustrate why this helper currently exists, consider what happens when we +change ownership of an inode from an idmapped mount. After we generated +a ``vfsuid_t`` or ``vfsgid_t`` based on the mount idmapping we later commit to +this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesytem wide ownership. +Thus, we are turning the ``vfsuid_t`` or ``vfsgid_t`` into a global ``kuid_t`` +or ``kgid_t``. And this can be done by using ``vfsuid_into_kuid()`` and +``vfsgid_into_kgid()``. + +Note, whenever a shared VFS object, e.g., a cached ``struct inode`` or a cached +``struct posix_acl``, stores ownership information a filesystem or "global" +``kuid_t`` and ``kgid_t`` must be used. Ownership expressed via ``vfsuid_t`` +and ``vfsgid_t`` is specific to an idmapped mount. + +We already noted that ``vfsuid_t`` and ``vfsgid_t`` types are generated based +on mount idmappings whereas ``kuid_t`` and ``kgid_t`` types are generated based +on filesystem idmappings. To prevent abusing filesystem idmappings to generate +``vfsuid_t`` or ``vfsgid_t`` types or mount idmappings to generate ``kuid_t`` +or ``kgid_t`` types filesystem idmappings and mount idmappings are different +types as well. + +All helpers that map to or from ``vfsuid_t`` and ``vfsgid_t`` types require +a mount idmapping to be passed which is of type ``struct mnt_idmap``. Passing +a filesystem or caller idmapping will cause a compilation error. + +Similar to how we prefix all userspace ids in this document with ``u`` and all +kernel ids with ``k`` we will prefix all VFS ids with ``v``. So a mount +idmapping will be written as: ``u0:v10000:r10000``. + Remapping helpers ~~~~~~~~~~~~~~~~~ Idmapping functions were added that translate between idmappings. They make use -of the remapping algorithm we've introduced earlier. We're going to look at -two: +of the remapping algorithm we've introduced earlier. We're going to look at: -- ``i_uid_into_mnt()`` and ``i_gid_into_mnt()`` +- ``i_uid_into_vfsuid()`` and ``i_gid_into_vfsgid()`` - The ``i_*id_into_mnt()`` functions translate filesystem's kernel ids into - kernel ids in the mount's idmapping:: + The ``i_*id_into_vfs*id()`` functions translate filesystem's kernel ids into + VFS ids in the mount's idmapping:: /* Map the filesystem's kernel id up into a userspace id in the filesystem's idmapping. */ from_kuid(filesystem, kid) = uid - /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */ + /* Map the filesystem's userspace id down ito a VFS id in the mount's idmapping. */ make_kuid(mount, uid) = kuid - ``mapped_fsuid()`` and ``mapped_fsgid()`` The ``mapped_fs*id()`` functions translate the caller's kernel ids into kernel ids in the filesystem's idmapping. This translation is achieved by - remapping the caller's kernel ids using the mount's idmapping:: + remapping the caller's VFS ids using the mount's idmapping:: - /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */ + /* Map the caller's VFS id up into a userspace id in the mount's idmapping. */ from_kuid(mount, kid) = uid /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */ make_kuid(filesystem, uid) = kuid +- ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()`` + + Whenever + Note that these two functions invert each other. Consider the following idmappings:: caller idmapping: u0:k10000:r10000 filesystem idmapping: u0:k20000:r10000 - mount idmapping: u0:k10000:r10000 + mount idmapping: u0:v10000:r10000 Assume a file owned by ``u1000`` is read from disk. The filesystem maps this id to ``k21000`` according to its idmapping. This is what is stored in the @@ -669,20 +736,21 @@ would usually simply use the crossmapping algorithm and map the filesystem's kernel id up to a userspace id in the caller's idmapping. But when the caller is accessing the file on an idmapped mount the kernel will -first call ``i_uid_into_mnt()`` thereby translating the filesystem's kernel id -into a kernel id in the mount's idmapping:: +first call ``i_uid_into_vfsuid()`` thereby translating the filesystem's kernel +id into a VFS id in the mount's idmapping:: - i_uid_into_mnt(k21000): + i_uid_into_vfsuid(k21000): /* Map the filesystem's kernel id up into a userspace id. */ from_kuid(u0:k20000:r10000, k21000) = u1000 - /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */ - make_kuid(u0:k10000:r10000, u1000) = k11000 + /* Map the filesystem's userspace id down into a VFS id in the mount's idmapping. */ + make_kuid(u0:v10000:r10000, u1000) = v11000 Finally, when the kernel reports the owner to the caller it will turn the -kernel id in the mount's idmapping into a userspace id in the caller's +VFS id in the mount's idmapping into a userspace id in the caller's idmapping:: + k11000 = vfsuid_into_kuid(v11000) from_kuid(u0:k10000:r10000, k11000) = u1000 We can test whether this algorithm really works by verifying what happens when @@ -696,18 +764,19 @@ fails. But when the caller is accessing the file on an idmapped mount the kernel will first call ``mapped_fs*id()`` thereby translating the caller's kernel id into -a kernel id according to the mount's idmapping:: +a VFS id according to the mount's idmapping:: mapped_fsuid(k11000): /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */ from_kuid(u0:k10000:r10000, k11000) = u1000 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */ - make_kuid(u0:k20000:r10000, u1000) = k21000 + make_kuid(u0:v20000:r10000, u1000) = v21000 -When finally writing to disk the kernel will then map ``k21000`` up into a +When finally writing to disk the kernel will then map ``v21000`` up into a userspace id in the filesystem's idmapping:: + k21000 = vfsuid_into_kuid(v21000) from_kuid(u0:k20000:r10000, k21000) = u1000 As we can see, we end up with an invertible and therefore information @@ -725,7 +794,7 @@ Example 2 reconsidered caller id: u1000 caller idmapping: u0:k10000:r10000 filesystem idmapping: u0:k20000:r10000 - mount idmapping: u0:k10000:r10000 + mount idmapping: u0:v10000:r10000 When the caller is using a non-initial idmapping the common case is to attach the same idmapping to the mount. We now perform three steps: @@ -734,12 +803,12 @@ the same idmapping to the mount. We now perform three steps: make_kuid(u0:k10000:r10000, u1000) = k11000 -2. Translate the caller's kernel id into a kernel id in the filesystem's +2. Translate the caller's VFS id into a kernel id in the filesystem's idmapping:: - mapped_fsuid(k11000): - /* Map the kernel id up into a userspace id in the mount's idmapping. */ - from_kuid(u0:k10000:r10000, k11000) = u1000 + mapped_fsuid(v11000): + /* Map the VFS id up into a userspace id in the mount's idmapping. */ + from_kuid(u0:v10000:r10000, v11000) = u1000 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ make_kuid(u0:k20000:r10000, u1000) = k21000 @@ -759,7 +828,7 @@ Example 3 reconsidered caller id: u1000 caller idmapping: u0:k10000:r10000 filesystem idmapping: u0:k0:r4294967295 - mount idmapping: u0:k10000:r10000 + mount idmapping: u0:v10000:r10000 The same translation algorithm works with the third example. @@ -767,12 +836,12 @@ The same translation algorithm works with the third example. make_kuid(u0:k10000:r10000, u1000) = k11000 -2. Translate the caller's kernel id into a kernel id in the filesystem's +2. Translate the caller's VFS id into a kernel id in the filesystem's idmapping:: - mapped_fsuid(k11000): - /* Map the kernel id up into a userspace id in the mount's idmapping. */ - from_kuid(u0:k10000:r10000, k11000) = u1000 + mapped_fsuid(v11000): + /* Map the VFS id up into a userspace id in the mount's idmapping. */ + from_kuid(u0:v10000:r10000, v11000) = u1000 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ make_kuid(u0:k0:r4294967295, u1000) = k1000 @@ -792,7 +861,7 @@ Example 4 reconsidered file id: u1000 caller idmapping: u0:k10000:r10000 filesystem idmapping: u0:k0:r4294967295 - mount idmapping: u0:k10000:r10000 + mount idmapping: u0:v10000:r10000 In order to report ownership to userspace the kernel now does three steps using the translation algorithm we introduced earlier: @@ -802,17 +871,18 @@ the translation algorithm we introduced earlier: make_kuid(u0:k0:r4294967295, u1000) = k1000 -2. Translate the kernel id into a kernel id in the mount's idmapping:: +2. Translate the kernel id into a VFS id in the mount's idmapping:: - i_uid_into_mnt(k1000): + i_uid_into_vfsuid(k1000): /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ from_kuid(u0:k0:r4294967295, k1000) = u1000 - /* Map the userspace id down into a kernel id in the mounts's idmapping. */ - make_kuid(u0:k10000:r10000, u1000) = k11000 + /* Map the userspace id down into a VFS id in the mounts's idmapping. */ + make_kuid(u0:v10000:r10000, u1000) = v11000 -3. Map the kernel id up into a userspace id in the caller's idmapping:: +3. Map the VFS id up into a userspace id in the caller's idmapping:: + k11000 = vfsuid_into_kuid(v11000) from_kuid(u0:k10000:r10000, k11000) = u1000 Earlier, the caller's kernel id couldn't be crossmapped in the filesystems's @@ -828,7 +898,7 @@ Example 5 reconsidered file id: u1000 caller idmapping: u0:k10000:r10000 filesystem idmapping: u0:k20000:r10000 - mount idmapping: u0:k10000:r10000 + mount idmapping: u0:v10000:r10000 Again, in order to report ownership to userspace the kernel now does three steps using the translation algorithm we introduced earlier: @@ -838,17 +908,18 @@ steps using the translation algorithm we introduced earlier: make_kuid(u0:k20000:r10000, u1000) = k21000 -2. Translate the kernel id into a kernel id in the mount's idmapping:: +2. Translate the kernel id into a VFS id in the mount's idmapping:: - i_uid_into_mnt(k21000): + i_uid_into_vfsuid(k21000): /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ from_kuid(u0:k20000:r10000, k21000) = u1000 - /* Map the userspace id down into a kernel id in the mounts's idmapping. */ - make_kuid(u0:k10000:r10000, u1000) = k11000 + /* Map the userspace id down into a VFS id in the mounts's idmapping. */ + make_kuid(u0:v10000:r10000, u1000) = v11000 -3. Map the kernel id up into a userspace id in the caller's idmapping:: +3. Map the VFS id up into a userspace id in the caller's idmapping:: + k11000 = vfsuid_into_kuid(v11000) from_kuid(u0:k10000:r10000, k11000) = u1000 Earlier, the file's kernel id couldn't be crossmapped in the filesystems's @@ -899,23 +970,23 @@ from above::: caller id: u1125 caller idmapping: u0:k0:r4294967295 filesystem idmapping: u0:k0:r4294967295 - mount idmapping: u1000:k1125:r1 + mount idmapping: u1000:v1125:r1 1. Map the caller's userspace ids into kernel ids in the caller's idmapping:: make_kuid(u0:k0:r4294967295, u1125) = k1125 -2. Translate the caller's kernel id into a kernel id in the filesystem's +2. Translate the caller's VFS id into a kernel id in the filesystem's idmapping:: - mapped_fsuid(k1125): - /* Map the kernel id up into a userspace id in the mount's idmapping. */ - from_kuid(u1000:k1125:r1, k1125) = u1000 + mapped_fsuid(v1125): + /* Map the VFS id up into a userspace id in the mount's idmapping. */ + from_kuid(u1000:v1125:r1, v1125) = u1000 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ make_kuid(u0:k0:r4294967295, u1000) = k1000 -2. Verify that the caller's kernel ids can be mapped to userspace ids in the +2. Verify that the caller's filesystem ids can be mapped to userspace ids in the filesystem's idmapping:: from_kuid(u0:k0:r4294967295, k1000) = u1000 @@ -930,24 +1001,25 @@ on their work computer: file id: u1000 caller idmapping: u0:k0:r4294967295 filesystem idmapping: u0:k0:r4294967295 - mount idmapping: u1000:k1125:r1 + mount idmapping: u1000:v1125:r1 1. Map the userspace id on disk down into a kernel id in the filesystem's idmapping:: make_kuid(u0:k0:r4294967295, u1000) = k1000 -2. Translate the kernel id into a kernel id in the mount's idmapping:: +2. Translate the kernel id into a VFS id in the mount's idmapping:: - i_uid_into_mnt(k1000): + i_uid_into_vfsuid(k1000): /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ from_kuid(u0:k0:r4294967295, k1000) = u1000 - /* Map the userspace id down into a kernel id in the mounts's idmapping. */ - make_kuid(u1000:k1125:r1, u1000) = k1125 + /* Map the userspace id down into a VFS id in the mounts's idmapping. */ + make_kuid(u1000:v1125:r1, u1000) = v1125 -3. Map the kernel id up into a userspace id in the caller's idmapping:: +3. Map the VFS id up into a userspace id in the caller's idmapping:: + k1125 = vfsuid_into_kuid(v1125) from_kuid(u0:k0:r4294967295, k1125) = u1125 So ultimately the caller will be reported that the file belongs to ``u1125`` diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index bee63d42e5ec..fbb2b5ada95b 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -123,4 +123,5 @@ Documentation for filesystem implementations. vfat xfs-delayed-logging-design xfs-self-describing-metadata + xfs-online-fsck-design zonefs diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 7de7a7272a5e..aa1a233b0fa8 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -645,7 +645,7 @@ ops mmap_lock PageLocked(page) open: yes close: yes fault: yes can return with page locked -map_pages: yes +map_pages: read page_mkwrite: yes can return with page locked pfn_mkwrite: yes access: yes @@ -661,7 +661,7 @@ locked. The VM will unlock the page. ->map_pages() is called when VM asks to map easy accessible pages. Filesystem should find and map pages associated with offsets from "start_pgoff" -till "end_pgoff". ->map_pages() is called with page table locked and must +till "end_pgoff". ->map_pages() is called with the RCU lock held and must not block. If it's not possible to reach a page without blocking, filesystem should skip it. Filesystem should use do_set_pte() to setup page table entry. Pointer to entry associated with the page is passed in diff --git a/Documentation/filesystems/mount_api.rst b/Documentation/filesystems/mount_api.rst index 63204d2094fd..9aaf6ef75eb5 100644 --- a/Documentation/filesystems/mount_api.rst +++ b/Documentation/filesystems/mount_api.rst @@ -79,7 +79,6 @@ context. This is represented by the fs_context structure:: unsigned int sb_flags; unsigned int sb_flags_mask; unsigned int s_iflags; - unsigned int lsm_flags; enum fs_context_purpose purpose:8; ... }; diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst index 5aa102bd72c2..f0cf05cad2ba 100644 --- a/Documentation/filesystems/ntfs3.rst +++ b/Documentation/filesystems/ntfs3.rst @@ -61,17 +61,6 @@ this table marked with no it means default is without **no**. directories, fmask applies only to files and dmask only to directories. * - fmask= - * - noacsrules - - "No access rules" mount option sets access rights for files/folders to - 777 and owner/group to root. This mount option absorbs all other - permissions. - - - Permissions change for files/folders will be reported as successful, - but they will remain 777. - - - Owner/group change will be reported as successful, butthey will stay - as root. - * - nohidden - Files with the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN) attribute will not be shown under Linux. diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 9d5fd9424e8b..7897a7dafcbc 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -85,7 +85,7 @@ contact Bodo Bauer at bb@ricochet.net. We'll be happy to add them to this document. The latest version of this document is available online at -http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html +https://www.kernel.org/doc/html/latest/filesystems/proc.html If the above direction does not works for you, you could try the kernel mailing list at linux-kernel@vger.kernel.org and/or try to reach me at @@ -179,6 +179,7 @@ read the file /proc/PID/status:: Gid: 100 100 100 100 FDSize: 256 Groups: 100 14 16 + Kthread: 0 VmPeak: 5004 kB VmSize: 5004 kB VmLck: 0 kB @@ -232,7 +233,7 @@ asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc/<pid>/smaps file and scan page table. It's slow but very precise. -.. table:: Table 1-2: Contents of the status files (as of 4.19) +.. table:: Table 1-2: Contents of the status fields (as of 4.19) ========================== =================================================== Field Content @@ -256,6 +257,7 @@ It's slow but very precise. NSpid descendant namespace process ID hierarchy NSpgid descendant namespace process group ID hierarchy NSsid descendant namespace session ID hierarchy + Kthread kernel thread flag, 1 is yes, 0 is no VmPeak peak virtual memory size VmSize total program size VmLck locked memory size @@ -305,7 +307,7 @@ It's slow but very precise. ========================== =================================================== -.. table:: Table 1-3: Contents of the statm files (as of 2.6.8-rc3) +.. table:: Table 1-3: Contents of the statm fields (as of 2.6.8-rc3) ======== =============================== ============================== Field Content @@ -323,7 +325,7 @@ It's slow but very precise. ======== =============================== ============================== -.. table:: Table 1-4: Contents of the stat files (as of 2.6.30-rc7) +.. table:: Table 1-4: Contents of the stat fields (as of 2.6.30-rc7) ============= =============================================================== Field Content @@ -996,6 +998,7 @@ Example output. You may not have all of these fields. VmallocUsed: 40444 kB VmallocChunk: 0 kB Percpu: 29312 kB + EarlyMemtestBad: 0 kB HardwareCorrupted: 0 kB AnonHugePages: 4149248 kB ShmemHugePages: 0 kB @@ -1146,6 +1149,13 @@ VmallocChunk Percpu Memory allocated to the percpu allocator used to back percpu allocations. This stat excludes the cost of metadata. +EarlyMemtestBad + The amount of RAM/memory in kB, that was identified as corrupted + by early memtest. If memtest was not run, this field will not + be displayed at all. Size is never rounded down to 0 kB. + That means if 0 kB is reported, you can safely assume + there was at least one pass of memtest and none of the passes + found a single faulty byte of RAM. HardwareCorrupted The amount of RAM/memory in KB, the kernel identifies as corrupted. @@ -1321,9 +1331,9 @@ many times the slaves link has failed. 1.4 SCSI info ------------- -If you have a SCSI host adapter in your system, you'll find a subdirectory -named after the driver for this adapter in /proc/scsi. You'll also see a list -of all recognized SCSI devices in /proc/scsi:: +If you have a SCSI or ATA host adapter in your system, you'll find a +subdirectory named after the driver for this adapter in /proc/scsi. +You'll also see a list of all recognized SCSI devices in /proc/scsi:: >cat /proc/scsi/scsi Attached devices: @@ -1449,16 +1459,18 @@ Various pieces of information about kernel activity are available in the since the system first booted. For a quick look, simply cat the file:: > cat /proc/stat - cpu 2255 34 2290 22625563 6290 127 456 0 0 0 - cpu0 1132 34 1441 11311718 3675 127 438 0 0 0 - cpu1 1123 0 849 11313845 2614 0 18 0 0 0 - intr 114930548 113199788 3 0 5 263 0 4 [... lots more numbers ...] - ctxt 1990473 - btime 1062191376 - processes 2915 - procs_running 1 + cpu 237902850 368826709 106375398 1873517540 1135548 0 14507935 0 0 0 + cpu0 60045249 91891769 26331539 468411416 495718 0 5739640 0 0 0 + cpu1 59746288 91759249 26609887 468860630 312281 0 4384817 0 0 0 + cpu2 59489247 92985423 26904446 467808813 171668 0 2268998 0 0 0 + cpu3 58622065 92190267 26529524 468436680 155879 0 2114478 0 0 0 + intr 8688370575 8 3373 0 0 0 0 0 0 1 40791 0 0 353317 0 0 0 0 224789828 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 190974333 41958554 123983334 43 0 224593 0 0 0 <more 0's deleted> + ctxt 22848221062 + btime 1605316999 + processes 746787147 + procs_running 2 procs_blocked 0 - softirq 183433 0 21755 12 39 1137 231 21459 2263 + softirq 12121874454 100099120 3938138295 127375644 2795979 187870761 0 173808342 3072582055 52608 224184354 The very first "cpu" line aggregates the numbers in all of the other "cpuN" lines. These numbers identify the amount of time the CPU has spent performing @@ -1520,8 +1532,8 @@ softirq. Information about mounted ext4 file systems can be found in /proc/fs/ext4. Each mounted filesystem will have a directory in /proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or -/proc/fs/ext4/dm-0). The files in each per-device directory are shown -in Table 1-12, below. +/proc/fs/ext4/sda9 or /proc/fs/ext4/dm-0). The files in each per-device +directory are shown in Table 1-12, below. .. table:: Table 1-12: Files in /proc/fs/ext4/<devname> @@ -1601,12 +1613,12 @@ can inadvertently disrupt your system, it is advisable to read both documentation and source before actually making adjustments. In any case, be very careful when writing to any of these files. The entries in /proc may change slightly between the 2.1.* and the 2.2 kernel, so if there is any doubt -review the kernel documentation in the directory /usr/src/linux/Documentation. +review the kernel documentation in the directory linux/Documentation. This chapter is heavily based on the documentation included in the pre 2.2 kernels, and became part of it in version 2.2.1 of the Linux kernel. -Please see: Documentation/admin-guide/sysctl/ directory for descriptions of these -entries. +Please see: Documentation/admin-guide/sysctl/ directory for descriptions of +these entries. Summary ------- diff --git a/Documentation/filesystems/sysfs.rst b/Documentation/filesystems/sysfs.rst index f8187d466b97..c32993bc83c7 100644 --- a/Documentation/filesystems/sysfs.rst +++ b/Documentation/filesystems/sysfs.rst @@ -373,8 +373,8 @@ Structure:: struct bus_attribute { struct attribute attr; - ssize_t (*show)(struct bus_type *, char * buf); - ssize_t (*store)(struct bus_type *, const char * buf, size_t count); + ssize_t (*show)(const struct bus_type *, char * buf); + ssize_t (*store)(const struct bus_type *, const char * buf, size_t count); }; Declaring:: diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst index 0408c245785e..f18f46be5c0c 100644 --- a/Documentation/filesystems/tmpfs.rst +++ b/Documentation/filesystems/tmpfs.rst @@ -13,17 +13,29 @@ everything stored therein is lost. tmpfs puts everything into the kernel internal caches and grows and shrinks to accommodate the files it contains and is able to swap -unneeded pages out to swap space. It has maximum size limits which can -be adjusted on the fly via 'mount -o remount ...' - -If you compare it to ramfs (which was the template to create tmpfs) -you gain swapping and limit checking. Another similar thing is the RAM -disk (/dev/ram*), which simulates a fixed size hard disk in physical -RAM, where you have to create an ordinary filesystem on top. Ramdisks -cannot swap and you do not have the possibility to resize them. - -Since tmpfs lives completely in the page cache and on swap, all tmpfs -pages will be shown as "Shmem" in /proc/meminfo and "Shared" in +unneeded pages out to swap space, if swap was enabled for the tmpfs +mount. tmpfs also supports THP. + +tmpfs extends ramfs with a few userspace configurable options listed and +explained further below, some of which can be reconfigured dynamically on the +fly using a remount ('mount -o remount ...') of the filesystem. A tmpfs +filesystem can be resized but it cannot be resized to a size below its current +usage. tmpfs also supports POSIX ACLs, and extended attributes for the +trusted.* and security.* namespaces. ramfs does not use swap and you cannot +modify any parameter for a ramfs filesystem. The size limit of a ramfs +filesystem is how much memory you have available, and so care must be taken if +used so to not run out of memory. + +An alternative to tmpfs and ramfs is to use brd to create RAM disks +(/dev/ram*), which allows you to simulate a block device disk in physical RAM. +To write data you would just then need to create an regular filesystem on top +this ramdisk. As with ramfs, brd ramdisks cannot swap. brd ramdisks are also +configured in size at initialization and you cannot dynamically resize them. +Contrary to brd ramdisks, tmpfs has its own filesystem, it does not rely on the +block layer at all. + +Since tmpfs lives completely in the page cache and optionally on swap, +all tmpfs pages will be shown as "Shmem" in /proc/meminfo and "Shared" in free(1). Notice that these counters also include shared memory (shmem, see ipcs(1)). The most reliable way to get the count is using df(1) and du(1). @@ -72,6 +84,8 @@ nr_inodes The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is the lower. +noswap Disables swap. Remounts must respect the original settings. + By default swap is enabled. ========= ============================================================ These parameters accept a suffix k, m or g for kilo, mega and giga and @@ -85,6 +99,36 @@ mount with such options, since it allows any user with write access to use up all the memory on the machine; but enhances the scalability of that instance in a system with many CPUs making intensive use of it. +tmpfs also supports Transparent Huge Pages which requires a kernel +configured with CONFIG_TRANSPARENT_HUGEPAGE and with huge supported for +your system (has_transparent_hugepage(), which is architecture specific). +The mount options for this are: + +====== ============================================================ +huge=0 never: disables huge pages for the mount +huge=1 always: enables huge pages for the mount +huge=2 within_size: only allocate huge pages if the page will be + fully within i_size, also respect fadvise()/madvise() hints. +huge=3 advise: only allocate huge pages if requested with + fadvise()/madvise() +====== ============================================================ + +There is a sysfs file which you can also use to control system wide THP +configuration for all tmpfs mounts, the file is: + +/sys/kernel/mm/transparent_hugepage/shmem_enabled + +This sysfs file is placed on top of THP sysfs directory and so is registered +by THP code. It is however only used to control all tmpfs mounts with one +single knob. Since it controls all tmpfs mounts it should only be used either +for emergency or testing purposes. The values you can set for shmem_enabled are: + +== ============================================================ +-1 deny: disables huge on shm_mnt and all mounts, for + emergency use +-2 force: enables huge on shm_mnt and all mounts, w/o needing + option, for testing +== ============================================================ tmpfs has a mount option to set the NUMA memory allocation policy for all files in that instance (if CONFIG_NUMA is enabled) - which can be diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index c53f30251a66..769be5230210 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -107,7 +107,7 @@ file /proc/filesystems. struct file_system_type ----------------------- -This describes the filesystem. As of kernel 2.6.39, the following +This describes the filesystem. The following members are defined: .. code-block:: c @@ -115,14 +115,24 @@ members are defined: struct file_system_type { const char *name; int fs_flags; + int (*init_fs_context)(struct fs_context *); + const struct fs_parameter_spec *parameters; struct dentry *(*mount) (struct file_system_type *, int, - const char *, void *); + const char *, void *); void (*kill_sb) (struct super_block *); struct module *owner; struct file_system_type * next; - struct list_head fs_supers; + struct hlist_head fs_supers; + struct lock_class_key s_lock_key; struct lock_class_key s_umount_key; + struct lock_class_key s_vfs_rename_key; + struct lock_class_key s_writers_key[SB_FREEZE_LEVELS]; + + struct lock_class_key i_lock_key; + struct lock_class_key i_mutex_key; + struct lock_class_key invalidate_lock_key; + struct lock_class_key i_mutex_dir_key; }; ``name`` @@ -132,6 +142,15 @@ members are defined: ``fs_flags`` various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.) +``init_fs_context`` + Initializes 'struct fs_context' ->ops and ->fs_private fields with + filesystem-specific data. + +``parameters`` + Pointer to the array of filesystem parameters descriptors + 'struct fs_parameter_spec'. + More info in Documentation/filesystems/mount_api.rst. + ``mount`` the method to call when a new instance of this filesystem should be mounted @@ -148,7 +167,11 @@ members are defined: ``next`` for internal VFS use: you should initialize this to NULL - s_lock_key, s_umount_key: lockdep-specific +``fs_supers`` + for internal VFS use: hlist of filesystem instances (superblocks) + + s_lock_key, s_umount_key, s_vfs_rename_key, s_writers_key, + i_lock_key, i_mutex_key, invalidate_lock_key, i_mutex_dir_key: lockdep-specific The mount() method has the following arguments: @@ -222,33 +245,42 @@ struct super_operations ----------------------- This describes how the VFS can manipulate the superblock of your -filesystem. As of kernel 2.6.22, the following members are defined: +filesystem. The following members are defined: .. code-block:: c struct super_operations { struct inode *(*alloc_inode)(struct super_block *sb); void (*destroy_inode)(struct inode *); + void (*free_inode)(struct inode *); void (*dirty_inode) (struct inode *, int flags); - int (*write_inode) (struct inode *, int); - void (*drop_inode) (struct inode *); - void (*delete_inode) (struct inode *); + int (*write_inode) (struct inode *, struct writeback_control *wbc); + int (*drop_inode) (struct inode *); + void (*evict_inode) (struct inode *); void (*put_super) (struct super_block *); int (*sync_fs)(struct super_block *sb, int wait); + int (*freeze_super) (struct super_block *); int (*freeze_fs) (struct super_block *); + int (*thaw_super) (struct super_block *); int (*unfreeze_fs) (struct super_block *); int (*statfs) (struct dentry *, struct kstatfs *); int (*remount_fs) (struct super_block *, int *, char *); - void (*clear_inode) (struct inode *); void (*umount_begin) (struct super_block *); int (*show_options)(struct seq_file *, struct dentry *); + int (*show_devname)(struct seq_file *, struct dentry *); + int (*show_path)(struct seq_file *, struct dentry *); + int (*show_stats)(struct seq_file *, struct dentry *); ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t); ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t); - int (*nr_cached_objects)(struct super_block *); - void (*free_cached_objects)(struct super_block *, int); + struct dquot **(*get_dquots)(struct inode *); + + long (*nr_cached_objects)(struct super_block *, + struct shrink_control *); + long (*free_cached_objects)(struct super_block *, + struct shrink_control *); }; All methods are called without any locks being held, unless otherwise @@ -269,6 +301,11 @@ or bottom half). ->alloc_inode was defined and simply undoes anything done by ->alloc_inode. +``free_inode`` + this method is called from RCU callback. If you use call_rcu() + in ->destroy_inode to free 'struct inode' memory, then it's + better to release memory in this method. + ``dirty_inode`` this method is called by the VFS when an inode is marked dirty. This is specifically for the inode itself being marked dirty, @@ -296,8 +333,12 @@ or bottom half). practice of using "force_delete" in the put_inode() case, but does not have the races that the "force_delete()" approach had. -``delete_inode`` - called when the VFS wants to delete an inode +``evict_inode`` + called when the VFS wants to evict an inode. Caller does + *not* evict the pagecache or inode-associated metadata buffers; + the method has to use truncate_inode_pages_final() to get rid + of those. Caller makes sure async writeback cannot be running for + the inode while (or after) ->evict_inode() is called. Optional. ``put_super`` called when the VFS wishes to free the superblock @@ -308,14 +349,25 @@ or bottom half). superblock. The second parameter indicates whether the method should wait until the write out has been completed. Optional. +``freeze_super`` + Called instead of ->freeze_fs callback if provided. + Main difference is that ->freeze_super is called without taking + down_write(&sb->s_umount). If filesystem implements it and wants + ->freeze_fs to be called too, then it has to call ->freeze_fs + explicitly from this callback. Optional. + ``freeze_fs`` called when VFS is locking a filesystem and forcing it into a consistent state. This method is currently used by the Logical - Volume Manager (LVM). + Volume Manager (LVM) and ioctl(FIFREEZE). Optional. + +``thaw_super`` + called when VFS is unlocking a filesystem and making it writable + again after ->freeze_super. Optional. ``unfreeze_fs`` called when VFS is unlocking a filesystem and making it writable - again. + again after ->freeze_fs. Optional. ``statfs`` called when the VFS needs to get filesystem statistics. @@ -324,22 +376,37 @@ or bottom half). called when the filesystem is remounted. This is called with the kernel lock held -``clear_inode`` - called then the VFS clears the inode. Optional - ``umount_begin`` called when the VFS is unmounting a filesystem. ``show_options`` - called by the VFS to show mount options for /proc/<pid>/mounts. + called by the VFS to show mount options for /proc/<pid>/mounts + and /proc/<pid>/mountinfo. (see "Mount Options" section) +``show_devname`` + Optional. Called by the VFS to show device name for + /proc/<pid>/{mounts,mountinfo,mountstats}. If not provided then + '(struct mount).mnt_devname' will be used. + +``show_path`` + Optional. Called by the VFS (for /proc/<pid>/mountinfo) to show + the mount root dentry path relative to the filesystem root. + +``show_stats`` + Optional. Called by the VFS (for /proc/<pid>/mountstats) to show + filesystem-specific mount statistics. + ``quota_read`` called by the VFS to read from filesystem quota file. ``quota_write`` called by the VFS to write to filesystem quota file. +``get_dquots`` + called by quota to get 'struct dquot' array for a particular inode. + Optional. + ``nr_cached_objects`` called by the sb cache shrinking function for the filesystem to return the number of freeable cached objects it contains. @@ -1222,7 +1289,7 @@ defined: return -ECHILD and it will be called again in ref-walk mode. -``_weak_revalidate`` +``d_weak_revalidate`` called when the VFS needs to revalidate a "jumped" dentry. This is called when a path-walk ends at dentry that was not acquired by doing a lookup in the parent directory. This includes "/", diff --git a/Documentation/filesystems/xfs-online-fsck-design.rst b/Documentation/filesystems/xfs-online-fsck-design.rst new file mode 100644 index 000000000000..791ab264b77e --- /dev/null +++ b/Documentation/filesystems/xfs-online-fsck-design.rst @@ -0,0 +1,5315 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. _xfs_online_fsck_design: + +.. + Mapping of heading styles within this document: + Heading 1 uses "====" above and below + Heading 2 uses "====" + Heading 3 uses "----" + Heading 4 uses "````" + Heading 5 uses "^^^^" + Heading 6 uses "~~~~" + Heading 7 uses "...." + + Sections are manually numbered because apparently that's what everyone + does in the kernel. + +====================== +XFS Online Fsck Design +====================== + +This document captures the design of the online filesystem check feature for +XFS. +The purpose of this document is threefold: + +- To help kernel distributors understand exactly what the XFS online fsck + feature is, and issues about which they should be aware. + +- To help people reading the code to familiarize themselves with the relevant + concepts and design points before they start digging into the code. + +- To help developers maintaining the system by capturing the reasons + supporting higher level decision making. + +As the online fsck code is merged, the links in this document to topic branches +will be replaced with links to code. + +This document is licensed under the terms of the GNU Public License, v2. +The primary author is Darrick J. Wong. + +This design document is split into seven parts. +Part 1 defines what fsck tools are and the motivations for writing a new one. +Parts 2 and 3 present a high level overview of how online fsck process works +and how it is tested to ensure correct functionality. +Part 4 discusses the user interface and the intended usage modes of the new +program. +Parts 5 and 6 show off the high level components and how they fit together, and +then present case studies of how each repair function actually works. +Part 7 sums up what has been discussed so far and speculates about what else +might be built atop online fsck. + +.. contents:: Table of Contents + :local: + +1. What is a Filesystem Check? +============================== + +A Unix filesystem has four main responsibilities: + +- Provide a hierarchy of names through which application programs can associate + arbitrary blobs of data for any length of time, + +- Virtualize physical storage media across those names, and + +- Retrieve the named data blobs at any time. + +- Examine resource usage. + +Metadata directly supporting these functions (e.g. files, directories, space +mappings) are sometimes called primary metadata. +Secondary metadata (e.g. reverse mapping and directory parent pointers) support +operations internal to the filesystem, such as internal consistency checking +and reorganization. +Summary metadata, as the name implies, condense information contained in +primary metadata for performance reasons. + +The filesystem check (fsck) tool examines all the metadata in a filesystem +to look for errors. +In addition to looking for obvious metadata corruptions, fsck also +cross-references different types of metadata records with each other to look +for inconsistencies. +People do not like losing data, so most fsck tools also contains some ability +to correct any problems found. +As a word of caution -- the primary goal of most Linux fsck tools is to restore +the filesystem metadata to a consistent state, not to maximize the data +recovered. +That precedent will not be challenged here. + +Filesystems of the 20th century generally lacked any redundancy in the ondisk +format, which means that fsck can only respond to errors by erasing files until +errors are no longer detected. +More recent filesystem designs contain enough redundancy in their metadata that +it is now possible to regenerate data structures when non-catastrophic errors +occur; this capability aids both strategies. + ++--------------------------------------------------------------------------+ +| **Note**: | ++--------------------------------------------------------------------------+ +| System administrators avoid data loss by increasing the number of | +| separate storage systems through the creation of backups; and they avoid | +| downtime by increasing the redundancy of each storage system through the | +| creation of RAID arrays. | +| fsck tools address only the first problem. | ++--------------------------------------------------------------------------+ + +TLDR; Show Me the Code! +----------------------- + +Code is posted to the kernel.org git trees as follows: +`kernel changes <https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-symlink>`_, +`userspace changes <https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=scrub-media-scan-service>`_, and +`QA test changes <https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=repair-dirs>`_. +Each kernel patchset adding an online repair function will use the same branch +name across the kernel, xfsprogs, and fstests git repos. + +Existing Tools +-------------- + +The online fsck tool described here will be the third tool in the history of +XFS (on Linux) to check and repair filesystems. +Two programs precede it: + +The first program, ``xfs_check``, was created as part of the XFS debugger +(``xfs_db``) and can only be used with unmounted filesystems. +It walks all metadata in the filesystem looking for inconsistencies in the +metadata, though it lacks any ability to repair what it finds. +Due to its high memory requirements and inability to repair things, this +program is now deprecated and will not be discussed further. + +The second program, ``xfs_repair``, was created to be faster and more robust +than the first program. +Like its predecessor, it can only be used with unmounted filesystems. +It uses extent-based in-memory data structures to reduce memory consumption, +and tries to schedule readahead IO appropriately to reduce I/O waiting time +while it scans the metadata of the entire filesystem. +The most important feature of this tool is its ability to respond to +inconsistencies in file metadata and directory tree by erasing things as needed +to eliminate problems. +Space usage metadata are rebuilt from the observed file metadata. + +Problem Statement +----------------- + +The current XFS tools leave several problems unsolved: + +1. **User programs** suddenly **lose access** to the filesystem when unexpected + shutdowns occur as a result of silent corruptions in the metadata. + These occur **unpredictably** and often without warning. + +2. **Users** experience a **total loss of service** during the recovery period + after an **unexpected shutdown** occurs. + +3. **Users** experience a **total loss of service** if the filesystem is taken + offline to **look for problems** proactively. + +4. **Data owners** cannot **check the integrity** of their stored data without + reading all of it. + This may expose them to substantial billing costs when a linear media scan + performed by the storage system administrator might suffice. + +5. **System administrators** cannot **schedule** a maintenance window to deal + with corruptions if they **lack the means** to assess filesystem health + while the filesystem is online. + +6. **Fleet monitoring tools** cannot **automate periodic checks** of filesystem + health when doing so requires **manual intervention** and downtime. + +7. **Users** can be tricked into **doing things they do not desire** when + malicious actors **exploit quirks of Unicode** to place misleading names + in directories. + +Given this definition of the problems to be solved and the actors who would +benefit, the proposed solution is a third fsck tool that acts on a running +filesystem. + +This new third program has three components: an in-kernel facility to check +metadata, an in-kernel facility to repair metadata, and a userspace driver +program to drive fsck activity on a live filesystem. +``xfs_scrub`` is the name of the driver program. +The rest of this document presents the goals and use cases of the new fsck +tool, describes its major design points in connection to those goals, and +discusses the similarities and differences with existing tools. + ++--------------------------------------------------------------------------+ +| **Note**: | ++--------------------------------------------------------------------------+ +| Throughout this document, the existing offline fsck tool can also be | +| referred to by its current name "``xfs_repair``". | +| The userspace driver program for the new online fsck tool can be | +| referred to as "``xfs_scrub``". | +| The kernel portion of online fsck that validates metadata is called | +| "online scrub", and portion of the kernel that fixes metadata is called | +| "online repair". | ++--------------------------------------------------------------------------+ + +The naming hierarchy is broken up into objects known as directories and files +and the physical space is split into pieces known as allocation groups. +Sharding enables better performance on highly parallel systems and helps to +contain the damage when corruptions occur. +The division of the filesystem into principal objects (allocation groups and +inodes) means that there are ample opportunities to perform targeted checks and +repairs on a subset of the filesystem. + +While this is going on, other parts continue processing IO requests. +Even if a piece of filesystem metadata can only be regenerated by scanning the +entire system, the scan can still be done in the background while other file +operations continue. + +In summary, online fsck takes advantage of resource sharding and redundant +metadata to enable targeted checking and repair operations while the system +is running. +This capability will be coupled to automatic system management so that +autonomous self-healing of XFS maximizes service availability. + +2. Theory of Operation +====================== + +Because it is necessary for online fsck to lock and scan live metadata objects, +online fsck consists of three separate code components. +The first is the userspace driver program ``xfs_scrub``, which is responsible +for identifying individual metadata items, scheduling work items for them, +reacting to the outcomes appropriately, and reporting results to the system +administrator. +The second and third are in the kernel, which implements functions to check +and repair each type of online fsck work item. + ++------------------------------------------------------------------+ +| **Note**: | ++------------------------------------------------------------------+ +| For brevity, this document shortens the phrase "online fsck work | +| item" to "scrub item". | ++------------------------------------------------------------------+ + +Scrub item types are delineated in a manner consistent with the Unix design +philosophy, which is to say that each item should handle one aspect of a +metadata structure, and handle it well. + +Scope +----- + +In principle, online fsck should be able to check and to repair everything that +the offline fsck program can handle. +However, online fsck cannot be running 100% of the time, which means that +latent errors may creep in after a scrub completes. +If these errors cause the next mount to fail, offline fsck is the only +solution. +This limitation means that maintenance of the offline fsck tool will continue. +A second limitation of online fsck is that it must follow the same resource +sharing and lock acquisition rules as the regular filesystem. +This means that scrub cannot take *any* shortcuts to save time, because doing +so could lead to concurrency problems. +In other words, online fsck is not a complete replacement for offline fsck, and +a complete run of online fsck may take longer than online fsck. +However, both of these limitations are acceptable tradeoffs to satisfy the +different motivations of online fsck, which are to **minimize system downtime** +and to **increase predictability of operation**. + +.. _scrubphases: + +Phases of Work +-------------- + +The userspace driver program ``xfs_scrub`` splits the work of checking and +repairing an entire filesystem into seven phases. +Each phase concentrates on checking specific types of scrub items and depends +on the success of all previous phases. +The seven phases are as follows: + +1. Collect geometry information about the mounted filesystem and computer, + discover the online fsck capabilities of the kernel, and open the + underlying storage devices. + +2. Check allocation group metadata, all realtime volume metadata, and all quota + files. + Each metadata structure is scheduled as a separate scrub item. + If corruption is found in the inode header or inode btree and ``xfs_scrub`` + is permitted to perform repairs, then those scrub items are repaired to + prepare for phase 3. + Repairs are implemented by using the information in the scrub item to + resubmit the kernel scrub call with the repair flag enabled; this is + discussed in the next section. + Optimizations and all other repairs are deferred to phase 4. + +3. Check all metadata of every file in the filesystem. + Each metadata structure is also scheduled as a separate scrub item. + If repairs are needed and ``xfs_scrub`` is permitted to perform repairs, + and there were no problems detected during phase 2, then those scrub items + are repaired immediately. + Optimizations, deferred repairs, and unsuccessful repairs are deferred to + phase 4. + +4. All remaining repairs and scheduled optimizations are performed during this + phase, if the caller permits them. + Before starting repairs, the summary counters are checked and any necessary + repairs are performed so that subsequent repairs will not fail the resource + reservation step due to wildly incorrect summary counters. + Unsuccesful repairs are requeued as long as forward progress on repairs is + made somewhere in the filesystem. + Free space in the filesystem is trimmed at the end of phase 4 if the + filesystem is clean. + +5. By the start of this phase, all primary and secondary filesystem metadata + must be correct. + Summary counters such as the free space counts and quota resource counts + are checked and corrected. + Directory entry names and extended attribute names are checked for + suspicious entries such as control characters or confusing Unicode sequences + appearing in names. + +6. If the caller asks for a media scan, read all allocated and written data + file extents in the filesystem. + The ability to use hardware-assisted data file integrity checking is new + to online fsck; neither of the previous tools have this capability. + If media errors occur, they will be mapped to the owning files and reported. + +7. Re-check the summary counters and presents the caller with a summary of + space usage and file counts. + +This allocation of responsibilities will be :ref:`revisited <scrubcheck>` +later in this document. + +Steps for Each Scrub Item +------------------------- + +The kernel scrub code uses a three-step strategy for checking and repairing +the one aspect of a metadata object represented by a scrub item: + +1. The scrub item of interest is checked for corruptions; opportunities for + optimization; and for values that are directly controlled by the system + administrator but look suspicious. + If the item is not corrupt or does not need optimization, resource are + released and the positive scan results are returned to userspace. + If the item is corrupt or could be optimized but the caller does not permit + this, resources are released and the negative scan results are returned to + userspace. + Otherwise, the kernel moves on to the second step. + +2. The repair function is called to rebuild the data structure. + Repair functions generally choose rebuild a structure from other metadata + rather than try to salvage the existing structure. + If the repair fails, the scan results from the first step are returned to + userspace. + Otherwise, the kernel moves on to the third step. + +3. In the third step, the kernel runs the same checks over the new metadata + item to assess the efficacy of the repairs. + The results of the reassessment are returned to userspace. + +Classification of Metadata +-------------------------- + +Each type of metadata object (and therefore each type of scrub item) is +classified as follows: + +Primary Metadata +```````````````` + +Metadata structures in this category should be most familiar to filesystem +users either because they are directly created by the user or they index +objects created by the user +Most filesystem objects fall into this class: + +- Free space and reference count information + +- Inode records and indexes + +- Storage mapping information for file data + +- Directories + +- Extended attributes + +- Symbolic links + +- Quota limits + +Scrub obeys the same rules as regular filesystem accesses for resource and lock +acquisition. + +Primary metadata objects are the simplest for scrub to process. +The principal filesystem object (either an allocation group or an inode) that +owns the item being scrubbed is locked to guard against concurrent updates. +The check function examines every record associated with the type for obvious +errors and cross-references healthy records against other metadata to look for +inconsistencies. +Repairs for this class of scrub item are simple, since the repair function +starts by holding all the resources acquired in the previous step. +The repair function scans available metadata as needed to record all the +observations needed to complete the structure. +Next, it stages the observations in a new ondisk structure and commits it +atomically to complete the repair. +Finally, the storage from the old data structure are carefully reaped. + +Because ``xfs_scrub`` locks a primary object for the duration of the repair, +this is effectively an offline repair operation performed on a subset of the +filesystem. +This minimizes the complexity of the repair code because it is not necessary to +handle concurrent updates from other threads, nor is it necessary to access +any other part of the filesystem. +As a result, indexed structures can be rebuilt very quickly, and programs +trying to access the damaged structure will be blocked until repairs complete. +The only infrastructure needed by the repair code are the staging area for +observations and a means to write new structures to disk. +Despite these limitations, the advantage that online repair holds is clear: +targeted work on individual shards of the filesystem avoids total loss of +service. + +This mechanism is described in section 2.1 ("Off-Line Algorithm") of +V. Srinivasan and M. J. Carey, `"Performance of On-Line Index Construction +Algorithms" <https://minds.wisconsin.edu/bitstream/handle/1793/59524/TR1047.pdf>`_, +*Extending Database Technology*, pp. 293-309, 1992. + +Most primary metadata repair functions stage their intermediate results in an +in-memory array prior to formatting the new ondisk structure, which is very +similar to the list-based algorithm discussed in section 2.3 ("List-Based +Algorithms") of Srinivasan. +However, any data structure builder that maintains a resource lock for the +duration of the repair is *always* an offline algorithm. + +.. _secondary_metadata: + +Secondary Metadata +`````````````````` + +Metadata structures in this category reflect records found in primary metadata, +but are only needed for online fsck or for reorganization of the filesystem. + +Secondary metadata include: + +- Reverse mapping information + +- Directory parent pointers + +This class of metadata is difficult for scrub to process because scrub attaches +to the secondary object but needs to check primary metadata, which runs counter +to the usual order of resource acquisition. +Frequently, this means that full filesystems scans are necessary to rebuild the +metadata. +Check functions can be limited in scope to reduce runtime. +Repairs, however, require a full scan of primary metadata, which can take a +long time to complete. +Under these conditions, ``xfs_scrub`` cannot lock resources for the entire +duration of the repair. + +Instead, repair functions set up an in-memory staging structure to store +observations. +Depending on the requirements of the specific repair function, the staging +index will either have the same format as the ondisk structure or a design +specific to that repair function. +The next step is to release all locks and start the filesystem scan. +When the repair scanner needs to record an observation, the staging data are +locked long enough to apply the update. +While the filesystem scan is in progress, the repair function hooks the +filesystem so that it can apply pending filesystem updates to the staging +information. +Once the scan is done, the owning object is re-locked, the live data is used to +write a new ondisk structure, and the repairs are committed atomically. +The hooks are disabled and the staging staging area is freed. +Finally, the storage from the old data structure are carefully reaped. + +Introducing concurrency helps online repair avoid various locking problems, but +comes at a high cost to code complexity. +Live filesystem code has to be hooked so that the repair function can observe +updates in progress. +The staging area has to become a fully functional parallel structure so that +updates can be merged from the hooks. +Finally, the hook, the filesystem scan, and the inode locking model must be +sufficiently well integrated that a hook event can decide if a given update +should be applied to the staging structure. + +In theory, the scrub implementation could apply these same techniques for +primary metadata, but doing so would make it massively more complex and less +performant. +Programs attempting to access the damaged structures are not blocked from +operation, which may cause application failure or an unplanned filesystem +shutdown. + +Inspiration for the secondary metadata repair strategy was drawn from section +2.4 of Srinivasan above, and sections 2 ("NSF: Inded Build Without Side-File") +and 3.1.1 ("Duplicate Key Insert Problem") in C. Mohan, `"Algorithms for +Creating Indexes for Very Large Tables Without Quiescing Updates" +<https://dl.acm.org/doi/10.1145/130283.130337>`_, 1992. + +The sidecar index mentioned above bears some resemblance to the side file +method mentioned in Srinivasan and Mohan. +Their method consists of an index builder that extracts relevant record data to +build the new structure as quickly as possible; and an auxiliary structure that +captures all updates that would be committed to the index by other threads were +the new index already online. +After the index building scan finishes, the updates recorded in the side file +are applied to the new index. +To avoid conflicts between the index builder and other writer threads, the +builder maintains a publicly visible cursor that tracks the progress of the +scan through the record space. +To avoid duplication of work between the side file and the index builder, side +file updates are elided when the record ID for the update is greater than the +cursor position within the record ID space. + +To minimize changes to the rest of the codebase, XFS online repair keeps the +replacement index hidden until it's completely ready to go. +In other words, there is no attempt to expose the keyspace of the new index +while repair is running. +The complexity of such an approach would be very high and perhaps more +appropriate to building *new* indices. + +**Future Work Question**: Can the full scan and live update code used to +facilitate a repair also be used to implement a comprehensive check? + +*Answer*: In theory, yes. Check would be much stronger if each scrub function +employed these live scans to build a shadow copy of the metadata and then +compared the shadow records to the ondisk records. +However, doing that is a fair amount more work than what the checking functions +do now. +The live scans and hooks were developed much later. +That in turn increases the runtime of those scrub functions. + +Summary Information +``````````````````` + +Metadata structures in this last category summarize the contents of primary +metadata records. +These are often used to speed up resource usage queries, and are many times +smaller than the primary metadata which they represent. + +Examples of summary information include: + +- Summary counts of free space and inodes + +- File link counts from directories + +- Quota resource usage counts + +Check and repair require full filesystem scans, but resource and lock +acquisition follow the same paths as regular filesystem accesses. + +The superblock summary counters have special requirements due to the underlying +implementation of the incore counters, and will be treated separately. +Check and repair of the other types of summary counters (quota resource counts +and file link counts) employ the same filesystem scanning and hooking +techniques as outlined above, but because the underlying data are sets of +integer counters, the staging data need not be a fully functional mirror of the +ondisk structure. + +Inspiration for quota and file link count repair strategies were drawn from +sections 2.12 ("Online Index Operations") through 2.14 ("Incremental View +Maintenace") of G. Graefe, `"Concurrent Queries and Updates in Summary Views +and Their Indexes" +<http://www.odbms.org/wp-content/uploads/2014/06/Increment-locks.pdf>`_, 2011. + +Since quotas are non-negative integer counts of resource usage, online +quotacheck can use the incremental view deltas described in section 2.14 to +track pending changes to the block and inode usage counts in each transaction, +and commit those changes to a dquot side file when the transaction commits. +Delta tracking is necessary for dquots because the index builder scans inodes, +whereas the data structure being rebuilt is an index of dquots. +Link count checking combines the view deltas and commit step into one because +it sets attributes of the objects being scanned instead of writing them to a +separate data structure. +Each online fsck function will be discussed as case studies later in this +document. + +Risk Management +--------------- + +During the development of online fsck, several risk factors were identified +that may make the feature unsuitable for certain distributors and users. +Steps can be taken to mitigate or eliminate those risks, though at a cost to +functionality. + +- **Decreased performance**: Adding metadata indices to the filesystem + increases the time cost of persisting changes to disk, and the reverse space + mapping and directory parent pointers are no exception. + System administrators who require the maximum performance can disable the + reverse mapping features at format time, though this choice dramatically + reduces the ability of online fsck to find inconsistencies and repair them. + +- **Incorrect repairs**: As with all software, there might be defects in the + software that result in incorrect repairs being written to the filesystem. + Systematic fuzz testing (detailed in the next section) is employed by the + authors to find bugs early, but it might not catch everything. + The kernel build system provides Kconfig options (``CONFIG_XFS_ONLINE_SCRUB`` + and ``CONFIG_XFS_ONLINE_REPAIR``) to enable distributors to choose not to + accept this risk. + The xfsprogs build system has a configure option (``--enable-scrub=no``) that + disables building of the ``xfs_scrub`` binary, though this is not a risk + mitigation if the kernel functionality remains enabled. + +- **Inability to repair**: Sometimes, a filesystem is too badly damaged to be + repairable. + If the keyspaces of several metadata indices overlap in some manner but a + coherent narrative cannot be formed from records collected, then the repair + fails. + To reduce the chance that a repair will fail with a dirty transaction and + render the filesystem unusable, the online repair functions have been + designed to stage and validate all new records before committing the new + structure. + +- **Misbehavior**: Online fsck requires many privileges -- raw IO to block + devices, opening files by handle, ignoring Unix discretionary access control, + and the ability to perform administrative changes. + Running this automatically in the background scares people, so the systemd + background service is configured to run with only the privileges required. + Obviously, this cannot address certain problems like the kernel crashing or + deadlocking, but it should be sufficient to prevent the scrub process from + escaping and reconfiguring the system. + The cron job does not have this protection. + +- **Fuzz Kiddiez**: There are many people now who seem to think that running + automated fuzz testing of ondisk artifacts to find mischevious behavior and + spraying exploit code onto the public mailing list for instant zero-day + disclosure is somehow of some social benefit. + In the view of this author, the benefit is realized only when the fuzz + operators help to **fix** the flaws, but this opinion apparently is not + widely shared among security "researchers". + The XFS maintainers' continuing ability to manage these events presents an + ongoing risk to the stability of the development process. + Automated testing should front-load some of the risk while the feature is + considered EXPERIMENTAL. + +Many of these risks are inherent to software programming. +Despite this, it is hoped that this new functionality will prove useful in +reducing unexpected downtime. + +3. Testing Plan +=============== + +As stated before, fsck tools have three main goals: + +1. Detect inconsistencies in the metadata; + +2. Eliminate those inconsistencies; and + +3. Minimize further loss of data. + +Demonstrations of correct operation are necessary to build users' confidence +that the software behaves within expectations. +Unfortunately, it was not really feasible to perform regular exhaustive testing +of every aspect of a fsck tool until the introduction of low-cost virtual +machines with high-IOPS storage. +With ample hardware availability in mind, the testing strategy for the online +fsck project involves differential analysis against the existing fsck tools and +systematic testing of every attribute of every type of metadata object. +Testing can be split into four major categories, as discussed below. + +Integrated Testing with fstests +------------------------------- + +The primary goal of any free software QA effort is to make testing as +inexpensive and widespread as possible to maximize the scaling advantages of +community. +In other words, testing should maximize the breadth of filesystem configuration +scenarios and hardware setups. +This improves code quality by enabling the authors of online fsck to find and +fix bugs early, and helps developers of new features to find integration +issues earlier in their development effort. + +The Linux filesystem community shares a common QA testing suite, +`fstests <https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/>`_, for +functional and regression testing. +Even before development work began on online fsck, fstests (when run on XFS) +would run both the ``xfs_check`` and ``xfs_repair -n`` commands on the test and +scratch filesystems between each test. +This provides a level of assurance that the kernel and the fsck tools stay in +alignment about what constitutes consistent metadata. +During development of the online checking code, fstests was modified to run +``xfs_scrub -n`` between each test to ensure that the new checking code +produces the same results as the two existing fsck tools. + +To start development of online repair, fstests was modified to run +``xfs_repair`` to rebuild the filesystem's metadata indices between tests. +This ensures that offline repair does not crash, leave a corrupt filesystem +after it exists, or trigger complaints from the online check. +This also established a baseline for what can and cannot be repaired offline. +To complete the first phase of development of online repair, fstests was +modified to be able to run ``xfs_scrub`` in a "force rebuild" mode. +This enables a comparison of the effectiveness of online repair as compared to +the existing offline repair tools. + +General Fuzz Testing of Metadata Blocks +--------------------------------------- + +XFS benefits greatly from having a very robust debugging tool, ``xfs_db``. + +Before development of online fsck even began, a set of fstests were created +to test the rather common fault that entire metadata blocks get corrupted. +This required the creation of fstests library code that can create a filesystem +containing every possible type of metadata object. +Next, individual test cases were created to create a test filesystem, identify +a single block of a specific type of metadata object, trash it with the +existing ``blocktrash`` command in ``xfs_db``, and test the reaction of a +particular metadata validation strategy. + +This earlier test suite enabled XFS developers to test the ability of the +in-kernel validation functions and the ability of the offline fsck tool to +detect and eliminate the inconsistent metadata. +This part of the test suite was extended to cover online fsck in exactly the +same manner. + +In other words, for a given fstests filesystem configuration: + +* For each metadata object existing on the filesystem: + + * Write garbage to it + + * Test the reactions of: + + 1. The kernel verifiers to stop obviously bad metadata + 2. Offline repair (``xfs_repair``) to detect and fix + 3. Online repair (``xfs_scrub``) to detect and fix + +Targeted Fuzz Testing of Metadata Records +----------------------------------------- + +The testing plan for online fsck includes extending the existing fs testing +infrastructure to provide a much more powerful facility: targeted fuzz testing +of every metadata field of every metadata object in the filesystem. +``xfs_db`` can modify every field of every metadata structure in every +block in the filesystem to simulate the effects of memory corruption and +software bugs. +Given that fstests already contains the ability to create a filesystem +containing every metadata format known to the filesystem, ``xfs_db`` can be +used to perform exhaustive fuzz testing! + +For a given fstests filesystem configuration: + +* For each metadata object existing on the filesystem... + + * For each record inside that metadata object... + + * For each field inside that record... + + * For each conceivable type of transformation that can be applied to a bit field... + + 1. Clear all bits + 2. Set all bits + 3. Toggle the most significant bit + 4. Toggle the middle bit + 5. Toggle the least significant bit + 6. Add a small quantity + 7. Subtract a small quantity + 8. Randomize the contents + + * ...test the reactions of: + + 1. The kernel verifiers to stop obviously bad metadata + 2. Offline checking (``xfs_repair -n``) + 3. Offline repair (``xfs_repair``) + 4. Online checking (``xfs_scrub -n``) + 5. Online repair (``xfs_scrub``) + 6. Both repair tools (``xfs_scrub`` and then ``xfs_repair`` if online repair doesn't succeed) + +This is quite the combinatoric explosion! + +Fortunately, having this much test coverage makes it easy for XFS developers to +check the responses of XFS' fsck tools. +Since the introduction of the fuzz testing framework, these tests have been +used to discover incorrect repair code and missing functionality for entire +classes of metadata objects in ``xfs_repair``. +The enhanced testing was used to finalize the deprecation of ``xfs_check`` by +confirming that ``xfs_repair`` could detect at least as many corruptions as +the older tool. + +These tests have been very valuable for ``xfs_scrub`` in the same ways -- they +allow the online fsck developers to compare online fsck against offline fsck, +and they enable XFS developers to find deficiencies in the code base. + +Proposed patchsets include +`general fuzzer improvements +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=fuzzer-improvements>`_, +`fuzzing baselines +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=fuzz-baseline>`_, +and `improvements in fuzz testing comprehensiveness +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=more-fuzz-testing>`_. + +Stress Testing +-------------- + +A unique requirement to online fsck is the ability to operate on a filesystem +concurrently with regular workloads. +Although it is of course impossible to run ``xfs_scrub`` with *zero* observable +impact on the running system, the online repair code should never introduce +inconsistencies into the filesystem metadata, and regular workloads should +never notice resource starvation. +To verify that these conditions are being met, fstests has been enhanced in +the following ways: + +* For each scrub item type, create a test to exercise checking that item type + while running ``fsstress``. +* For each scrub item type, create a test to exercise repairing that item type + while running ``fsstress``. +* Race ``fsstress`` and ``xfs_scrub -n`` to ensure that checking the whole + filesystem doesn't cause problems. +* Race ``fsstress`` and ``xfs_scrub`` in force-rebuild mode to ensure that + force-repairing the whole filesystem doesn't cause problems. +* Race ``xfs_scrub`` in check and force-repair mode against ``fsstress`` while + freezing and thawing the filesystem. +* Race ``xfs_scrub`` in check and force-repair mode against ``fsstress`` while + remounting the filesystem read-only and read-write. +* The same, but running ``fsx`` instead of ``fsstress``. (Not done yet?) + +Success is defined by the ability to run all of these tests without observing +any unexpected filesystem shutdowns due to corrupted metadata, kernel hang +check warnings, or any other sort of mischief. + +Proposed patchsets include `general stress testing +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=race-scrub-and-mount-state-changes>`_ +and the `evolution of existing per-function stress testing +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=refactor-scrub-stress>`_. + +4. User Interface +================= + +The primary user of online fsck is the system administrator, just like offline +repair. +Online fsck presents two modes of operation to administrators: +A foreground CLI process for online fsck on demand, and a background service +that performs autonomous checking and repair. + +Checking on Demand +------------------ + +For administrators who want the absolute freshest information about the +metadata in a filesystem, ``xfs_scrub`` can be run as a foreground process on +a command line. +The program checks every piece of metadata in the filesystem while the +administrator waits for the results to be reported, just like the existing +``xfs_repair`` tool. +Both tools share a ``-n`` option to perform a read-only scan, and a ``-v`` +option to increase the verbosity of the information reported. + +A new feature of ``xfs_scrub`` is the ``-x`` option, which employs the error +correction capabilities of the hardware to check data file contents. +The media scan is not enabled by default because it may dramatically increase +program runtime and consume a lot of bandwidth on older storage hardware. + +The output of a foreground invocation is captured in the system log. + +The ``xfs_scrub_all`` program walks the list of mounted filesystems and +initiates ``xfs_scrub`` for each of them in parallel. +It serializes scans for any filesystems that resolve to the same top level +kernel block device to prevent resource overconsumption. + +Background Service +------------------ + +To reduce the workload of system administrators, the ``xfs_scrub`` package +provides a suite of `systemd <https://systemd.io/>`_ timers and services that +run online fsck automatically on weekends by default. +The background service configures scrub to run with as little privilege as +possible, the lowest CPU and IO priority, and in a CPU-constrained single +threaded mode. +This can be tuned by the systemd administrator at any time to suit the latency +and throughput requirements of customer workloads. + +The output of the background service is also captured in the system log. +If desired, reports of failures (either due to inconsistencies or mere runtime +errors) can be emailed automatically by setting the ``EMAIL_ADDR`` environment +variable in the following service files: + +* ``xfs_scrub_fail@.service`` +* ``xfs_scrub_media_fail@.service`` +* ``xfs_scrub_all_fail.service`` + +The decision to enable the background scan is left to the system administrator. +This can be done by enabling either of the following services: + +* ``xfs_scrub_all.timer`` on systemd systems +* ``xfs_scrub_all.cron`` on non-systemd systems + +This automatic weekly scan is configured out of the box to perform an +additional media scan of all file data once per month. +This is less foolproof than, say, storing file data block checksums, but much +more performant if application software provides its own integrity checking, +redundancy can be provided elsewhere above the filesystem, or the storage +device's integrity guarantees are deemed sufficient. + +The systemd unit file definitions have been subjected to a security audit +(as of systemd 249) to ensure that the xfs_scrub processes have as little +access to the rest of the system as possible. +This was performed via ``systemd-analyze security``, after which privileges +were restricted to the minimum required, sandboxing was set up to the maximal +extent possible with sandboxing and system call filtering; and access to the +filesystem tree was restricted to the minimum needed to start the program and +access the filesystem being scanned. +The service definition files restrict CPU usage to 80% of one CPU core, and +apply as nice of a priority to IO and CPU scheduling as possible. +This measure was taken to minimize delays in the rest of the filesystem. +No such hardening has been performed for the cron job. + +Proposed patchset: +`Enabling the xfs_scrub background service +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=scrub-media-scan-service>`_. + +Health Reporting +---------------- + +XFS caches a summary of each filesystem's health status in memory. +The information is updated whenever ``xfs_scrub`` is run, or whenever +inconsistencies are detected in the filesystem metadata during regular +operations. +System administrators should use the ``health`` command of ``xfs_spaceman`` to +download this information into a human-readable format. +If problems have been observed, the administrator can schedule a reduced +service window to run the online repair tool to correct the problem. +Failing that, the administrator can decide to schedule a maintenance window to +run the traditional offline repair tool to correct the problem. + +**Future Work Question**: Should the health reporting integrate with the new +inotify fs error notification system? +Would it be helpful for sysadmins to have a daemon to listen for corruption +notifications and initiate a repair? + +*Answer*: These questions remain unanswered, but should be a part of the +conversation with early adopters and potential downstream users of XFS. + +Proposed patchsets include +`wiring up health reports to correction returns +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=corruption-health-reports>`_ +and +`preservation of sickness info during memory reclaim +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=indirect-health-reporting>`_. + +5. Kernel Algorithms and Data Structures +======================================== + +This section discusses the key algorithms and data structures of the kernel +code that provide the ability to check and repair metadata while the system +is running. +The first chapters in this section reveal the pieces that provide the +foundation for checking metadata. +The remainder of this section presents the mechanisms through which XFS +regenerates itself. + +Self Describing Metadata +------------------------ + +Starting with XFS version 5 in 2012, XFS updated the format of nearly every +ondisk block header to record a magic number, a checksum, a universally +"unique" identifier (UUID), an owner code, the ondisk address of the block, +and a log sequence number. +When loading a block buffer from disk, the magic number, UUID, owner, and +ondisk address confirm that the retrieved block matches the specific owner of +the current filesystem, and that the information contained in the block is +supposed to be found at the ondisk address. +The first three components enable checking tools to disregard alleged metadata +that doesn't belong to the filesystem, and the fourth component enables the +filesystem to detect lost writes. + +Whenever a file system operation modifies a block, the change is submitted +to the log as part of a transaction. +The log then processes these transactions marking them done once they are +safely persisted to storage. +The logging code maintains the checksum and the log sequence number of the last +transactional update. +Checksums are useful for detecting torn writes and other discrepancies that can +be introduced between the computer and its storage devices. +Sequence number tracking enables log recovery to avoid applying out of date +log updates to the filesystem. + +These two features improve overall runtime resiliency by providing a means for +the filesystem to detect obvious corruption when reading metadata blocks from +disk, but these buffer verifiers cannot provide any consistency checking +between metadata structures. + +For more information, please see the documentation for +Documentation/filesystems/xfs-self-describing-metadata.rst + +Reverse Mapping +--------------- + +The original design of XFS (circa 1993) is an improvement upon 1980s Unix +filesystem design. +In those days, storage density was expensive, CPU time was scarce, and +excessive seek time could kill performance. +For performance reasons, filesystem authors were reluctant to add redundancy to +the filesystem, even at the cost of data integrity. +Filesystems designers in the early 21st century choose different strategies to +increase internal redundancy -- either storing nearly identical copies of +metadata, or more space-efficient encoding techniques. + +For XFS, a different redundancy strategy was chosen to modernize the design: +a secondary space usage index that maps allocated disk extents back to their +owners. +By adding a new index, the filesystem retains most of its ability to scale +well to heavily threaded workloads involving large datasets, since the primary +file metadata (the directory tree, the file block map, and the allocation +groups) remain unchanged. +Like any system that improves redundancy, the reverse-mapping feature increases +overhead costs for space mapping activities. +However, it has two critical advantages: first, the reverse index is key to +enabling online fsck and other requested functionality such as free space +defragmentation, better media failure reporting, and filesystem shrinking. +Second, the different ondisk storage format of the reverse mapping btree +defeats device-level deduplication because the filesystem requires real +redundancy. + ++--------------------------------------------------------------------------+ +| **Sidebar**: | ++--------------------------------------------------------------------------+ +| A criticism of adding the secondary index is that it does nothing to | +| improve the robustness of user data storage itself. | +| This is a valid point, but adding a new index for file data block | +| checksums increases write amplification by turning data overwrites into | +| copy-writes, which age the filesystem prematurely. | +| In keeping with thirty years of precedent, users who want file data | +| integrity can supply as powerful a solution as they require. | +| As for metadata, the complexity of adding a new secondary index of space | +| usage is much less than adding volume management and storage device | +| mirroring to XFS itself. | +| Perfection of RAID and volume management are best left to existing | +| layers in the kernel. | ++--------------------------------------------------------------------------+ + +The information captured in a reverse space mapping record is as follows: + +.. code-block:: c + + struct xfs_rmap_irec { + xfs_agblock_t rm_startblock; /* extent start block */ + xfs_extlen_t rm_blockcount; /* extent length */ + uint64_t rm_owner; /* extent owner */ + uint64_t rm_offset; /* offset within the owner */ + unsigned int rm_flags; /* state flags */ + }; + +The first two fields capture the location and size of the physical space, +in units of filesystem blocks. +The owner field tells scrub which metadata structure or file inode have been +assigned this space. +For space allocated to files, the offset field tells scrub where the space was +mapped within the file fork. +Finally, the flags field provides extra information about the space usage -- +is this an attribute fork extent? A file mapping btree extent? Or an +unwritten data extent? + +Online filesystem checking judges the consistency of each primary metadata +record by comparing its information against all other space indices. +The reverse mapping index plays a key role in the consistency checking process +because it contains a centralized alternate copy of all space allocation +information. +Program runtime and ease of resource acquisition are the only real limits to +what online checking can consult. +For example, a file data extent mapping can be checked against: + +* The absence of an entry in the free space information. +* The absence of an entry in the inode index. +* The absence of an entry in the reference count data if the file is not + marked as having shared extents. +* The correspondence of an entry in the reverse mapping information. + +There are several observations to make about reverse mapping indices: + +1. Reverse mappings can provide a positive affirmation of correctness if any of + the above primary metadata are in doubt. + The checking code for most primary metadata follows a path similar to the + one outlined above. + +2. Proving the consistency of secondary metadata with the primary metadata is + difficult because that requires a full scan of all primary space metadata, + which is very time intensive. + For example, checking a reverse mapping record for a file extent mapping + btree block requires locking the file and searching the entire btree to + confirm the block. + Instead, scrub relies on rigorous cross-referencing during the primary space + mapping structure checks. + +3. Consistency scans must use non-blocking lock acquisition primitives if the + required locking order is not the same order used by regular filesystem + operations. + For example, if the filesystem normally takes a file ILOCK before taking + the AGF buffer lock but scrub wants to take a file ILOCK while holding + an AGF buffer lock, scrub cannot block on that second acquisition. + This means that forward progress during this part of a scan of the reverse + mapping data cannot be guaranteed if system load is heavy. + +In summary, reverse mappings play a key role in reconstruction of primary +metadata. +The details of how these records are staged, written to disk, and committed +into the filesystem are covered in subsequent sections. + +Checking and Cross-Referencing +------------------------------ + +The first step of checking a metadata structure is to examine every record +contained within the structure and its relationship with the rest of the +system. +XFS contains multiple layers of checking to try to prevent inconsistent +metadata from wreaking havoc on the system. +Each of these layers contributes information that helps the kernel to make +three decisions about the health of a metadata structure: + +- Is a part of this structure obviously corrupt (``XFS_SCRUB_OFLAG_CORRUPT``) ? +- Is this structure inconsistent with the rest of the system + (``XFS_SCRUB_OFLAG_XCORRUPT``) ? +- Is there so much damage around the filesystem that cross-referencing is not + possible (``XFS_SCRUB_OFLAG_XFAIL``) ? +- Can the structure be optimized to improve performance or reduce the size of + metadata (``XFS_SCRUB_OFLAG_PREEN``) ? +- Does the structure contain data that is not inconsistent but deserves review + by the system administrator (``XFS_SCRUB_OFLAG_WARNING``) ? + +The following sections describe how the metadata scrubbing process works. + +Metadata Buffer Verification +```````````````````````````` + +The lowest layer of metadata protection in XFS are the metadata verifiers built +into the buffer cache. +These functions perform inexpensive internal consistency checking of the block +itself, and answer these questions: + +- Does the block belong to this filesystem? + +- Does the block belong to the structure that asked for the read? + This assumes that metadata blocks only have one owner, which is always true + in XFS. + +- Is the type of data stored in the block within a reasonable range of what + scrub is expecting? + +- Does the physical location of the block match the location it was read from? + +- Does the block checksum match the data? + +The scope of the protections here are very limited -- verifiers can only +establish that the filesystem code is reasonably free of gross corruption bugs +and that the storage system is reasonably competent at retrieval. +Corruption problems observed at runtime cause the generation of health reports, +failed system calls, and in the extreme case, filesystem shutdowns if the +corrupt metadata force the cancellation of a dirty transaction. + +Every online fsck scrubbing function is expected to read every ondisk metadata +block of a structure in the course of checking the structure. +Corruption problems observed during a check are immediately reported to +userspace as corruption; during a cross-reference, they are reported as a +failure to cross-reference once the full examination is complete. +Reads satisfied by a buffer already in cache (and hence already verified) +bypass these checks. + +Internal Consistency Checks +``````````````````````````` + +After the buffer cache, the next level of metadata protection is the internal +record verification code built into the filesystem. +These checks are split between the buffer verifiers, the in-filesystem users of +the buffer cache, and the scrub code itself, depending on the amount of higher +level context required. +The scope of checking is still internal to the block. +These higher level checking functions answer these questions: + +- Does the type of data stored in the block match what scrub is expecting? + +- Does the block belong to the owning structure that asked for the read? + +- If the block contains records, do the records fit within the block? + +- If the block tracks internal free space information, is it consistent with + the record areas? + +- Are the records contained inside the block free of obvious corruptions? + +Record checks in this category are more rigorous and more time-intensive. +For example, block pointers and inumbers are checked to ensure that they point +within the dynamically allocated parts of an allocation group and within +the filesystem. +Names are checked for invalid characters, and flags are checked for invalid +combinations. +Other record attributes are checked for sensible values. +Btree records spanning an interval of the btree keyspace are checked for +correct order and lack of mergeability (except for file fork mappings). +For performance reasons, regular code may skip some of these checks unless +debugging is enabled or a write is about to occur. +Scrub functions, of course, must check all possible problems. + +Validation of Userspace-Controlled Record Attributes +```````````````````````````````````````````````````` + +Various pieces of filesystem metadata are directly controlled by userspace. +Because of this nature, validation work cannot be more precise than checking +that a value is within the possible range. +These fields include: + +- Superblock fields controlled by mount options +- Filesystem labels +- File timestamps +- File permissions +- File size +- File flags +- Names present in directory entries, extended attribute keys, and filesystem + labels +- Extended attribute key namespaces +- Extended attribute values +- File data block contents +- Quota limits +- Quota timer expiration (if resource usage exceeds the soft limit) + +Cross-Referencing Space Metadata +```````````````````````````````` + +After internal block checks, the next higher level of checking is +cross-referencing records between metadata structures. +For regular runtime code, the cost of these checks is considered to be +prohibitively expensive, but as scrub is dedicated to rooting out +inconsistencies, it must pursue all avenues of inquiry. +The exact set of cross-referencing is highly dependent on the context of the +data structure being checked. + +The XFS btree code has keyspace scanning functions that online fsck uses to +cross reference one structure with another. +Specifically, scrub can scan the key space of an index to determine if that +keyspace is fully, sparsely, or not at all mapped to records. +For the reverse mapping btree, it is possible to mask parts of the key for the +purposes of performing a keyspace scan so that scrub can decide if the rmap +btree contains records mapping a certain extent of physical space without the +sparsenses of the rest of the rmap keyspace getting in the way. + +Btree blocks undergo the following checks before cross-referencing: + +- Does the type of data stored in the block match what scrub is expecting? + +- Does the block belong to the owning structure that asked for the read? + +- Do the records fit within the block? + +- Are the records contained inside the block free of obvious corruptions? + +- Are the name hashes in the correct order? + +- Do node pointers within the btree point to valid block addresses for the type + of btree? + +- Do child pointers point towards the leaves? + +- Do sibling pointers point across the same level? + +- For each node block record, does the record key accurate reflect the contents + of the child block? + +Space allocation records are cross-referenced as follows: + +1. Any space mentioned by any metadata structure are cross-referenced as + follows: + + - Does the reverse mapping index list only the appropriate owner as the + owner of each block? + + - Are none of the blocks claimed as free space? + + - If these aren't file data blocks, are none of the blocks claimed as space + shared by different owners? + +2. Btree blocks are cross-referenced as follows: + + - Everything in class 1 above. + + - If there's a parent node block, do the keys listed for this block match the + keyspace of this block? + + - Do the sibling pointers point to valid blocks? Of the same level? + + - Do the child pointers point to valid blocks? Of the next level down? + +3. Free space btree records are cross-referenced as follows: + + - Everything in class 1 and 2 above. + + - Does the reverse mapping index list no owners of this space? + + - Is this space not claimed by the inode index for inodes? + + - Is it not mentioned by the reference count index? + + - Is there a matching record in the other free space btree? + +4. Inode btree records are cross-referenced as follows: + + - Everything in class 1 and 2 above. + + - Is there a matching record in free inode btree? + + - Do cleared bits in the holemask correspond with inode clusters? + + - Do set bits in the freemask correspond with inode records with zero link + count? + +5. Inode records are cross-referenced as follows: + + - Everything in class 1. + + - Do all the fields that summarize information about the file forks actually + match those forks? + + - Does each inode with zero link count correspond to a record in the free + inode btree? + +6. File fork space mapping records are cross-referenced as follows: + + - Everything in class 1 and 2 above. + + - Is this space not mentioned by the inode btrees? + + - If this is a CoW fork mapping, does it correspond to a CoW entry in the + reference count btree? + +7. Reference count records are cross-referenced as follows: + + - Everything in class 1 and 2 above. + + - Within the space subkeyspace of the rmap btree (that is to say, all + records mapped to a particular space extent and ignoring the owner info), + are there the same number of reverse mapping records for each block as the + reference count record claims? + +Proposed patchsets are the series to find gaps in +`refcount btree +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-detect-refcount-gaps>`_, +`inode btree +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-detect-inobt-gaps>`_, and +`rmap btree +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-detect-rmapbt-gaps>`_ records; +to find +`mergeable records +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-detect-mergeable-records>`_; +and to +`improve cross referencing with rmap +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-strengthen-rmap-checking>`_ +before starting a repair. + +Checking Extended Attributes +```````````````````````````` + +Extended attributes implement a key-value store that enable fragments of data +to be attached to any file. +Both the kernel and userspace can access the keys and values, subject to +namespace and privilege restrictions. +Most typically these fragments are metadata about the file -- origins, security +contexts, user-supplied labels, indexing information, etc. + +Names can be as long as 255 bytes and can exist in several different +namespaces. +Values can be as large as 64KB. +A file's extended attributes are stored in blocks mapped by the attr fork. +The mappings point to leaf blocks, remote value blocks, or dabtree blocks. +Block 0 in the attribute fork is always the top of the structure, but otherwise +each of the three types of blocks can be found at any offset in the attr fork. +Leaf blocks contain attribute key records that point to the name and the value. +Names are always stored elsewhere in the same leaf block. +Values that are less than 3/4 the size of a filesystem block are also stored +elsewhere in the same leaf block. +Remote value blocks contain values that are too large to fit inside a leaf. +If the leaf information exceeds a single filesystem block, a dabtree (also +rooted at block 0) is created to map hashes of the attribute names to leaf +blocks in the attr fork. + +Checking an extended attribute structure is not so straightfoward due to the +lack of separation between attr blocks and index blocks. +Scrub must read each block mapped by the attr fork and ignore the non-leaf +blocks: + +1. Walk the dabtree in the attr fork (if present) to ensure that there are no + irregularities in the blocks or dabtree mappings that do not point to + attr leaf blocks. + +2. Walk the blocks of the attr fork looking for leaf blocks. + For each entry inside a leaf: + + a. Validate that the name does not contain invalid characters. + + b. Read the attr value. + This performs a named lookup of the attr name to ensure the correctness + of the dabtree. + If the value is stored in a remote block, this also validates the + integrity of the remote value block. + +Checking and Cross-Referencing Directories +`````````````````````````````````````````` + +The filesystem directory tree is a directed acylic graph structure, with files +constituting the nodes, and directory entries (dirents) constituting the edges. +Directories are a special type of file containing a set of mappings from a +255-byte sequence (name) to an inumber. +These are called directory entries, or dirents for short. +Each directory file must have exactly one directory pointing to the file. +A root directory points to itself. +Directory entries point to files of any type. +Each non-directory file may have multiple directories point to it. + +In XFS, directories are implemented as a file containing up to three 32GB +partitions. +The first partition contains directory entry data blocks. +Each data block contains variable-sized records associating a user-provided +name with an inumber and, optionally, a file type. +If the directory entry data grows beyond one block, the second partition (which +exists as post-EOF extents) is populated with a block containing free space +information and an index that maps hashes of the dirent names to directory data +blocks in the first partition. +This makes directory name lookups very fast. +If this second partition grows beyond one block, the third partition is +populated with a linear array of free space information for faster +expansions. +If the free space has been separated and the second partition grows again +beyond one block, then a dabtree is used to map hashes of dirent names to +directory data blocks. + +Checking a directory is pretty straightfoward: + +1. Walk the dabtree in the second partition (if present) to ensure that there + are no irregularities in the blocks or dabtree mappings that do not point to + dirent blocks. + +2. Walk the blocks of the first partition looking for directory entries. + Each dirent is checked as follows: + + a. Does the name contain no invalid characters? + + b. Does the inumber correspond to an actual, allocated inode? + + c. Does the child inode have a nonzero link count? + + d. If a file type is included in the dirent, does it match the type of the + inode? + + e. If the child is a subdirectory, does the child's dotdot pointer point + back to the parent? + + f. If the directory has a second partition, perform a named lookup of the + dirent name to ensure the correctness of the dabtree. + +3. Walk the free space list in the third partition (if present) to ensure that + the free spaces it describes are really unused. + +Checking operations involving :ref:`parents <dirparent>` and +:ref:`file link counts <nlinks>` are discussed in more detail in later +sections. + +Checking Directory/Attribute Btrees +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +As stated in previous sections, the directory/attribute btree (dabtree) index +maps user-provided names to improve lookup times by avoiding linear scans. +Internally, it maps a 32-bit hash of the name to a block offset within the +appropriate file fork. + +The internal structure of a dabtree closely resembles the btrees that record +fixed-size metadata records -- each dabtree block contains a magic number, a +checksum, sibling pointers, a UUID, a tree level, and a log sequence number. +The format of leaf and node records are the same -- each entry points to the +next level down in the hierarchy, with dabtree node records pointing to dabtree +leaf blocks, and dabtree leaf records pointing to non-dabtree blocks elsewhere +in the fork. + +Checking and cross-referencing the dabtree is very similar to what is done for +space btrees: + +- Does the type of data stored in the block match what scrub is expecting? + +- Does the block belong to the owning structure that asked for the read? + +- Do the records fit within the block? + +- Are the records contained inside the block free of obvious corruptions? + +- Are the name hashes in the correct order? + +- Do node pointers within the dabtree point to valid fork offsets for dabtree + blocks? + +- Do leaf pointers within the dabtree point to valid fork offsets for directory + or attr leaf blocks? + +- Do child pointers point towards the leaves? + +- Do sibling pointers point across the same level? + +- For each dabtree node record, does the record key accurate reflect the + contents of the child dabtree block? + +- For each dabtree leaf record, does the record key accurate reflect the + contents of the directory or attr block? + +Cross-Referencing Summary Counters +`````````````````````````````````` + +XFS maintains three classes of summary counters: available resources, quota +resource usage, and file link counts. + +In theory, the amount of available resources (data blocks, inodes, realtime +extents) can be found by walking the entire filesystem. +This would make for very slow reporting, so a transactional filesystem can +maintain summaries of this information in the superblock. +Cross-referencing these values against the filesystem metadata should be a +simple matter of walking the free space and inode metadata in each AG and the +realtime bitmap, but there are complications that will be discussed in +:ref:`more detail <fscounters>` later. + +:ref:`Quota usage <quotacheck>` and :ref:`file link count <nlinks>` +checking are sufficiently complicated to warrant separate sections. + +Post-Repair Reverification +`````````````````````````` + +After performing a repair, the checking code is run a second time to validate +the new structure, and the results of the health assessment are recorded +internally and returned to the calling process. +This step is critical for enabling system administrator to monitor the status +of the filesystem and the progress of any repairs. +For developers, it is a useful means to judge the efficacy of error detection +and correction in the online and offline checking tools. + +Eventual Consistency vs. Online Fsck +------------------------------------ + +Complex operations can make modifications to multiple per-AG data structures +with a chain of transactions. +These chains, once committed to the log, are restarted during log recovery if +the system crashes while processing the chain. +Because the AG header buffers are unlocked between transactions within a chain, +online checking must coordinate with chained operations that are in progress to +avoid incorrectly detecting inconsistencies due to pending chains. +Furthermore, online repair must not run when operations are pending because +the metadata are temporarily inconsistent with each other, and rebuilding is +not possible. + +Only online fsck has this requirement of total consistency of AG metadata, and +should be relatively rare as compared to filesystem change operations. +Online fsck coordinates with transaction chains as follows: + +* For each AG, maintain a count of intent items targetting that AG. + The count should be bumped whenever a new item is added to the chain. + The count should be dropped when the filesystem has locked the AG header + buffers and finished the work. + +* When online fsck wants to examine an AG, it should lock the AG header + buffers to quiesce all transaction chains that want to modify that AG. + If the count is zero, proceed with the checking operation. + If it is nonzero, cycle the buffer locks to allow the chain to make forward + progress. + +This may lead to online fsck taking a long time to complete, but regular +filesystem updates take precedence over background checking activity. +Details about the discovery of this situation are presented in the +:ref:`next section <chain_coordination>`, and details about the solution +are presented :ref:`after that<intent_drains>`. + +.. _chain_coordination: + +Discovery of the Problem +```````````````````````` + +Midway through the development of online scrubbing, the fsstress tests +uncovered a misinteraction between online fsck and compound transaction chains +created by other writer threads that resulted in false reports of metadata +inconsistency. +The root cause of these reports is the eventual consistency model introduced by +the expansion of deferred work items and compound transaction chains when +reverse mapping and reflink were introduced. + +Originally, transaction chains were added to XFS to avoid deadlocks when +unmapping space from files. +Deadlock avoidance rules require that AGs only be locked in increasing order, +which makes it impossible (say) to use a single transaction to free a space +extent in AG 7 and then try to free a now superfluous block mapping btree block +in AG 3. +To avoid these kinds of deadlocks, XFS creates Extent Freeing Intent (EFI) log +items to commit to freeing some space in one transaction while deferring the +actual metadata updates to a fresh transaction. +The transaction sequence looks like this: + +1. The first transaction contains a physical update to the file's block mapping + structures to remove the mapping from the btree blocks. + It then attaches to the in-memory transaction an action item to schedule + deferred freeing of space. + Concretely, each transaction maintains a list of ``struct + xfs_defer_pending`` objects, each of which maintains a list of ``struct + xfs_extent_free_item`` objects. + Returning to the example above, the action item tracks the freeing of both + the unmapped space from AG 7 and the block mapping btree (BMBT) block from + AG 3. + Deferred frees recorded in this manner are committed in the log by creating + an EFI log item from the ``struct xfs_extent_free_item`` object and + attaching the log item to the transaction. + When the log is persisted to disk, the EFI item is written into the ondisk + transaction record. + EFIs can list up to 16 extents to free, all sorted in AG order. + +2. The second transaction contains a physical update to the free space btrees + of AG 3 to release the former BMBT block and a second physical update to the + free space btrees of AG 7 to release the unmapped file space. + Observe that the the physical updates are resequenced in the correct order + when possible. + Attached to the transaction is a an extent free done (EFD) log item. + The EFD contains a pointer to the EFI logged in transaction #1 so that log + recovery can tell if the EFI needs to be replayed. + +If the system goes down after transaction #1 is written back to the filesystem +but before #2 is committed, a scan of the filesystem metadata would show +inconsistent filesystem metadata because there would not appear to be any owner +of the unmapped space. +Happily, log recovery corrects this inconsistency for us -- when recovery finds +an intent log item but does not find a corresponding intent done item, it will +reconstruct the incore state of the intent item and finish it. +In the example above, the log must replay both frees described in the recovered +EFI to complete the recovery phase. + +There are subtleties to XFS' transaction chaining strategy to consider: + +* Log items must be added to a transaction in the correct order to prevent + conflicts with principal objects that are not held by the transaction. + In other words, all per-AG metadata updates for an unmapped block must be + completed before the last update to free the extent, and extents should not + be reallocated until that last update commits to the log. + +* AG header buffers are released between each transaction in a chain. + This means that other threads can observe an AG in an intermediate state, + but as long as the first subtlety is handled, this should not affect the + correctness of filesystem operations. + +* Unmounting the filesystem flushes all pending work to disk, which means that + offline fsck never sees the temporary inconsistencies caused by deferred + work item processing. + +In this manner, XFS employs a form of eventual consistency to avoid deadlocks +and increase parallelism. + +During the design phase of the reverse mapping and reflink features, it was +decided that it was impractical to cram all the reverse mapping updates for a +single filesystem change into a single transaction because a single file +mapping operation can explode into many small updates: + +* The block mapping update itself +* A reverse mapping update for the block mapping update +* Fixing the freelist +* A reverse mapping update for the freelist fix + +* A shape change to the block mapping btree +* A reverse mapping update for the btree update +* Fixing the freelist (again) +* A reverse mapping update for the freelist fix + +* An update to the reference counting information +* A reverse mapping update for the refcount update +* Fixing the freelist (a third time) +* A reverse mapping update for the freelist fix + +* Freeing any space that was unmapped and not owned by any other file +* Fixing the freelist (a fourth time) +* A reverse mapping update for the freelist fix + +* Freeing the space used by the block mapping btree +* Fixing the freelist (a fifth time) +* A reverse mapping update for the freelist fix + +Free list fixups are not usually needed more than once per AG per transaction +chain, but it is theoretically possible if space is very tight. +For copy-on-write updates this is even worse, because this must be done once to +remove the space from a staging area and again to map it into the file! + +To deal with this explosion in a calm manner, XFS expands its use of deferred +work items to cover most reverse mapping updates and all refcount updates. +This reduces the worst case size of transaction reservations by breaking the +work into a long chain of small updates, which increases the degree of eventual +consistency in the system. +Again, this generally isn't a problem because XFS orders its deferred work +items carefully to avoid resource reuse conflicts between unsuspecting threads. + +However, online fsck changes the rules -- remember that although physical +updates to per-AG structures are coordinated by locking the buffers for AG +headers, buffer locks are dropped between transactions. +Once scrub acquires resources and takes locks for a data structure, it must do +all the validation work without releasing the lock. +If the main lock for a space btree is an AG header buffer lock, scrub may have +interrupted another thread that is midway through finishing a chain. +For example, if a thread performing a copy-on-write has completed a reverse +mapping update but not the corresponding refcount update, the two AG btrees +will appear inconsistent to scrub and an observation of corruption will be +recorded. This observation will not be correct. +If a repair is attempted in this state, the results will be catastrophic! + +Several other solutions to this problem were evaluated upon discovery of this +flaw and rejected: + +1. Add a higher level lock to allocation groups and require writer threads to + acquire the higher level lock in AG order before making any changes. + This would be very difficult to implement in practice because it is + difficult to determine which locks need to be obtained, and in what order, + without simulating the entire operation. + Performing a dry run of a file operation to discover necessary locks would + make the filesystem very slow. + +2. Make the deferred work coordinator code aware of consecutive intent items + targeting the same AG and have it hold the AG header buffers locked across + the transaction roll between updates. + This would introduce a lot of complexity into the coordinator since it is + only loosely coupled with the actual deferred work items. + It would also fail to solve the problem because deferred work items can + generate new deferred subtasks, but all subtasks must be complete before + work can start on a new sibling task. + +3. Teach online fsck to walk all transactions waiting for whichever lock(s) + protect the data structure being scrubbed to look for pending operations. + The checking and repair operations must factor these pending operations into + the evaluations being performed. + This solution is a nonstarter because it is *extremely* invasive to the main + filesystem. + +.. _intent_drains: + +Intent Drains +````````````` + +Online fsck uses an atomic intent item counter and lock cycling to coordinate +with transaction chains. +There are two key properties to the drain mechanism. +First, the counter is incremented when a deferred work item is *queued* to a +transaction, and it is decremented after the associated intent done log item is +*committed* to another transaction. +The second property is that deferred work can be added to a transaction without +holding an AG header lock, but per-AG work items cannot be marked done without +locking that AG header buffer to log the physical updates and the intent done +log item. +The first property enables scrub to yield to running transaction chains, which +is an explicit deprioritization of online fsck to benefit file operations. +The second property of the drain is key to the correct coordination of scrub, +since scrub will always be able to decide if a conflict is possible. + +For regular filesystem code, the drain works as follows: + +1. Call the appropriate subsystem function to add a deferred work item to a + transaction. + +2. The function calls ``xfs_defer_drain_bump`` to increase the counter. + +3. When the deferred item manager wants to finish the deferred work item, it + calls ``->finish_item`` to complete it. + +4. The ``->finish_item`` implementation logs some changes and calls + ``xfs_defer_drain_drop`` to decrease the sloppy counter and wake up any threads + waiting on the drain. + +5. The subtransaction commits, which unlocks the resource associated with the + intent item. + +For scrub, the drain works as follows: + +1. Lock the resource(s) associated with the metadata being scrubbed. + For example, a scan of the refcount btree would lock the AGI and AGF header + buffers. + +2. If the counter is zero (``xfs_defer_drain_busy`` returns false), there are no + chains in progress and the operation may proceed. + +3. Otherwise, release the resources grabbed in step 1. + +4. Wait for the intent counter to reach zero (``xfs_defer_drain_intents``), then go + back to step 1 unless a signal has been caught. + +To avoid polling in step 4, the drain provides a waitqueue for scrub threads to +be woken up whenever the intent count drops to zero. + +The proposed patchset is the +`scrub intent drain series +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-drain-intents>`_. + +.. _jump_labels: + +Static Keys (aka Jump Label Patching) +````````````````````````````````````` + +Online fsck for XFS separates the regular filesystem from the checking and +repair code as much as possible. +However, there are a few parts of online fsck (such as the intent drains, and +later, live update hooks) where it is useful for the online fsck code to know +what's going on in the rest of the filesystem. +Since it is not expected that online fsck will be constantly running in the +background, it is very important to minimize the runtime overhead imposed by +these hooks when online fsck is compiled into the kernel but not actively +running on behalf of userspace. +Taking locks in the hot path of a writer thread to access a data structure only +to find that no further action is necessary is expensive -- on the author's +computer, this have an overhead of 40-50ns per access. +Fortunately, the kernel supports dynamic code patching, which enables XFS to +replace a static branch to hook code with ``nop`` sleds when online fsck isn't +running. +This sled has an overhead of however long it takes the instruction decoder to +skip past the sled, which seems to be on the order of less than 1ns and +does not access memory outside of instruction fetching. + +When online fsck enables the static key, the sled is replaced with an +unconditional branch to call the hook code. +The switchover is quite expensive (~22000ns) but is paid entirely by the +program that invoked online fsck, and can be amortized if multiple threads +enter online fsck at the same time, or if multiple filesystems are being +checked at the same time. +Changing the branch direction requires taking the CPU hotplug lock, and since +CPU initialization requires memory allocation, online fsck must be careful not +to change a static key while holding any locks or resources that could be +accessed in the memory reclaim paths. +To minimize contention on the CPU hotplug lock, care should be taken not to +enable or disable static keys unnecessarily. + +Because static keys are intended to minimize hook overhead for regular +filesystem operations when xfs_scrub is not running, the intended usage +patterns are as follows: + +- The hooked part of XFS should declare a static-scoped static key that + defaults to false. + The ``DEFINE_STATIC_KEY_FALSE`` macro takes care of this. + The static key itself should be declared as a ``static`` variable. + +- When deciding to invoke code that's only used by scrub, the regular + filesystem should call the ``static_branch_unlikely`` predicate to avoid the + scrub-only hook code if the static key is not enabled. + +- The regular filesystem should export helper functions that call + ``static_branch_inc`` to enable and ``static_branch_dec`` to disable the + static key. + Wrapper functions make it easy to compile out the relevant code if the kernel + distributor turns off online fsck at build time. + +- Scrub functions wanting to turn on scrub-only XFS functionality should call + the ``xchk_fsgates_enable`` from the setup function to enable a specific + hook. + This must be done before obtaining any resources that are used by memory + reclaim. + Callers had better be sure they really need the functionality gated by the + static key; the ``TRY_HARDER`` flag is useful here. + +Online scrub has resource acquisition helpers (e.g. ``xchk_perag_lock``) to +handle locking AGI and AGF buffers for all scrubber functions. +If it detects a conflict between scrub and the running transactions, it will +try to wait for intents to complete. +If the caller of the helper has not enabled the static key, the helper will +return -EDEADLOCK, which should result in the scrub being restarted with the +``TRY_HARDER`` flag set. +The scrub setup function should detect that flag, enable the static key, and +try the scrub again. +Scrub teardown disables all static keys obtained by ``xchk_fsgates_enable``. + +For more information, please see the kernel documentation of +Documentation/staging/static-keys.rst. + +.. _xfile: + +Pageable Kernel Memory +---------------------- + +Some online checking functions work by scanning the filesystem to build a +shadow copy of an ondisk metadata structure in memory and comparing the two +copies. +For online repair to rebuild a metadata structure, it must compute the record +set that will be stored in the new structure before it can persist that new +structure to disk. +Ideally, repairs complete with a single atomic commit that introduces +a new data structure. +To meet these goals, the kernel needs to collect a large amount of information +in a place that doesn't require the correct operation of the filesystem. + +Kernel memory isn't suitable because: + +* Allocating a contiguous region of memory to create a C array is very + difficult, especially on 32-bit systems. + +* Linked lists of records introduce double pointer overhead which is very high + and eliminate the possibility of indexed lookups. + +* Kernel memory is pinned, which can drive the system into OOM conditions. + +* The system might not have sufficient memory to stage all the information. + +At any given time, online fsck does not need to keep the entire record set in +memory, which means that individual records can be paged out if necessary. +Continued development of online fsck demonstrated that the ability to perform +indexed data storage would also be very useful. +Fortunately, the Linux kernel already has a facility for byte-addressable and +pageable storage: tmpfs. +In-kernel graphics drivers (most notably i915) take advantage of tmpfs files +to store intermediate data that doesn't need to be in memory at all times, so +that usage precedent is already established. +Hence, the ``xfile`` was born! + ++--------------------------------------------------------------------------+ +| **Historical Sidebar**: | ++--------------------------------------------------------------------------+ +| The first edition of online repair inserted records into a new btree as | +| it found them, which failed because filesystem could shut down with a | +| built data structure, which would be live after recovery finished. | +| | +| The second edition solved the half-rebuilt structure problem by storing | +| everything in memory, but frequently ran the system out of memory. | +| | +| The third edition solved the OOM problem by using linked lists, but the | +| memory overhead of the list pointers was extreme. | ++--------------------------------------------------------------------------+ + +xfile Access Models +``````````````````` + +A survey of the intended uses of xfiles suggested these use cases: + +1. Arrays of fixed-sized records (space management btrees, directory and + extended attribute entries) + +2. Sparse arrays of fixed-sized records (quotas and link counts) + +3. Large binary objects (BLOBs) of variable sizes (directory and extended + attribute names and values) + +4. Staging btrees in memory (reverse mapping btrees) + +5. Arbitrary contents (realtime space management) + +To support the first four use cases, high level data structures wrap the xfile +to share functionality between online fsck functions. +The rest of this section discusses the interfaces that the xfile presents to +four of those five higher level data structures. +The fifth use case is discussed in the :ref:`realtime summary <rtsummary>` case +study. + +The most general storage interface supported by the xfile enables the reading +and writing of arbitrary quantities of data at arbitrary offsets in the xfile. +This capability is provided by ``xfile_pread`` and ``xfile_pwrite`` functions, +which behave similarly to their userspace counterparts. +XFS is very record-based, which suggests that the ability to load and store +complete records is important. +To support these cases, a pair of ``xfile_obj_load`` and ``xfile_obj_store`` +functions are provided to read and persist objects into an xfile. +They are internally the same as pread and pwrite, except that they treat any +error as an out of memory error. +For online repair, squashing error conditions in this manner is an acceptable +behavior because the only reaction is to abort the operation back to userspace. +All five xfile usecases can be serviced by these four functions. + +However, no discussion of file access idioms is complete without answering the +question, "But what about mmap?" +It is convenient to access storage directly with pointers, just like userspace +code does with regular memory. +Online fsck must not drive the system into OOM conditions, which means that +xfiles must be responsive to memory reclamation. +tmpfs can only push a pagecache folio to the swap cache if the folio is neither +pinned nor locked, which means the xfile must not pin too many folios. + +Short term direct access to xfile contents is done by locking the pagecache +folio and mapping it into kernel address space. +Programmatic access (e.g. pread and pwrite) uses this mechanism. +Folio locks are not supposed to be held for long periods of time, so long +term direct access to xfile contents is done by bumping the folio refcount, +mapping it into kernel address space, and dropping the folio lock. +These long term users *must* be responsive to memory reclaim by hooking into +the shrinker infrastructure to know when to release folios. + +The ``xfile_get_page`` and ``xfile_put_page`` functions are provided to +retrieve the (locked) folio that backs part of an xfile and to release it. +The only code to use these folio lease functions are the xfarray +:ref:`sorting<xfarray_sort>` algorithms and the :ref:`in-memory +btrees<xfbtree>`. + +xfile Access Coordination +````````````````````````` + +For security reasons, xfiles must be owned privately by the kernel. +They are marked ``S_PRIVATE`` to prevent interference from the security system, +must never be mapped into process file descriptor tables, and their pages must +never be mapped into userspace processes. + +To avoid locking recursion issues with the VFS, all accesses to the shmfs file +are performed by manipulating the page cache directly. +xfile writers call the ``->write_begin`` and ``->write_end`` functions of the +xfile's address space to grab writable pages, copy the caller's buffer into the +page, and release the pages. +xfile readers call ``shmem_read_mapping_page_gfp`` to grab pages directly +before copying the contents into the caller's buffer. +In other words, xfiles ignore the VFS read and write code paths to avoid +having to create a dummy ``struct kiocb`` and to avoid taking inode and +freeze locks. +tmpfs cannot be frozen, and xfiles must not be exposed to userspace. + +If an xfile is shared between threads to stage repairs, the caller must provide +its own locks to coordinate access. +For example, if a scrub function stores scan results in an xfile and needs +other threads to provide updates to the scanned data, the scrub function must +provide a lock for all threads to share. + +.. _xfarray: + +Arrays of Fixed-Sized Records +````````````````````````````` + +In XFS, each type of indexed space metadata (free space, inodes, reference +counts, file fork space, and reverse mappings) consists of a set of fixed-size +records indexed with a classic B+ tree. +Directories have a set of fixed-size dirent records that point to the names, +and extended attributes have a set of fixed-size attribute keys that point to +names and values. +Quota counters and file link counters index records with numbers. +During a repair, scrub needs to stage new records during the gathering step and +retrieve them during the btree building step. + +Although this requirement can be satisfied by calling the read and write +methods of the xfile directly, it is simpler for callers for there to be a +higher level abstraction to take care of computing array offsets, to provide +iterator functions, and to deal with sparse records and sorting. +The ``xfarray`` abstraction presents a linear array for fixed-size records atop +the byte-accessible xfile. + +.. _xfarray_access_patterns: + +Array Access Patterns +^^^^^^^^^^^^^^^^^^^^^ + +Array access patterns in online fsck tend to fall into three categories. +Iteration of records is assumed to be necessary for all cases and will be +covered in the next section. + +The first type of caller handles records that are indexed by position. +Gaps may exist between records, and a record may be updated multiple times +during the collection step. +In other words, these callers want a sparse linearly addressed table file. +The typical use case are quota records or file link count records. +Access to array elements is performed programmatically via ``xfarray_load`` and +``xfarray_store`` functions, which wrap the similarly-named xfile functions to +provide loading and storing of array elements at arbitrary array indices. +Gaps are defined to be null records, and null records are defined to be a +sequence of all zero bytes. +Null records are detected by calling ``xfarray_element_is_null``. +They are created either by calling ``xfarray_unset`` to null out an existing +record or by never storing anything to an array index. + +The second type of caller handles records that are not indexed by position +and do not require multiple updates to a record. +The typical use case here is rebuilding space btrees and key/value btrees. +These callers can add records to the array without caring about array indices +via the ``xfarray_append`` function, which stores a record at the end of the +array. +For callers that require records to be presentable in a specific order (e.g. +rebuilding btree data), the ``xfarray_sort`` function can arrange the sorted +records; this function will be covered later. + +The third type of caller is a bag, which is useful for counting records. +The typical use case here is constructing space extent reference counts from +reverse mapping information. +Records can be put in the bag in any order, they can be removed from the bag +at any time, and uniqueness of records is left to callers. +The ``xfarray_store_anywhere`` function is used to insert a record in any +null record slot in the bag; and the ``xfarray_unset`` function removes a +record from the bag. + +The proposed patchset is the +`big in-memory array +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=big-array>`_. + +Iterating Array Elements +^^^^^^^^^^^^^^^^^^^^^^^^ + +Most users of the xfarray require the ability to iterate the records stored in +the array. +Callers can probe every possible array index with the following: + +.. code-block:: c + + xfarray_idx_t i; + foreach_xfarray_idx(array, i) { + xfarray_load(array, i, &rec); + + /* do something with rec */ + } + +All users of this idiom must be prepared to handle null records or must already +know that there aren't any. + +For xfarray users that want to iterate a sparse array, the ``xfarray_iter`` +function ignores indices in the xfarray that have never been written to by +calling ``xfile_seek_data`` (which internally uses ``SEEK_DATA``) to skip areas +of the array that are not populated with memory pages. +Once it finds a page, it will skip the zeroed areas of the page. + +.. code-block:: c + + xfarray_idx_t i = XFARRAY_CURSOR_INIT; + while ((ret = xfarray_iter(array, &i, &rec)) == 1) { + /* do something with rec */ + } + +.. _xfarray_sort: + +Sorting Array Elements +^^^^^^^^^^^^^^^^^^^^^^ + +During the fourth demonstration of online repair, a community reviewer remarked +that for performance reasons, online repair ought to load batches of records +into btree record blocks instead of inserting records into a new btree one at a +time. +The btree insertion code in XFS is responsible for maintaining correct ordering +of the records, so naturally the xfarray must also support sorting the record +set prior to bulk loading. + +Case Study: Sorting xfarrays +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The sorting algorithm used in the xfarray is actually a combination of adaptive +quicksort and a heapsort subalgorithm in the spirit of +`Sedgewick <https://algs4.cs.princeton.edu/23quicksort/>`_ and +`pdqsort <https://github.com/orlp/pdqsort>`_, with customizations for the Linux +kernel. +To sort records in a reasonably short amount of time, ``xfarray`` takes +advantage of the binary subpartitioning offered by quicksort, but it also uses +heapsort to hedge aginst performance collapse if the chosen quicksort pivots +are poor. +Both algorithms are (in general) O(n * lg(n)), but there is a wide performance +gulf between the two implementations. + +The Linux kernel already contains a reasonably fast implementation of heapsort. +It only operates on regular C arrays, which limits the scope of its usefulness. +There are two key places where the xfarray uses it: + +* Sorting any record subset backed by a single xfile page. + +* Loading a small number of xfarray records from potentially disparate parts + of the xfarray into a memory buffer, and sorting the buffer. + +In other words, ``xfarray`` uses heapsort to constrain the nested recursion of +quicksort, thereby mitigating quicksort's worst runtime behavior. + +Choosing a quicksort pivot is a tricky business. +A good pivot splits the set to sort in half, leading to the divide and conquer +behavior that is crucial to O(n * lg(n)) performance. +A poor pivot barely splits the subset at all, leading to O(n\ :sup:`2`) +runtime. +The xfarray sort routine tries to avoid picking a bad pivot by sampling nine +records into a memory buffer and using the kernel heapsort to identify the +median of the nine. + +Most modern quicksort implementations employ Tukey's "ninther" to select a +pivot from a classic C array. +Typical ninther implementations pick three unique triads of records, sort each +of the triads, and then sort the middle value of each triad to determine the +ninther value. +As stated previously, however, xfile accesses are not entirely cheap. +It turned out to be much more performant to read the nine elements into a +memory buffer, run the kernel's in-memory heapsort on the buffer, and choose +the 4th element of that buffer as the pivot. +Tukey's ninthers are described in J. W. Tukey, `The ninther, a technique for +low-effort robust (resistant) location in large samples`, in *Contributions to +Survey Sampling and Applied Statistics*, edited by H. David, (Academic Press, +1978), pp. 251–257. + +The partitioning of quicksort is fairly textbook -- rearrange the record +subset around the pivot, then set up the current and next stack frames to +sort with the larger and the smaller halves of the pivot, respectively. +This keeps the stack space requirements to log2(record count). + +As a final performance optimization, the hi and lo scanning phase of quicksort +keeps examined xfile pages mapped in the kernel for as long as possible to +reduce map/unmap cycles. +Surprisingly, this reduces overall sort runtime by nearly half again after +accounting for the application of heapsort directly onto xfile pages. + +.. _xfblob: + +Blob Storage +```````````` + +Extended attributes and directories add an additional requirement for staging +records: arbitrary byte sequences of finite length. +Each directory entry record needs to store entry name, +and each extended attribute needs to store both the attribute name and value. +The names, keys, and values can consume a large amount of memory, so the +``xfblob`` abstraction was created to simplify management of these blobs +atop an xfile. + +Blob arrays provide ``xfblob_load`` and ``xfblob_store`` functions to retrieve +and persist objects. +The store function returns a magic cookie for every object that it persists. +Later, callers provide this cookie to the ``xblob_load`` to recall the object. +The ``xfblob_free`` function frees a specific blob, and the ``xfblob_truncate`` +function frees them all because compaction is not needed. + +The details of repairing directories and extended attributes will be discussed +in a subsequent section about atomic extent swapping. +However, it should be noted that these repair functions only use blob storage +to cache a small number of entries before adding them to a temporary ondisk +file, which is why compaction is not required. + +The proposed patchset is at the start of the +`extended attribute repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-xattrs>`_ series. + +.. _xfbtree: + +In-Memory B+Trees +````````````````` + +The chapter about :ref:`secondary metadata<secondary_metadata>` mentioned that +checking and repairing of secondary metadata commonly requires coordination +between a live metadata scan of the filesystem and writer threads that are +updating that metadata. +Keeping the scan data up to date requires requires the ability to propagate +metadata updates from the filesystem into the data being collected by the scan. +This *can* be done by appending concurrent updates into a separate log file and +applying them before writing the new metadata to disk, but this leads to +unbounded memory consumption if the rest of the system is very busy. +Another option is to skip the side-log and commit live updates from the +filesystem directly into the scan data, which trades more overhead for a lower +maximum memory requirement. +In both cases, the data structure holding the scan results must support indexed +access to perform well. + +Given that indexed lookups of scan data is required for both strategies, online +fsck employs the second strategy of committing live updates directly into +scan data. +Because xfarrays are not indexed and do not enforce record ordering, they +are not suitable for this task. +Conveniently, however, XFS has a library to create and maintain ordered reverse +mapping records: the existing rmap btree code! +If only there was a means to create one in memory. + +Recall that the :ref:`xfile <xfile>` abstraction represents memory pages as a +regular file, which means that the kernel can create byte or block addressable +virtual address spaces at will. +The XFS buffer cache specializes in abstracting IO to block-oriented address +spaces, which means that adaptation of the buffer cache to interface with +xfiles enables reuse of the entire btree library. +Btrees built atop an xfile are collectively known as ``xfbtrees``. +The next few sections describe how they actually work. + +The proposed patchset is the +`in-memory btree +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=in-memory-btrees>`_ +series. + +Using xfiles as a Buffer Cache Target +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Two modifications are necessary to support xfiles as a buffer cache target. +The first is to make it possible for the ``struct xfs_buftarg`` structure to +host the ``struct xfs_buf`` rhashtable, because normally those are held by a +per-AG structure. +The second change is to modify the buffer ``ioapply`` function to "read" cached +pages from the xfile and "write" cached pages back to the xfile. +Multiple access to individual buffers is controlled by the ``xfs_buf`` lock, +since the xfile does not provide any locking on its own. +With this adaptation in place, users of the xfile-backed buffer cache use +exactly the same APIs as users of the disk-backed buffer cache. +The separation between xfile and buffer cache implies higher memory usage since +they do not share pages, but this property could some day enable transactional +updates to an in-memory btree. +Today, however, it simply eliminates the need for new code. + +Space Management with an xfbtree +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Space management for an xfile is very simple -- each btree block is one memory +page in size. +These blocks use the same header format as an on-disk btree, but the in-memory +block verifiers ignore the checksums, assuming that xfile memory is no more +corruption-prone than regular DRAM. +Reusing existing code here is more important than absolute memory efficiency. + +The very first block of an xfile backing an xfbtree contains a header block. +The header describes the owner, height, and the block number of the root +xfbtree block. + +To allocate a btree block, use ``xfile_seek_data`` to find a gap in the file. +If there are no gaps, create one by extending the length of the xfile. +Preallocate space for the block with ``xfile_prealloc``, and hand back the +location. +To free an xfbtree block, use ``xfile_discard`` (which internally uses +``FALLOC_FL_PUNCH_HOLE``) to remove the memory page from the xfile. + +Populating an xfbtree +^^^^^^^^^^^^^^^^^^^^^ + +An online fsck function that wants to create an xfbtree should proceed as +follows: + +1. Call ``xfile_create`` to create an xfile. + +2. Call ``xfs_alloc_memory_buftarg`` to create a buffer cache target structure + pointing to the xfile. + +3. Pass the buffer cache target, buffer ops, and other information to + ``xfbtree_create`` to write an initial tree header and root block to the + xfile. + Each btree type should define a wrapper that passes necessary arguments to + the creation function. + For example, rmap btrees define ``xfs_rmapbt_mem_create`` to take care of + all the necessary details for callers. + A ``struct xfbtree`` object will be returned. + +4. Pass the xfbtree object to the btree cursor creation function for the + btree type. + Following the example above, ``xfs_rmapbt_mem_cursor`` takes care of this + for callers. + +5. Pass the btree cursor to the regular btree functions to make queries against + and to update the in-memory btree. + For example, a btree cursor for an rmap xfbtree can be passed to the + ``xfs_rmap_*`` functions just like any other btree cursor. + See the :ref:`next section<xfbtree_commit>` for information on dealing with + xfbtree updates that are logged to a transaction. + +6. When finished, delete the btree cursor, destroy the xfbtree object, free the + buffer target, and the destroy the xfile to release all resources. + +.. _xfbtree_commit: + +Committing Logged xfbtree Buffers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Although it is a clever hack to reuse the rmap btree code to handle the staging +structure, the ephemeral nature of the in-memory btree block storage presents +some challenges of its own. +The XFS transaction manager must not commit buffer log items for buffers backed +by an xfile because the log format does not understand updates for devices +other than the data device. +An ephemeral xfbtree probably will not exist by the time the AIL checkpoints +log transactions back into the filesystem, and certainly won't exist during +log recovery. +For these reasons, any code updating an xfbtree in transaction context must +remove the buffer log items from the transaction and write the updates into the +backing xfile before committing or cancelling the transaction. + +The ``xfbtree_trans_commit`` and ``xfbtree_trans_cancel`` functions implement +this functionality as follows: + +1. Find each buffer log item whose buffer targets the xfile. + +2. Record the dirty/ordered status of the log item. + +3. Detach the log item from the buffer. + +4. Queue the buffer to a special delwri list. + +5. Clear the transaction dirty flag if the only dirty log items were the ones + that were detached in step 3. + +6. Submit the delwri list to commit the changes to the xfile, if the updates + are being committed. + +After removing xfile logged buffers from the transaction in this manner, the +transaction can be committed or cancelled. + +Bulk Loading of Ondisk B+Trees +------------------------------ + +As mentioned previously, early iterations of online repair built new btree +structures by creating a new btree and adding observations individually. +Loading a btree one record at a time had a slight advantage of not requiring +the incore records to be sorted prior to commit, but was very slow and leaked +blocks if the system went down during a repair. +Loading records one at a time also meant that repair could not control the +loading factor of the blocks in the new btree. + +Fortunately, the venerable ``xfs_repair`` tool had a more efficient means for +rebuilding a btree index from a collection of records -- bulk btree loading. +This was implemented rather inefficiently code-wise, since ``xfs_repair`` +had separate copy-pasted implementations for each btree type. + +To prepare for online fsck, each of the four bulk loaders were studied, notes +were taken, and the four were refactored into a single generic btree bulk +loading mechanism. +Those notes in turn have been refreshed and are presented below. + +Geometry Computation +```````````````````` + +The zeroth step of bulk loading is to assemble the entire record set that will +be stored in the new btree, and sort the records. +Next, call ``xfs_btree_bload_compute_geometry`` to compute the shape of the +btree from the record set, the type of btree, and any load factor preferences. +This information is required for resource reservation. + +First, the geometry computation computes the minimum and maximum records that +will fit in a leaf block from the size of a btree block and the size of the +block header. +Roughly speaking, the maximum number of records is:: + + maxrecs = (block_size - header_size) / record_size + +The XFS design specifies that btree blocks should be merged when possible, +which means the minimum number of records is half of maxrecs:: + + minrecs = maxrecs / 2 + +The next variable to determine is the desired loading factor. +This must be at least minrecs and no more than maxrecs. +Choosing minrecs is undesirable because it wastes half the block. +Choosing maxrecs is also undesirable because adding a single record to each +newly rebuilt leaf block will cause a tree split, which causes a noticeable +drop in performance immediately afterwards. +The default loading factor was chosen to be 75% of maxrecs, which provides a +reasonably compact structure without any immediate split penalties:: + + default_load_factor = (maxrecs + minrecs) / 2 + +If space is tight, the loading factor will be set to maxrecs to try to avoid +running out of space:: + + leaf_load_factor = enough space ? default_load_factor : maxrecs + +Load factor is computed for btree node blocks using the combined size of the +btree key and pointer as the record size:: + + maxrecs = (block_size - header_size) / (key_size + ptr_size) + minrecs = maxrecs / 2 + node_load_factor = enough space ? default_load_factor : maxrecs + +Once that's done, the number of leaf blocks required to store the record set +can be computed as:: + + leaf_blocks = ceil(record_count / leaf_load_factor) + +The number of node blocks needed to point to the next level down in the tree +is computed as:: + + n_blocks = (n == 0 ? leaf_blocks : node_blocks[n]) + node_blocks[n + 1] = ceil(n_blocks / node_load_factor) + +The entire computation is performed recursively until the current level only +needs one block. +The resulting geometry is as follows: + +- For AG-rooted btrees, this level is the root level, so the height of the new + tree is ``level + 1`` and the space needed is the summation of the number of + blocks on each level. + +- For inode-rooted btrees where the records in the top level do not fit in the + inode fork area, the height is ``level + 2``, the space needed is the + summation of the number of blocks on each level, and the inode fork points to + the root block. + +- For inode-rooted btrees where the records in the top level can be stored in + the inode fork area, then the root block can be stored in the inode, the + height is ``level + 1``, and the space needed is one less than the summation + of the number of blocks on each level. + This only becomes relevant when non-bmap btrees gain the ability to root in + an inode, which is a future patchset and only included here for completeness. + +.. _newbt: + +Reserving New B+Tree Blocks +``````````````````````````` + +Once repair knows the number of blocks needed for the new btree, it allocates +those blocks using the free space information. +Each reserved extent is tracked separately by the btree builder state data. +To improve crash resilience, the reservation code also logs an Extent Freeing +Intent (EFI) item in the same transaction as each space allocation and attaches +its in-memory ``struct xfs_extent_free_item`` object to the space reservation. +If the system goes down, log recovery will use the unfinished EFIs to free the +unused space, the free space, leaving the filesystem unchanged. + +Each time the btree builder claims a block for the btree from a reserved +extent, it updates the in-memory reservation to reflect the claimed space. +Block reservation tries to allocate as much contiguous space as possible to +reduce the number of EFIs in play. + +While repair is writing these new btree blocks, the EFIs created for the space +reservations pin the tail of the ondisk log. +It's possible that other parts of the system will remain busy and push the head +of the log towards the pinned tail. +To avoid livelocking the filesystem, the EFIs must not pin the tail of the log +for too long. +To alleviate this problem, the dynamic relogging capability of the deferred ops +mechanism is reused here to commit a transaction at the log head containing an +EFD for the old EFI and new EFI at the head. +This enables the log to release the old EFI to keep the log moving forwards. + +EFIs have a role to play during the commit and reaping phases; please see the +next section and the section about :ref:`reaping<reaping>` for more details. + +Proposed patchsets are the +`bitmap rework +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-bitmap-rework>`_ +and the +`preparation for bulk loading btrees +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-prep-for-bulk-loading>`_. + + +Writing the New Tree +```````````````````` + +This part is pretty simple -- the btree builder (``xfs_btree_bulkload``) claims +a block from the reserved list, writes the new btree block header, fills the +rest of the block with records, and adds the new leaf block to a list of +written blocks:: + + ┌────┠+ │leaf│ + │RRR │ + └────┘ + +Sibling pointers are set every time a new block is added to the level:: + + ┌────┠┌────┠┌────┠┌────┠+ │leaf│→│leaf│→│leaf│→│leaf│ + │RRR │â†â”‚RRR │â†â”‚RRR │â†â”‚RRR │ + └────┘ └────┘ └────┘ └────┘ + +When it finishes writing the record leaf blocks, it moves on to the node +blocks +To fill a node block, it walks each block in the next level down in the tree +to compute the relevant keys and write them into the parent node:: + + ┌────┠┌────┠+ │node│──────→│node│ + │PP │â†â”€â”€â”€â”€â”€â”€â”‚PP │ + └────┘ └────┘ + ↙ ↘ ↙ ↘ + ┌────┠┌────┠┌────┠┌────┠+ │leaf│→│leaf│→│leaf│→│leaf│ + │RRR │â†â”‚RRR │â†â”‚RRR │â†â”‚RRR │ + └────┘ └────┘ └────┘ └────┘ + +When it reaches the root level, it is ready to commit the new btree!:: + + ┌─────────┠+ │ root │ + │ PP │ + └─────────┘ + ↙ ↘ + ┌────┠┌────┠+ │node│──────→│node│ + │PP │â†â”€â”€â”€â”€â”€â”€â”‚PP │ + └────┘ └────┘ + ↙ ↘ ↙ ↘ + ┌────┠┌────┠┌────┠┌────┠+ │leaf│→│leaf│→│leaf│→│leaf│ + │RRR │â†â”‚RRR │â†â”‚RRR │â†â”‚RRR │ + └────┘ └────┘ └────┘ └────┘ + +The first step to commit the new btree is to persist the btree blocks to disk +synchronously. +This is a little complicated because a new btree block could have been freed +in the recent past, so the builder must use ``xfs_buf_delwri_queue_here`` to +remove the (stale) buffer from the AIL list before it can write the new blocks +to disk. +Blocks are queued for IO using a delwri list and written in one large batch +with ``xfs_buf_delwri_submit``. + +Once the new blocks have been persisted to disk, control returns to the +individual repair function that called the bulk loader. +The repair function must log the location of the new root in a transaction, +clean up the space reservations that were made for the new btree, and reap the +old metadata blocks: + +1. Commit the location of the new btree root. + +2. For each incore reservation: + + a. Log Extent Freeing Done (EFD) items for all the space that was consumed + by the btree builder. The new EFDs must point to the EFIs attached to + the reservation to prevent log recovery from freeing the new blocks. + + b. For unclaimed portions of incore reservations, create a regular deferred + extent free work item to be free the unused space later in the + transaction chain. + + c. The EFDs and EFIs logged in steps 2a and 2b must not overrun the + reservation of the committing transaction. + If the btree loading code suspects this might be about to happen, it must + call ``xrep_defer_finish`` to clear out the deferred work and obtain a + fresh transaction. + +3. Clear out the deferred work a second time to finish the commit and clean + the repair transaction. + +The transaction rolling in steps 2c and 3 represent a weakness in the repair +algorithm, because a log flush and a crash before the end of the reap step can +result in space leaking. +Online repair functions minimize the chances of this occuring by using very +large transactions, which each can accomodate many thousands of block freeing +instructions. +Repair moves on to reaping the old blocks, which will be presented in a +subsequent :ref:`section<reaping>` after a few case studies of bulk loading. + +Case Study: Rebuilding the Inode Index +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The high level process to rebuild the inode index btree is: + +1. Walk the reverse mapping records to generate ``struct xfs_inobt_rec`` + records from the inode chunk information and a bitmap of the old inode btree + blocks. + +2. Append the records to an xfarray in inode order. + +3. Use the ``xfs_btree_bload_compute_geometry`` function to compute the number + of blocks needed for the inode btree. + If the free space inode btree is enabled, call it again to estimate the + geometry of the finobt. + +4. Allocate the number of blocks computed in the previous step. + +5. Use ``xfs_btree_bload`` to write the xfarray records to btree blocks and + generate the internal node blocks. + If the free space inode btree is enabled, call it again to load the finobt. + +6. Commit the location of the new btree root block(s) to the AGI. + +7. Reap the old btree blocks using the bitmap created in step 1. + +Details are as follows. + +The inode btree maps inumbers to the ondisk location of the associated +inode records, which means that the inode btrees can be rebuilt from the +reverse mapping information. +Reverse mapping records with an owner of ``XFS_RMAP_OWN_INOBT`` marks the +location of the old inode btree blocks. +Each reverse mapping record with an owner of ``XFS_RMAP_OWN_INODES`` marks the +location of at least one inode cluster buffer. +A cluster is the smallest number of ondisk inodes that can be allocated or +freed in a single transaction; it is never smaller than 1 fs block or 4 inodes. + +For the space represented by each inode cluster, ensure that there are no +records in the free space btrees nor any records in the reference count btree. +If there are, the space metadata inconsistencies are reason enough to abort the +operation. +Otherwise, read each cluster buffer to check that its contents appear to be +ondisk inodes and to decide if the file is allocated +(``xfs_dinode.i_mode != 0``) or free (``xfs_dinode.i_mode == 0``). +Accumulate the results of successive inode cluster buffer reads until there is +enough information to fill a single inode chunk record, which is 64 consecutive +numbers in the inumber keyspace. +If the chunk is sparse, the chunk record may include holes. + +Once the repair function accumulates one chunk's worth of data, it calls +``xfarray_append`` to add the inode btree record to the xfarray. +This xfarray is walked twice during the btree creation step -- once to populate +the inode btree with all inode chunk records, and a second time to populate the +free inode btree with records for chunks that have free non-sparse inodes. +The number of records for the inode btree is the number of xfarray records, +but the record count for the free inode btree has to be computed as inode chunk +records are stored in the xfarray. + +The proposed patchset is the +`AG btree repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-ag-btrees>`_ +series. + +Case Study: Rebuilding the Space Reference Counts +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Reverse mapping records are used to rebuild the reference count information. +Reference counts are required for correct operation of copy on write for shared +file data. +Imagine the reverse mapping entries as rectangles representing extents of +physical blocks, and that the rectangles can be laid down to allow them to +overlap each other. +From the diagram below, it is apparent that a reference count record must start +or end wherever the height of the stack changes. +In other words, the record emission stimulus is level-triggered:: + + â–ˆ ███ + ██ █████ ████ ███ ██████ + ██ ████ ███████████ ████ █████████ + ████████████████████████████████ ███████████ + ^ ^ ^^ ^^ ^ ^^ ^^^ ^^^^ ^ ^^ ^ ^ ^ + 2 1 23 21 3 43 234 2123 1 01 2 3 0 + +The ondisk reference count btree does not store the refcount == 0 cases because +the free space btree already records which blocks are free. +Extents being used to stage copy-on-write operations should be the only records +with refcount == 1. +Single-owner file blocks aren't recorded in either the free space or the +reference count btrees. + +The high level process to rebuild the reference count btree is: + +1. Walk the reverse mapping records to generate ``struct xfs_refcount_irec`` + records for any space having more than one reverse mapping and add them to + the xfarray. + Any records owned by ``XFS_RMAP_OWN_COW`` are also added to the xfarray + because these are extents allocated to stage a copy on write operation and + are tracked in the refcount btree. + + Use any records owned by ``XFS_RMAP_OWN_REFC`` to create a bitmap of old + refcount btree blocks. + +2. Sort the records in physical extent order, putting the CoW staging extents + at the end of the xfarray. + This matches the sorting order of records in the refcount btree. + +3. Use the ``xfs_btree_bload_compute_geometry`` function to compute the number + of blocks needed for the new tree. + +4. Allocate the number of blocks computed in the previous step. + +5. Use ``xfs_btree_bload`` to write the xfarray records to btree blocks and + generate the internal node blocks. + +6. Commit the location of new btree root block to the AGF. + +7. Reap the old btree blocks using the bitmap created in step 1. + +Details are as follows; the same algorithm is used by ``xfs_repair`` to +generate refcount information from reverse mapping records. + +- Until the reverse mapping btree runs out of records: + + - Retrieve the next record from the btree and put it in a bag. + + - Collect all records with the same starting block from the btree and put + them in the bag. + + - While the bag isn't empty: + + - Among the mappings in the bag, compute the lowest block number where the + reference count changes. + This position will be either the starting block number of the next + unprocessed reverse mapping or the next block after the shortest mapping + in the bag. + + - Remove all mappings from the bag that end at this position. + + - Collect all reverse mappings that start at this position from the btree + and put them in the bag. + + - If the size of the bag changed and is greater than one, create a new + refcount record associating the block number range that we just walked to + the size of the bag. + +The bag-like structure in this case is a type 2 xfarray as discussed in the +:ref:`xfarray access patterns<xfarray_access_patterns>` section. +Reverse mappings are added to the bag using ``xfarray_store_anywhere`` and +removed via ``xfarray_unset``. +Bag members are examined through ``xfarray_iter`` loops. + +The proposed patchset is the +`AG btree repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-ag-btrees>`_ +series. + +Case Study: Rebuilding File Fork Mapping Indices +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The high level process to rebuild a data/attr fork mapping btree is: + +1. Walk the reverse mapping records to generate ``struct xfs_bmbt_rec`` + records from the reverse mapping records for that inode and fork. + Append these records to an xfarray. + Compute the bitmap of the old bmap btree blocks from the ``BMBT_BLOCK`` + records. + +2. Use the ``xfs_btree_bload_compute_geometry`` function to compute the number + of blocks needed for the new tree. + +3. Sort the records in file offset order. + +4. If the extent records would fit in the inode fork immediate area, commit the + records to that immediate area and skip to step 8. + +5. Allocate the number of blocks computed in the previous step. + +6. Use ``xfs_btree_bload`` to write the xfarray records to btree blocks and + generate the internal node blocks. + +7. Commit the new btree root block to the inode fork immediate area. + +8. Reap the old btree blocks using the bitmap created in step 1. + +There are some complications here: +First, it's possible to move the fork offset to adjust the sizes of the +immediate areas if the data and attr forks are not both in BMBT format. +Second, if there are sufficiently few fork mappings, it may be possible to use +EXTENTS format instead of BMBT, which may require a conversion. +Third, the incore extent map must be reloaded carefully to avoid disturbing +any delayed allocation extents. + +The proposed patchset is the +`file mapping repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-file-mappings>`_ +series. + +.. _reaping: + +Reaping Old Metadata Blocks +--------------------------- + +Whenever online fsck builds a new data structure to replace one that is +suspect, there is a question of how to find and dispose of the blocks that +belonged to the old structure. +The laziest method of course is not to deal with them at all, but this slowly +leads to service degradations as space leaks out of the filesystem. +Hopefully, someone will schedule a rebuild of the free space information to +plug all those leaks. +Offline repair rebuilds all space metadata after recording the usage of +the files and directories that it decides not to clear, hence it can build new +structures in the discovered free space and avoid the question of reaping. + +As part of a repair, online fsck relies heavily on the reverse mapping records +to find space that is owned by the corresponding rmap owner yet truly free. +Cross referencing rmap records with other rmap records is necessary because +there may be other data structures that also think they own some of those +blocks (e.g. crosslinked trees). +Permitting the block allocator to hand them out again will not push the system +towards consistency. + +For space metadata, the process of finding extents to dispose of generally +follows this format: + +1. Create a bitmap of space used by data structures that must be preserved. + The space reservations used to create the new metadata can be used here if + the same rmap owner code is used to denote all of the objects being rebuilt. + +2. Survey the reverse mapping data to create a bitmap of space owned by the + same ``XFS_RMAP_OWN_*`` number for the metadata that is being preserved. + +3. Use the bitmap disunion operator to subtract (1) from (2). + The remaining set bits represent candidate extents that could be freed. + The process moves on to step 4 below. + +Repairs for file-based metadata such as extended attributes, directories, +symbolic links, quota files and realtime bitmaps are performed by building a +new structure attached to a temporary file and swapping the forks. +Afterward, the mappings in the old file fork are the candidate blocks for +disposal. + +The process for disposing of old extents is as follows: + +4. For each candidate extent, count the number of reverse mapping records for + the first block in that extent that do not have the same rmap owner for the + data structure being repaired. + + - If zero, the block has a single owner and can be freed. + + - If not, the block is part of a crosslinked structure and must not be + freed. + +5. Starting with the next block in the extent, figure out how many more blocks + have the same zero/nonzero other owner status as that first block. + +6. If the region is crosslinked, delete the reverse mapping entry for the + structure being repaired and move on to the next region. + +7. If the region is to be freed, mark any corresponding buffers in the buffer + cache as stale to prevent log writeback. + +8. Free the region and move on. + +However, there is one complication to this procedure. +Transactions are of finite size, so the reaping process must be careful to roll +the transactions to avoid overruns. +Overruns come from two sources: + +a. EFIs logged on behalf of space that is no longer occupied + +b. Log items for buffer invalidations + +This is also a window in which a crash during the reaping process can leak +blocks. +As stated earlier, online repair functions use very large transactions to +minimize the chances of this occurring. + +The proposed patchset is the +`preparation for bulk loading btrees +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-prep-for-bulk-loading>`_ +series. + +Case Study: Reaping After a Regular Btree Repair +```````````````````````````````````````````````` + +Old reference count and inode btrees are the easiest to reap because they have +rmap records with special owner codes: ``XFS_RMAP_OWN_REFC`` for the refcount +btree, and ``XFS_RMAP_OWN_INOBT`` for the inode and free inode btrees. +Creating a list of extents to reap the old btree blocks is quite simple, +conceptually: + +1. Lock the relevant AGI/AGF header buffers to prevent allocation and frees. + +2. For each reverse mapping record with an rmap owner corresponding to the + metadata structure being rebuilt, set the corresponding range in a bitmap. + +3. Walk the current data structures that have the same rmap owner. + For each block visited, clear that range in the above bitmap. + +4. Each set bit in the bitmap represents a block that could be a block from the + old data structures and hence is a candidate for reaping. + In other words, ``(rmap_records_owned_by & ~blocks_reachable_by_walk)`` + are the blocks that might be freeable. + +If it is possible to maintain the AGF lock throughout the repair (which is the +common case), then step 2 can be performed at the same time as the reverse +mapping record walk that creates the records for the new btree. + +Case Study: Rebuilding the Free Space Indices +````````````````````````````````````````````` + +The high level process to rebuild the free space indices is: + +1. Walk the reverse mapping records to generate ``struct xfs_alloc_rec_incore`` + records from the gaps in the reverse mapping btree. + +2. Append the records to an xfarray. + +3. Use the ``xfs_btree_bload_compute_geometry`` function to compute the number + of blocks needed for each new tree. + +4. Allocate the number of blocks computed in the previous step from the free + space information collected. + +5. Use ``xfs_btree_bload`` to write the xfarray records to btree blocks and + generate the internal node blocks for the free space by length index. + Call it again for the free space by block number index. + +6. Commit the locations of the new btree root blocks to the AGF. + +7. Reap the old btree blocks by looking for space that is not recorded by the + reverse mapping btree, the new free space btrees, or the AGFL. + +Repairing the free space btrees has three key complications over a regular +btree repair: + +First, free space is not explicitly tracked in the reverse mapping records. +Hence, the new free space records must be inferred from gaps in the physical +space component of the keyspace of the reverse mapping btree. + +Second, free space repairs cannot use the common btree reservation code because +new blocks are reserved out of the free space btrees. +This is impossible when repairing the free space btrees themselves. +However, repair holds the AGF buffer lock for the duration of the free space +index reconstruction, so it can use the collected free space information to +supply the blocks for the new free space btrees. +It is not necessary to back each reserved extent with an EFI because the new +free space btrees are constructed in what the ondisk filesystem thinks is +unowned space. +However, if reserving blocks for the new btrees from the collected free space +information changes the number of free space records, repair must re-estimate +the new free space btree geometry with the new record count until the +reservation is sufficient. +As part of committing the new btrees, repair must ensure that reverse mappings +are created for the reserved blocks and that unused reserved blocks are +inserted into the free space btrees. +Deferrred rmap and freeing operations are used to ensure that this transition +is atomic, similar to the other btree repair functions. + +Third, finding the blocks to reap after the repair is not overly +straightforward. +Blocks for the free space btrees and the reverse mapping btrees are supplied by +the AGFL. +Blocks put onto the AGFL have reverse mapping records with the owner +``XFS_RMAP_OWN_AG``. +This ownership is retained when blocks move from the AGFL into the free space +btrees or the reverse mapping btrees. +When repair walks reverse mapping records to synthesize free space records, it +creates a bitmap (``ag_owner_bitmap``) of all the space claimed by +``XFS_RMAP_OWN_AG`` records. +The repair context maintains a second bitmap corresponding to the rmap btree +blocks and the AGFL blocks (``rmap_agfl_bitmap``). +When the walk is complete, the bitmap disunion operation ``(ag_owner_bitmap & +~rmap_agfl_bitmap)`` computes the extents that are used by the old free space +btrees. +These blocks can then be reaped using the methods outlined above. + +The proposed patchset is the +`AG btree repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-ag-btrees>`_ +series. + +.. _rmap_reap: + +Case Study: Reaping After Repairing Reverse Mapping Btrees +`````````````````````````````````````````````````````````` + +Old reverse mapping btrees are less difficult to reap after a repair. +As mentioned in the previous section, blocks on the AGFL, the two free space +btree blocks, and the reverse mapping btree blocks all have reverse mapping +records with ``XFS_RMAP_OWN_AG`` as the owner. +The full process of gathering reverse mapping records and building a new btree +are described in the case study of +:ref:`live rebuilds of rmap data <rmap_repair>`, but a crucial point from that +discussion is that the new rmap btree will not contain any records for the old +rmap btree, nor will the old btree blocks be tracked in the free space btrees. +The list of candidate reaping blocks is computed by setting the bits +corresponding to the gaps in the new rmap btree records, and then clearing the +bits corresponding to extents in the free space btrees and the current AGFL +blocks. +The result ``(new_rmapbt_gaps & ~(agfl | bnobt_records))`` are reaped using the +methods outlined above. + +The rest of the process of rebuildng the reverse mapping btree is discussed +in a separate :ref:`case study<rmap_repair>`. + +The proposed patchset is the +`AG btree repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-ag-btrees>`_ +series. + +Case Study: Rebuilding the AGFL +``````````````````````````````` + +The allocation group free block list (AGFL) is repaired as follows: + +1. Create a bitmap for all the space that the reverse mapping data claims is + owned by ``XFS_RMAP_OWN_AG``. + +2. Subtract the space used by the two free space btrees and the rmap btree. + +3. Subtract any space that the reverse mapping data claims is owned by any + other owner, to avoid re-adding crosslinked blocks to the AGFL. + +4. Once the AGFL is full, reap any blocks leftover. + +5. The next operation to fix the freelist will right-size the list. + +See `fs/xfs/scrub/agheader_repair.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/xfs/scrub/agheader_repair.c>`_ for more details. + +Inode Record Repairs +-------------------- + +Inode records must be handled carefully, because they have both ondisk records +("dinodes") and an in-memory ("cached") representation. +There is a very high potential for cache coherency issues if online fsck is not +careful to access the ondisk metadata *only* when the ondisk metadata is so +badly damaged that the filesystem cannot load the in-memory representation. +When online fsck wants to open a damaged file for scrubbing, it must use +specialized resource acquisition functions that return either the in-memory +representation *or* a lock on whichever object is necessary to prevent any +update to the ondisk location. + +The only repairs that should be made to the ondisk inode buffers are whatever +is necessary to get the in-core structure loaded. +This means fixing whatever is caught by the inode cluster buffer and inode fork +verifiers, and retrying the ``iget`` operation. +If the second ``iget`` fails, the repair has failed. + +Once the in-memory representation is loaded, repair can lock the inode and can +subject it to comprehensive checks, repairs, and optimizations. +Most inode attributes are easy to check and constrain, or are user-controlled +arbitrary bit patterns; these are both easy to fix. +Dealing with the data and attr fork extent counts and the file block counts is +more complicated, because computing the correct value requires traversing the +forks, or if that fails, leaving the fields invalid and waiting for the fork +fsck functions to run. + +The proposed patchset is the +`inode +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-inodes>`_ +repair series. + +Quota Record Repairs +-------------------- + +Similar to inodes, quota records ("dquots") also have both ondisk records and +an in-memory representation, and hence are subject to the same cache coherency +issues. +Somewhat confusingly, both are known as dquots in the XFS codebase. + +The only repairs that should be made to the ondisk quota record buffers are +whatever is necessary to get the in-core structure loaded. +Once the in-memory representation is loaded, the only attributes needing +checking are obviously bad limits and timer values. + +Quota usage counters are checked, repaired, and discussed separately in the +section about :ref:`live quotacheck <quotacheck>`. + +The proposed patchset is the +`quota +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-quota>`_ +repair series. + +.. _fscounters: + +Freezing to Fix Summary Counters +-------------------------------- + +Filesystem summary counters track availability of filesystem resources such +as free blocks, free inodes, and allocated inodes. +This information could be compiled by walking the free space and inode indexes, +but this is a slow process, so XFS maintains a copy in the ondisk superblock +that should reflect the ondisk metadata, at least when the filesystem has been +unmounted cleanly. +For performance reasons, XFS also maintains incore copies of those counters, +which are key to enabling resource reservations for active transactions. +Writer threads reserve the worst-case quantities of resources from the +incore counter and give back whatever they don't use at commit time. +It is therefore only necessary to serialize on the superblock when the +superblock is being committed to disk. + +The lazy superblock counter feature introduced in XFS v5 took this even further +by training log recovery to recompute the summary counters from the AG headers, +which eliminated the need for most transactions even to touch the superblock. +The only time XFS commits the summary counters is at filesystem unmount. +To reduce contention even further, the incore counter is implemented as a +percpu counter, which means that each CPU is allocated a batch of blocks from a +global incore counter and can satisfy small allocations from the local batch. + +The high-performance nature of the summary counters makes it difficult for +online fsck to check them, since there is no way to quiesce a percpu counter +while the system is running. +Although online fsck can read the filesystem metadata to compute the correct +values of the summary counters, there's no way to hold the value of a percpu +counter stable, so it's quite possible that the counter will be out of date by +the time the walk is complete. +Earlier versions of online scrub would return to userspace with an incomplete +scan flag, but this is not a satisfying outcome for a system administrator. +For repairs, the in-memory counters must be stabilized while walking the +filesystem metadata to get an accurate reading and install it in the percpu +counter. + +To satisfy this requirement, online fsck must prevent other programs in the +system from initiating new writes to the filesystem, it must disable background +garbage collection threads, and it must wait for existing writer programs to +exit the kernel. +Once that has been established, scrub can walk the AG free space indexes, the +inode btrees, and the realtime bitmap to compute the correct value of all +four summary counters. +This is very similar to a filesystem freeze, though not all of the pieces are +necessary: + +- The final freeze state is set one higher than ``SB_FREEZE_COMPLETE`` to + prevent other threads from thawing the filesystem, or other scrub threads + from initiating another fscounters freeze. + +- It does not quiesce the log. + +With this code in place, it is now possible to pause the filesystem for just +long enough to check and correct the summary counters. + ++--------------------------------------------------------------------------+ +| **Historical Sidebar**: | ++--------------------------------------------------------------------------+ +| The initial implementation used the actual VFS filesystem freeze | +| mechanism to quiesce filesystem activity. | +| With the filesystem frozen, it is possible to resolve the counter values | +| with exact precision, but there are many problems with calling the VFS | +| methods directly: | +| | +| - Other programs can unfreeze the filesystem without our knowledge. | +| This leads to incorrect scan results and incorrect repairs. | +| | +| - Adding an extra lock to prevent others from thawing the filesystem | +| required the addition of a ``->freeze_super`` function to wrap | +| ``freeze_fs()``. | +| This in turn caused other subtle problems because it turns out that | +| the VFS ``freeze_super`` and ``thaw_super`` functions can drop the | +| last reference to the VFS superblock, and any subsequent access | +| becomes a UAF bug! | +| This can happen if the filesystem is unmounted while the underlying | +| block device has frozen the filesystem. | +| This problem could be solved by grabbing extra references to the | +| superblock, but it felt suboptimal given the other inadequacies of | +| this approach. | +| | +| - The log need not be quiesced to check the summary counters, but a VFS | +| freeze initiates one anyway. | +| This adds unnecessary runtime to live fscounter fsck operations. | +| | +| - Quiescing the log means that XFS flushes the (possibly incorrect) | +| counters to disk as part of cleaning the log. | +| | +| - A bug in the VFS meant that freeze could complete even when | +| sync_filesystem fails to flush the filesystem and returns an error. | +| This bug was fixed in Linux 5.17. | ++--------------------------------------------------------------------------+ + +The proposed patchset is the +`summary counter cleanup +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-fscounters>`_ +series. + +Full Filesystem Scans +--------------------- + +Certain types of metadata can only be checked by walking every file in the +entire filesystem to record observations and comparing the observations against +what's recorded on disk. +Like every other type of online repair, repairs are made by writing those +observations to disk in a replacement structure and committing it atomically. +However, it is not practical to shut down the entire filesystem to examine +hundreds of billions of files because the downtime would be excessive. +Therefore, online fsck must build the infrastructure to manage a live scan of +all the files in the filesystem. +There are two questions that need to be solved to perform a live walk: + +- How does scrub manage the scan while it is collecting data? + +- How does the scan keep abreast of changes being made to the system by other + threads? + +.. _iscan: + +Coordinated Inode Scans +``````````````````````` + +In the original Unix filesystems of the 1970s, each directory entry contained +an index number (*inumber*) which was used as an index into on ondisk array +(*itable*) of fixed-size records (*inodes*) describing a file's attributes and +its data block mapping. +This system is described by J. Lions, `"inode (5659)" +<http://www.lemis.com/grog/Documentation/Lions/>`_ in *Lions' Commentary on +UNIX, 6th Edition*, (Dept. of Computer Science, the University of New South +Wales, November 1977), pp. 18-2; and later by D. Ritchie and K. Thompson, +`"Implementation of the File System" +<https://archive.org/details/bstj57-6-1905/page/n8/mode/1up>`_, from *The UNIX +Time-Sharing System*, (The Bell System Technical Journal, July 1978), pp. +1913-4. + +XFS retains most of this design, except now inumbers are search keys over all +the space in the data section filesystem. +They form a continuous keyspace that can be expressed as a 64-bit integer, +though the inodes themselves are sparsely distributed within the keyspace. +Scans proceed in a linear fashion across the inumber keyspace, starting from +``0x0`` and ending at ``0xFFFFFFFFFFFFFFFF``. +Naturally, a scan through a keyspace requires a scan cursor object to track the +scan progress. +Because this keyspace is sparse, this cursor contains two parts. +The first part of this scan cursor object tracks the inode that will be +examined next; call this the examination cursor. +Somewhat less obviously, the scan cursor object must also track which parts of +the keyspace have already been visited, which is critical for deciding if a +concurrent filesystem update needs to be incorporated into the scan data. +Call this the visited inode cursor. + +Advancing the scan cursor is a multi-step process encapsulated in +``xchk_iscan_iter``: + +1. Lock the AGI buffer of the AG containing the inode pointed to by the visited + inode cursor. + This guarantee that inodes in this AG cannot be allocated or freed while + advancing the cursor. + +2. Use the per-AG inode btree to look up the next inumber after the one that + was just visited, since it may not be keyspace adjacent. + +3. If there are no more inodes left in this AG: + + a. Move the examination cursor to the point of the inumber keyspace that + corresponds to the start of the next AG. + + b. Adjust the visited inode cursor to indicate that it has "visited" the + last possible inode in the current AG's inode keyspace. + XFS inumbers are segmented, so the cursor needs to be marked as having + visited the entire keyspace up to just before the start of the next AG's + inode keyspace. + + c. Unlock the AGI and return to step 1 if there are unexamined AGs in the + filesystem. + + d. If there are no more AGs to examine, set both cursors to the end of the + inumber keyspace. + The scan is now complete. + +4. Otherwise, there is at least one more inode to scan in this AG: + + a. Move the examination cursor ahead to the next inode marked as allocated + by the inode btree. + + b. Adjust the visited inode cursor to point to the inode just prior to where + the examination cursor is now. + Because the scanner holds the AGI buffer lock, no inodes could have been + created in the part of the inode keyspace that the visited inode cursor + just advanced. + +5. Get the incore inode for the inumber of the examination cursor. + By maintaining the AGI buffer lock until this point, the scanner knows that + it was safe to advance the examination cursor across the entire keyspace, + and that it has stabilized this next inode so that it cannot disappear from + the filesystem until the scan releases the incore inode. + +6. Drop the AGI lock and return the incore inode to the caller. + +Online fsck functions scan all files in the filesystem as follows: + +1. Start a scan by calling ``xchk_iscan_start``. + +2. Advance the scan cursor (``xchk_iscan_iter``) to get the next inode. + If one is provided: + + a. Lock the inode to prevent updates during the scan. + + b. Scan the inode. + + c. While still holding the inode lock, adjust the visited inode cursor + (``xchk_iscan_mark_visited``) to point to this inode. + + d. Unlock and release the inode. + +8. Call ``xchk_iscan_teardown`` to complete the scan. + +There are subtleties with the inode cache that complicate grabbing the incore +inode for the caller. +Obviously, it is an absolute requirement that the inode metadata be consistent +enough to load it into the inode cache. +Second, if the incore inode is stuck in some intermediate state, the scan +coordinator must release the AGI and push the main filesystem to get the inode +back into a loadable state. + +The proposed patches are the +`inode scanner +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-iscan>`_ +series. +The first user of the new functionality is the +`online quotacheck +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-quotacheck>`_ +series. + +Inode Management +```````````````` + +In regular filesystem code, references to allocated XFS incore inodes are +always obtained (``xfs_iget``) outside of transaction context because the +creation of the incore context for an existing file does not require metadata +updates. +However, it is important to note that references to incore inodes obtained as +part of file creation must be performed in transaction context because the +filesystem must ensure the atomicity of the ondisk inode btree index updates +and the initialization of the actual ondisk inode. + +References to incore inodes are always released (``xfs_irele``) outside of +transaction context because there are a handful of activities that might +require ondisk updates: + +- The VFS may decide to kick off writeback as part of a ``DONTCACHE`` inode + release. + +- Speculative preallocations need to be unreserved. + +- An unlinked file may have lost its last reference, in which case the entire + file must be inactivated, which involves releasing all of its resources in + the ondisk metadata and freeing the inode. + +These activities are collectively called inode inactivation. +Inactivation has two parts -- the VFS part, which initiates writeback on all +dirty file pages, and the XFS part, which cleans up XFS-specific information +and frees the inode if it was unlinked. +If the inode is unlinked (or unconnected after a file handle operation), the +kernel drops the inode into the inactivation machinery immediately. + +During normal operation, resource acquisition for an update follows this order +to avoid deadlocks: + +1. Inode reference (``iget``). + +2. Filesystem freeze protection, if repairing (``mnt_want_write_file``). + +3. Inode ``IOLOCK`` (VFS ``i_rwsem``) lock to control file IO. + +4. Inode ``MMAPLOCK`` (page cache ``invalidate_lock``) lock for operations that + can update page cache mappings. + +5. Log feature enablement. + +6. Transaction log space grant. + +7. Space on the data and realtime devices for the transaction. + +8. Incore dquot references, if a file is being repaired. + Note that they are not locked, merely acquired. + +9. Inode ``ILOCK`` for file metadata updates. + +10. AG header buffer locks / Realtime metadata inode ILOCK. + +11. Realtime metadata buffer locks, if applicable. + +12. Extent mapping btree blocks, if applicable. + +Resources are often released in the reverse order, though this is not required. +However, online fsck differs from regular XFS operations because it may examine +an object that normally is acquired in a later stage of the locking order, and +then decide to cross-reference the object with an object that is acquired +earlier in the order. +The next few sections detail the specific ways in which online fsck takes care +to avoid deadlocks. + +iget and irele During a Scrub +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +An inode scan performed on behalf of a scrub operation runs in transaction +context, and possibly with resources already locked and bound to it. +This isn't much of a problem for ``iget`` since it can operate in the context +of an existing transaction, as long as all of the bound resources are acquired +before the inode reference in the regular filesystem. + +When the VFS ``iput`` function is given a linked inode with no other +references, it normally puts the inode on an LRU list in the hope that it can +save time if another process re-opens the file before the system runs out +of memory and frees it. +Filesystem callers can short-circuit the LRU process by setting a ``DONTCACHE`` +flag on the inode to cause the kernel to try to drop the inode into the +inactivation machinery immediately. + +In the past, inactivation was always done from the process that dropped the +inode, which was a problem for scrub because scrub may already hold a +transaction, and XFS does not support nesting transactions. +On the other hand, if there is no scrub transaction, it is desirable to drop +otherwise unused inodes immediately to avoid polluting caches. +To capture these nuances, the online fsck code has a separate ``xchk_irele`` +function to set or clear the ``DONTCACHE`` flag to get the required release +behavior. + +Proposed patchsets include fixing +`scrub iget usage +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-iget-fixes>`_ and +`dir iget usage +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-dir-iget-fixes>`_. + +.. _ilocking: + +Locking Inodes +^^^^^^^^^^^^^^ + +In regular filesystem code, the VFS and XFS will acquire multiple IOLOCK locks +in a well-known order: parent → child when updating the directory tree, and +in numerical order of the addresses of their ``struct inode`` object otherwise. +For regular files, the MMAPLOCK can be acquired after the IOLOCK to stop page +faults. +If two MMAPLOCKs must be acquired, they are acquired in numerical order of +the addresses of their ``struct address_space`` objects. +Due to the structure of existing filesystem code, IOLOCKs and MMAPLOCKs must be +acquired before transactions are allocated. +If two ILOCKs must be acquired, they are acquired in inumber order. + +Inode lock acquisition must be done carefully during a coordinated inode scan. +Online fsck cannot abide these conventions, because for a directory tree +scanner, the scrub process holds the IOLOCK of the file being scanned and it +needs to take the IOLOCK of the file at the other end of the directory link. +If the directory tree is corrupt because it contains a cycle, ``xfs_scrub`` +cannot use the regular inode locking functions and avoid becoming trapped in an +ABBA deadlock. + +Solving both of these problems is straightforward -- any time online fsck +needs to take a second lock of the same class, it uses trylock to avoid an ABBA +deadlock. +If the trylock fails, scrub drops all inode locks and use trylock loops to +(re)acquire all necessary resources. +Trylock loops enable scrub to check for pending fatal signals, which is how +scrub avoids deadlocking the filesystem or becoming an unresponsive process. +However, trylock loops means that online fsck must be prepared to measure the +resource being scrubbed before and after the lock cycle to detect changes and +react accordingly. + +.. _dirparent: + +Case Study: Finding a Directory Parent +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Consider the directory parent pointer repair code as an example. +Online fsck must verify that the dotdot dirent of a directory points up to a +parent directory, and that the parent directory contains exactly one dirent +pointing down to the child directory. +Fully validating this relationship (and repairing it if possible) requires a +walk of every directory on the filesystem while holding the child locked, and +while updates to the directory tree are being made. +The coordinated inode scan provides a way to walk the filesystem without the +possibility of missing an inode. +The child directory is kept locked to prevent updates to the dotdot dirent, but +if the scanner fails to lock a parent, it can drop and relock both the child +and the prospective parent. +If the dotdot entry changes while the directory is unlocked, then a move or +rename operation must have changed the child's parentage, and the scan can +exit early. + +The proposed patchset is the +`directory repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-dirs>`_ +series. + +.. _fshooks: + +Filesystem Hooks +````````````````` + +The second piece of support that online fsck functions need during a full +filesystem scan is the ability to stay informed about updates being made by +other threads in the filesystem, since comparisons against the past are useless +in a dynamic environment. +Two pieces of Linux kernel infrastructure enable online fsck to monitor regular +filesystem operations: filesystem hooks and :ref:`static keys<jump_labels>`. + +Filesystem hooks convey information about an ongoing filesystem operation to +a downstream consumer. +In this case, the downstream consumer is always an online fsck function. +Because multiple fsck functions can run in parallel, online fsck uses the Linux +notifier call chain facility to dispatch updates to any number of interested +fsck processes. +Call chains are a dynamic list, which means that they can be configured at +run time. +Because these hooks are private to the XFS module, the information passed along +contains exactly what the checking function needs to update its observations. + +The current implementation of XFS hooks uses SRCU notifier chains to reduce the +impact to highly threaded workloads. +Regular blocking notifier chains use a rwsem and seem to have a much lower +overhead for single-threaded applications. +However, it may turn out that the combination of blocking chains and static +keys are a more performant combination; more study is needed here. + +The following pieces are necessary to hook a certain point in the filesystem: + +- A ``struct xfs_hooks`` object must be embedded in a convenient place such as + a well-known incore filesystem object. + +- Each hook must define an action code and a structure containing more context + about the action. + +- Hook providers should provide appropriate wrapper functions and structs + around the ``xfs_hooks`` and ``xfs_hook`` objects to take advantage of type + checking to ensure correct usage. + +- A callsite in the regular filesystem code must be chosen to call + ``xfs_hooks_call`` with the action code and data structure. + This place should be adjacent to (and not earlier than) the place where + the filesystem update is committed to the transaction. + In general, when the filesystem calls a hook chain, it should be able to + handle sleeping and should not be vulnerable to memory reclaim or locking + recursion. + However, the exact requirements are very dependent on the context of the hook + caller and the callee. + +- The online fsck function should define a structure to hold scan data, a lock + to coordinate access to the scan data, and a ``struct xfs_hook`` object. + The scanner function and the regular filesystem code must acquire resources + in the same order; see the next section for details. + +- The online fsck code must contain a C function to catch the hook action code + and data structure. + If the object being updated has already been visited by the scan, then the + hook information must be applied to the scan data. + +- Prior to unlocking inodes to start the scan, online fsck must call + ``xfs_hooks_setup`` to initialize the ``struct xfs_hook``, and + ``xfs_hooks_add`` to enable the hook. + +- Online fsck must call ``xfs_hooks_del`` to disable the hook once the scan is + complete. + +The number of hooks should be kept to a minimum to reduce complexity. +Static keys are used to reduce the overhead of filesystem hooks to nearly +zero when online fsck is not running. + +.. _liveupdate: + +Live Updates During a Scan +`````````````````````````` + +The code paths of the online fsck scanning code and the :ref:`hooked<fshooks>` +filesystem code look like this:: + + other program + ↓ + inode lock â†â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â” + ↓ │ + AG header lock │ + ↓ │ + filesystem function │ + ↓ │ + notifier call chain │ same + ↓ ├─── inode + scrub hook function │ lock + ↓ │ + scan data mutex â†â”€â”€â” same │ + ↓ ├─── scan │ + update scan data │ lock │ + ↑ │ │ + scan data mutex â†â”€â”€â”˜ │ + ↑ │ + inode lock â†â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”˜ + ↑ + scrub function + ↑ + inode scanner + ↑ + xfs_scrub + +These rules must be followed to ensure correct interactions between the +checking code and the code making an update to the filesystem: + +- Prior to invoking the notifier call chain, the filesystem function being + hooked must acquire the same lock that the scrub scanning function acquires + to scan the inode. + +- The scanning function and the scrub hook function must coordinate access to + the scan data by acquiring a lock on the scan data. + +- Scrub hook function must not add the live update information to the scan + observations unless the inode being updated has already been scanned. + The scan coordinator has a helper predicate (``xchk_iscan_want_live_update``) + for this. + +- Scrub hook functions must not change the caller's state, including the + transaction that it is running. + They must not acquire any resources that might conflict with the filesystem + function being hooked. + +- The hook function can abort the inode scan to avoid breaking the other rules. + +The inode scan APIs are pretty simple: + +- ``xchk_iscan_start`` starts a scan + +- ``xchk_iscan_iter`` grabs a reference to the next inode in the scan or + returns zero if there is nothing left to scan + +- ``xchk_iscan_want_live_update`` to decide if an inode has already been + visited in the scan. + This is critical for hook functions to decide if they need to update the + in-memory scan information. + +- ``xchk_iscan_mark_visited`` to mark an inode as having been visited in the + scan + +- ``xchk_iscan_teardown`` to finish the scan + +This functionality is also a part of the +`inode scanner +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-iscan>`_ +series. + +.. _quotacheck: + +Case Study: Quota Counter Checking +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +It is useful to compare the mount time quotacheck code to the online repair +quotacheck code. +Mount time quotacheck does not have to contend with concurrent operations, so +it does the following: + +1. Make sure the ondisk dquots are in good enough shape that all the incore + dquots will actually load, and zero the resource usage counters in the + ondisk buffer. + +2. Walk every inode in the filesystem. + Add each file's resource usage to the incore dquot. + +3. Walk each incore dquot. + If the incore dquot is not being flushed, add the ondisk buffer backing the + incore dquot to a delayed write (delwri) list. + +4. Write the buffer list to disk. + +Like most online fsck functions, online quotacheck can't write to regular +filesystem objects until the newly collected metadata reflect all filesystem +state. +Therefore, online quotacheck records file resource usage to a shadow dquot +index implemented with a sparse ``xfarray``, and only writes to the real dquots +once the scan is complete. +Handling transactional updates is tricky because quota resource usage updates +are handled in phases to minimize contention on dquots: + +1. The inodes involved are joined and locked to a transaction. + +2. For each dquot attached to the file: + + a. The dquot is locked. + + b. A quota reservation is added to the dquot's resource usage. + The reservation is recorded in the transaction. + + c. The dquot is unlocked. + +3. Changes in actual quota usage are tracked in the transaction. + +4. At transaction commit time, each dquot is examined again: + + a. The dquot is locked again. + + b. Quota usage changes are logged and unused reservation is given back to + the dquot. + + c. The dquot is unlocked. + +For online quotacheck, hooks are placed in steps 2 and 4. +The step 2 hook creates a shadow version of the transaction dquot context +(``dqtrx``) that operates in a similar manner to the regular code. +The step 4 hook commits the shadow ``dqtrx`` changes to the shadow dquots. +Notice that both hooks are called with the inode locked, which is how the +live update coordinates with the inode scanner. + +The quotacheck scan looks like this: + +1. Set up a coordinated inode scan. + +2. For each inode returned by the inode scan iterator: + + a. Grab and lock the inode. + + b. Determine that inode's resource usage (data blocks, inode counts, + realtime blocks) and add that to the shadow dquots for the user, group, + and project ids associated with the inode. + + c. Unlock and release the inode. + +3. For each dquot in the system: + + a. Grab and lock the dquot. + + b. Check the dquot against the shadow dquots created by the scan and updated + by the live hooks. + +Live updates are key to being able to walk every quota record without +needing to hold any locks for a long duration. +If repairs are desired, the real and shadow dquots are locked and their +resource counts are set to the values in the shadow dquot. + +The proposed patchset is the +`online quotacheck +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-quotacheck>`_ +series. + +.. _nlinks: + +Case Study: File Link Count Checking +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +File link count checking also uses live update hooks. +The coordinated inode scanner is used to visit all directories on the +filesystem, and per-file link count records are stored in a sparse ``xfarray`` +indexed by inumber. +During the scanning phase, each entry in a directory generates observation +data as follows: + +1. If the entry is a dotdot (``'..'``) entry of the root directory, the + directory's parent link count is bumped because the root directory's dotdot + entry is self referential. + +2. If the entry is a dotdot entry of a subdirectory, the parent's backref + count is bumped. + +3. If the entry is neither a dot nor a dotdot entry, the target file's parent + count is bumped. + +4. If the target is a subdirectory, the parent's child link count is bumped. + +A crucial point to understand about how the link count inode scanner interacts +with the live update hooks is that the scan cursor tracks which *parent* +directories have been scanned. +In other words, the live updates ignore any update about ``A → B`` when A has +not been scanned, even if B has been scanned. +Furthermore, a subdirectory A with a dotdot entry pointing back to B is +accounted as a backref counter in the shadow data for A, since child dotdot +entries affect the parent's link count. +Live update hooks are carefully placed in all parts of the filesystem that +create, change, or remove directory entries, since those operations involve +bumplink and droplink. + +For any file, the correct link count is the number of parents plus the number +of child subdirectories. +Non-directories never have children of any kind. +The backref information is used to detect inconsistencies in the number of +links pointing to child subdirectories and the number of dotdot entries +pointing back. + +After the scan completes, the link count of each file can be checked by locking +both the inode and the shadow data, and comparing the link counts. +A second coordinated inode scan cursor is used for comparisons. +Live updates are key to being able to walk every inode without needing to hold +any locks between inodes. +If repairs are desired, the inode's link count is set to the value in the +shadow information. +If no parents are found, the file must be :ref:`reparented <orphanage>` to the +orphanage to prevent the file from being lost forever. + +The proposed patchset is the +`file link count repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=scrub-nlinks>`_ +series. + +.. _rmap_repair: + +Case Study: Rebuilding Reverse Mapping Records +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Most repair functions follow the same pattern: lock filesystem resources, +walk the surviving ondisk metadata looking for replacement metadata records, +and use an :ref:`in-memory array <xfarray>` to store the gathered observations. +The primary advantage of this approach is the simplicity and modularity of the +repair code -- code and data are entirely contained within the scrub module, +do not require hooks in the main filesystem, and are usually the most efficient +in memory use. +A secondary advantage of this repair approach is atomicity -- once the kernel +decides a structure is corrupt, no other threads can access the metadata until +the kernel finishes repairing and revalidating the metadata. + +For repairs going on within a shard of the filesystem, these advantages +outweigh the delays inherent in locking the shard while repairing parts of the +shard. +Unfortunately, repairs to the reverse mapping btree cannot use the "standard" +btree repair strategy because it must scan every space mapping of every fork of +every file in the filesystem, and the filesystem cannot stop. +Therefore, rmap repair foregoes atomicity between scrub and repair. +It combines a :ref:`coordinated inode scanner <iscan>`, :ref:`live update hooks +<liveupdate>`, and an :ref:`in-memory rmap btree <xfbtree>` to complete the +scan for reverse mapping records. + +1. Set up an xfbtree to stage rmap records. + +2. While holding the locks on the AGI and AGF buffers acquired during the + scrub, generate reverse mappings for all AG metadata: inodes, btrees, CoW + staging extents, and the internal log. + +3. Set up an inode scanner. + +4. Hook into rmap updates for the AG being repaired so that the live scan data + can receive updates to the rmap btree from the rest of the filesystem during + the file scan. + +5. For each space mapping found in either fork of each file scanned, + decide if the mapping matches the AG of interest. + If so: + + a. Create a btree cursor for the in-memory btree. + + b. Use the rmap code to add the record to the in-memory btree. + + c. Use the :ref:`special commit function <xfbtree_commit>` to write the + xfbtree changes to the xfile. + +6. For each live update received via the hook, decide if the owner has already + been scanned. + If so, apply the live update into the scan data: + + a. Create a btree cursor for the in-memory btree. + + b. Replay the operation into the in-memory btree. + + c. Use the :ref:`special commit function <xfbtree_commit>` to write the + xfbtree changes to the xfile. + This is performed with an empty transaction to avoid changing the + caller's state. + +7. When the inode scan finishes, create a new scrub transaction and relock the + two AG headers. + +8. Compute the new btree geometry using the number of rmap records in the + shadow btree, like all other btree rebuilding functions. + +9. Allocate the number of blocks computed in the previous step. + +10. Perform the usual btree bulk loading and commit to install the new rmap + btree. + +11. Reap the old rmap btree blocks as discussed in the case study about how + to :ref:`reap after rmap btree repair <rmap_reap>`. + +12. Free the xfbtree now that it not needed. + +The proposed patchset is the +`rmap repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-rmap-btree>`_ +series. + +Staging Repairs with Temporary Files on Disk +-------------------------------------------- + +XFS stores a substantial amount of metadata in file forks: directories, +extended attributes, symbolic link targets, free space bitmaps and summary +information for the realtime volume, and quota records. +File forks map 64-bit logical file fork space extents to physical storage space +extents, similar to how a memory management unit maps 64-bit virtual addresses +to physical memory addresses. +Therefore, file-based tree structures (such as directories and extended +attributes) use blocks mapped in the file fork offset address space that point +to other blocks mapped within that same address space, and file-based linear +structures (such as bitmaps and quota records) compute array element offsets in +the file fork offset address space. + +Because file forks can consume as much space as the entire filesystem, repairs +cannot be staged in memory, even when a paging scheme is available. +Therefore, online repair of file-based metadata createas a temporary file in +the XFS filesystem, writes a new structure at the correct offsets into the +temporary file, and atomically swaps the fork mappings (and hence the fork +contents) to commit the repair. +Once the repair is complete, the old fork can be reaped as necessary; if the +system goes down during the reap, the iunlink code will delete the blocks +during log recovery. + +**Note**: All space usage and inode indices in the filesystem *must* be +consistent to use a temporary file safely! +This dependency is the reason why online repair can only use pageable kernel +memory to stage ondisk space usage information. + +Swapping metadata extents with a temporary file requires the owner field of the +block headers to match the file being repaired and not the temporary file. The +directory, extended attribute, and symbolic link functions were all modified to +allow callers to specify owner numbers explicitly. + +There is a downside to the reaping process -- if the system crashes during the +reap phase and the fork extents are crosslinked, the iunlink processing will +fail because freeing space will find the extra reverse mappings and abort. + +Temporary files created for repair are similar to ``O_TMPFILE`` files created +by userspace. +They are not linked into a directory and the entire file will be reaped when +the last reference to the file is lost. +The key differences are that these files must have no access permission outside +the kernel at all, they must be specially marked to prevent them from being +opened by handle, and they must never be linked into the directory tree. + ++--------------------------------------------------------------------------+ +| **Historical Sidebar**: | ++--------------------------------------------------------------------------+ +| In the initial iteration of file metadata repair, the damaged metadata | +| blocks would be scanned for salvageable data; the extents in the file | +| fork would be reaped; and then a new structure would be built in its | +| place. | +| This strategy did not survive the introduction of the atomic repair | +| requirement expressed earlier in this document. | +| | +| The second iteration explored building a second structure at a high | +| offset in the fork from the salvage data, reaping the old extents, and | +| using a ``COLLAPSE_RANGE`` operation to slide the new extents into | +| place. | +| | +| This had many drawbacks: | +| | +| - Array structures are linearly addressed, and the regular filesystem | +| codebase does not have the concept of a linear offset that could be | +| applied to the record offset computation to build an alternate copy. | +| | +| - Extended attributes are allowed to use the entire attr fork offset | +| address space. | +| | +| - Even if repair could build an alternate copy of a data structure in a | +| different part of the fork address space, the atomic repair commit | +| requirement means that online repair would have to be able to perform | +| a log assisted ``COLLAPSE_RANGE`` operation to ensure that the old | +| structure was completely replaced. | +| | +| - A crash after construction of the secondary tree but before the range | +| collapse would leave unreachable blocks in the file fork. | +| This would likely confuse things further. | +| | +| - Reaping blocks after a repair is not a simple operation, and | +| initiating a reap operation from a restarted range collapse operation | +| during log recovery is daunting. | +| | +| - Directory entry blocks and quota records record the file fork offset | +| in the header area of each block. | +| An atomic range collapse operation would have to rewrite this part of | +| each block header. | +| Rewriting a single field in block headers is not a huge problem, but | +| it's something to be aware of. | +| | +| - Each block in a directory or extended attributes btree index contains | +| sibling and child block pointers. | +| Were the atomic commit to use a range collapse operation, each block | +| would have to be rewritten very carefully to preserve the graph | +| structure. | +| Doing this as part of a range collapse means rewriting a large number | +| of blocks repeatedly, which is not conducive to quick repairs. | +| | +| This lead to the introduction of temporary file staging. | ++--------------------------------------------------------------------------+ + +Using a Temporary File +`````````````````````` + +Online repair code should use the ``xrep_tempfile_create`` function to create a +temporary file inside the filesystem. +This allocates an inode, marks the in-core inode private, and attaches it to +the scrub context. +These files are hidden from userspace, may not be added to the directory tree, +and must be kept private. + +Temporary files only use two inode locks: the IOLOCK and the ILOCK. +The MMAPLOCK is not needed here, because there must not be page faults from +userspace for data fork blocks. +The usage patterns of these two locks are the same as for any other XFS file -- +access to file data are controlled via the IOLOCK, and access to file metadata +are controlled via the ILOCK. +Locking helpers are provided so that the temporary file and its lock state can +be cleaned up by the scrub context. +To comply with the nested locking strategy laid out in the :ref:`inode +locking<ilocking>` section, it is recommended that scrub functions use the +xrep_tempfile_ilock*_nowait lock helpers. + +Data can be written to a temporary file by two means: + +1. ``xrep_tempfile_copyin`` can be used to set the contents of a regular + temporary file from an xfile. + +2. The regular directory, symbolic link, and extended attribute functions can + be used to write to the temporary file. + +Once a good copy of a data file has been constructed in a temporary file, it +must be conveyed to the file being repaired, which is the topic of the next +section. + +The proposed patches are in the +`repair temporary files +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-tempfiles>`_ +series. + +Atomic Extent Swapping +---------------------- + +Once repair builds a temporary file with a new data structure written into +it, it must commit the new changes into the existing file. +It is not possible to swap the inumbers of two files, so instead the new +metadata must replace the old. +This suggests the need for the ability to swap extents, but the existing extent +swapping code used by the file defragmenting tool ``xfs_fsr`` is not sufficient +for online repair because: + +a. When the reverse-mapping btree is enabled, the swap code must keep the + reverse mapping information up to date with every exchange of mappings. + Therefore, it can only exchange one mapping per transaction, and each + transaction is independent. + +b. Reverse-mapping is critical for the operation of online fsck, so the old + defragmentation code (which swapped entire extent forks in a single + operation) is not useful here. + +c. Defragmentation is assumed to occur between two files with identical + contents. + For this use case, an incomplete exchange will not result in a user-visible + change in file contents, even if the operation is interrupted. + +d. Online repair needs to swap the contents of two files that are by definition + *not* identical. + For directory and xattr repairs, the user-visible contents might be the + same, but the contents of individual blocks may be very different. + +e. Old blocks in the file may be cross-linked with another structure and must + not reappear if the system goes down mid-repair. + +These problems are overcome by creating a new deferred operation and a new type +of log intent item to track the progress of an operation to exchange two file +ranges. +The new deferred operation type chains together the same transactions used by +the reverse-mapping extent swap code. +The new log item records the progress of the exchange to ensure that once an +exchange begins, it will always run to completion, even there are +interruptions. +The new ``XFS_SB_FEAT_INCOMPAT_LOG_ATOMIC_SWAP`` log-incompatible feature flag +in the superblock protects these new log item records from being replayed on +old kernels. + +The proposed patchset is the +`atomic extent swap +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=atomic-file-updates>`_ +series. + ++--------------------------------------------------------------------------+ +| **Sidebar: Using Log-Incompatible Feature Flags** | ++--------------------------------------------------------------------------+ +| Starting with XFS v5, the superblock contains a | +| ``sb_features_log_incompat`` field to indicate that the log contains | +| records that might not readable by all kernels that could mount this | +| filesystem. | +| In short, log incompat features protect the log contents against kernels | +| that will not understand the contents. | +| Unlike the other superblock feature bits, log incompat bits are | +| ephemeral because an empty (clean) log does not need protection. | +| The log cleans itself after its contents have been committed into the | +| filesystem, either as part of an unmount or because the system is | +| otherwise idle. | +| Because upper level code can be working on a transaction at the same | +| time that the log cleans itself, it is necessary for upper level code to | +| communicate to the log when it is going to use a log incompatible | +| feature. | +| | +| The log coordinates access to incompatible features through the use of | +| one ``struct rw_semaphore`` for each feature. | +| The log cleaning code tries to take this rwsem in exclusive mode to | +| clear the bit; if the lock attempt fails, the feature bit remains set. | +| Filesystem code signals its intention to use a log incompat feature in a | +| transaction by calling ``xlog_use_incompat_feat``, which takes the rwsem | +| in shared mode. | +| The code supporting a log incompat feature should create wrapper | +| functions to obtain the log feature and call | +| ``xfs_add_incompat_log_feature`` to set the feature bits in the primary | +| superblock. | +| The superblock update is performed transactionally, so the wrapper to | +| obtain log assistance must be called just prior to the creation of the | +| transaction that uses the functionality. | +| For a file operation, this step must happen after taking the IOLOCK | +| and the MMAPLOCK, but before allocating the transaction. | +| When the transaction is complete, the ``xlog_drop_incompat_feat`` | +| function is called to release the feature. | +| The feature bit will not be cleared from the superblock until the log | +| becomes clean. | +| | +| Log-assisted extended attribute updates and atomic extent swaps both use | +| log incompat features and provide convenience wrappers around the | +| functionality. | ++--------------------------------------------------------------------------+ + +Mechanics of an Atomic Extent Swap +`````````````````````````````````` + +Swapping entire file forks is a complex task. +The goal is to exchange all file fork mappings between two file fork offset +ranges. +There are likely to be many extent mappings in each fork, and the edges of +the mappings aren't necessarily aligned. +Furthermore, there may be other updates that need to happen after the swap, +such as exchanging file sizes, inode flags, or conversion of fork data to local +format. +This is roughly the format of the new deferred extent swap work item: + +.. code-block:: c + + struct xfs_swapext_intent { + /* Inodes participating in the operation. */ + struct xfs_inode *sxi_ip1; + struct xfs_inode *sxi_ip2; + + /* File offset range information. */ + xfs_fileoff_t sxi_startoff1; + xfs_fileoff_t sxi_startoff2; + xfs_filblks_t sxi_blockcount; + + /* Set these file sizes after the operation, unless negative. */ + xfs_fsize_t sxi_isize1; + xfs_fsize_t sxi_isize2; + + /* XFS_SWAP_EXT_* log operation flags */ + uint64_t sxi_flags; + }; + +The new log intent item contains enough information to track two logical fork +offset ranges: ``(inode1, startoff1, blockcount)`` and ``(inode2, startoff2, +blockcount)``. +Each step of a swap operation exchanges the largest file range mapping possible +from one file to the other. +After each step in the swap operation, the two startoff fields are incremented +and the blockcount field is decremented to reflect the progress made. +The flags field captures behavioral parameters such as swapping the attr fork +instead of the data fork and other work to be done after the extent swap. +The two isize fields are used to swap the file size at the end of the operation +if the file data fork is the target of the swap operation. + +When the extent swap is initiated, the sequence of operations is as follows: + +1. Create a deferred work item for the extent swap. + At the start, it should contain the entirety of the file ranges to be + swapped. + +2. Call ``xfs_defer_finish`` to process the exchange. + This is encapsulated in ``xrep_tempswap_contents`` for scrub operations. + This will log an extent swap intent item to the transaction for the deferred + extent swap work item. + +3. Until ``sxi_blockcount`` of the deferred extent swap work item is zero, + + a. Read the block maps of both file ranges starting at ``sxi_startoff1`` and + ``sxi_startoff2``, respectively, and compute the longest extent that can + be swapped in a single step. + This is the minimum of the two ``br_blockcount`` s in the mappings. + Keep advancing through the file forks until at least one of the mappings + contains written blocks. + Mutual holes, unwritten extents, and extent mappings to the same physical + space are not exchanged. + + For the next few steps, this document will refer to the mapping that came + from file 1 as "map1", and the mapping that came from file 2 as "map2". + + b. Create a deferred block mapping update to unmap map1 from file 1. + + c. Create a deferred block mapping update to unmap map2 from file 2. + + d. Create a deferred block mapping update to map map1 into file 2. + + e. Create a deferred block mapping update to map map2 into file 1. + + f. Log the block, quota, and extent count updates for both files. + + g. Extend the ondisk size of either file if necessary. + + h. Log an extent swap done log item for the extent swap intent log item + that was read at the start of step 3. + + i. Compute the amount of file range that has just been covered. + This quantity is ``(map1.br_startoff + map1.br_blockcount - + sxi_startoff1)``, because step 3a could have skipped holes. + + j. Increase the starting offsets of ``sxi_startoff1`` and ``sxi_startoff2`` + by the number of blocks computed in the previous step, and decrease + ``sxi_blockcount`` by the same quantity. + This advances the cursor. + + k. Log a new extent swap intent log item reflecting the advanced state of + the work item. + + l. Return the proper error code (EAGAIN) to the deferred operation manager + to inform it that there is more work to be done. + The operation manager completes the deferred work in steps 3b-3e before + moving back to the start of step 3. + +4. Perform any post-processing. + This will be discussed in more detail in subsequent sections. + +If the filesystem goes down in the middle of an operation, log recovery will +find the most recent unfinished extent swap log intent item and restart from +there. +This is how extent swapping guarantees that an outside observer will either see +the old broken structure or the new one, and never a mismash of both. + +Preparation for Extent Swapping +``````````````````````````````` + +There are a few things that need to be taken care of before initiating an +atomic extent swap operation. +First, regular files require the page cache to be flushed to disk before the +operation begins, and directio writes to be quiesced. +Like any filesystem operation, extent swapping must determine the maximum +amount of disk space and quota that can be consumed on behalf of both files in +the operation, and reserve that quantity of resources to avoid an unrecoverable +out of space failure once it starts dirtying metadata. +The preparation step scans the ranges of both files to estimate: + +- Data device blocks needed to handle the repeated updates to the fork + mappings. +- Change in data and realtime block counts for both files. +- Increase in quota usage for both files, if the two files do not share the + same set of quota ids. +- The number of extent mappings that will be added to each file. +- Whether or not there are partially written realtime extents. + User programs must never be able to access a realtime file extent that maps + to different extents on the realtime volume, which could happen if the + operation fails to run to completion. + +The need for precise estimation increases the run time of the swap operation, +but it is very important to maintain correct accounting. +The filesystem must not run completely out of free space, nor can the extent +swap ever add more extent mappings to a fork than it can support. +Regular users are required to abide the quota limits, though metadata repairs +may exceed quota to resolve inconsistent metadata elsewhere. + +Special Features for Swapping Metadata File Extents +``````````````````````````````````````````````````` + +Extended attributes, symbolic links, and directories can set the fork format to +"local" and treat the fork as a literal area for data storage. +Metadata repairs must take extra steps to support these cases: + +- If both forks are in local format and the fork areas are large enough, the + swap is performed by copying the incore fork contents, logging both forks, + and committing. + The atomic extent swap mechanism is not necessary, since this can be done + with a single transaction. + +- If both forks map blocks, then the regular atomic extent swap is used. + +- Otherwise, only one fork is in local format. + The contents of the local format fork are converted to a block to perform the + swap. + The conversion to block format must be done in the same transaction that + logs the initial extent swap intent log item. + The regular atomic extent swap is used to exchange the mappings. + Special flags are set on the swap operation so that the transaction can be + rolled one more time to convert the second file's fork back to local format + so that the second file will be ready to go as soon as the ILOCK is dropped. + +Extended attributes and directories stamp the owning inode into every block, +but the buffer verifiers do not actually check the inode number! +Although there is no verification, it is still important to maintain +referential integrity, so prior to performing the extent swap, online repair +builds every block in the new data structure with the owner field of the file +being repaired. + +After a successful swap operation, the repair operation must reap the old fork +blocks by processing each fork mapping through the standard :ref:`file extent +reaping <reaping>` mechanism that is done post-repair. +If the filesystem should go down during the reap part of the repair, the +iunlink processing at the end of recovery will free both the temporary file and +whatever blocks were not reaped. +However, this iunlink processing omits the cross-link detection of online +repair, and is not completely foolproof. + +Swapping Temporary File Extents +``````````````````````````````` + +To repair a metadata file, online repair proceeds as follows: + +1. Create a temporary repair file. + +2. Use the staging data to write out new contents into the temporary repair + file. + The same fork must be written to as is being repaired. + +3. Commit the scrub transaction, since the swap estimation step must be + completed before transaction reservations are made. + +4. Call ``xrep_tempswap_trans_alloc`` to allocate a new scrub transaction with + the appropriate resource reservations, locks, and fill out a ``struct + xfs_swapext_req`` with the details of the swap operation. + +5. Call ``xrep_tempswap_contents`` to swap the contents. + +6. Commit the transaction to complete the repair. + +.. _rtsummary: + +Case Study: Repairing the Realtime Summary File +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In the "realtime" section of an XFS filesystem, free space is tracked via a +bitmap, similar to Unix FFS. +Each bit in the bitmap represents one realtime extent, which is a multiple of +the filesystem block size between 4KiB and 1GiB in size. +The realtime summary file indexes the number of free extents of a given size to +the offset of the block within the realtime free space bitmap where those free +extents begin. +In other words, the summary file helps the allocator find free extents by +length, similar to what the free space by count (cntbt) btree does for the data +section. + +The summary file itself is a flat file (with no block headers or checksums!) +partitioned into ``log2(total rt extents)`` sections containing enough 32-bit +counters to match the number of blocks in the rt bitmap. +Each counter records the number of free extents that start in that bitmap block +and can satisfy a power-of-two allocation request. + +To check the summary file against the bitmap: + +1. Take the ILOCK of both the realtime bitmap and summary files. + +2. For each free space extent recorded in the bitmap: + + a. Compute the position in the summary file that contains a counter that + represents this free extent. + + b. Read the counter from the xfile. + + c. Increment it, and write it back to the xfile. + +3. Compare the contents of the xfile against the ondisk file. + +To repair the summary file, write the xfile contents into the temporary file +and use atomic extent swap to commit the new contents. +The temporary file is then reaped. + +The proposed patchset is the +`realtime summary repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-rtsummary>`_ +series. + +Case Study: Salvaging Extended Attributes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In XFS, extended attributes are implemented as a namespaced name-value store. +Values are limited in size to 64KiB, but there is no limit in the number of +names. +The attribute fork is unpartitioned, which means that the root of the attribute +structure is always in logical block zero, but attribute leaf blocks, dabtree +index blocks, and remote value blocks are intermixed. +Attribute leaf blocks contain variable-sized records that associate +user-provided names with the user-provided values. +Values larger than a block are allocated separate extents and written there. +If the leaf information expands beyond a single block, a directory/attribute +btree (``dabtree``) is created to map hashes of attribute names to entries +for fast lookup. + +Salvaging extended attributes is done as follows: + +1. Walk the attr fork mappings of the file being repaired to find the attribute + leaf blocks. + When one is found, + + a. Walk the attr leaf block to find candidate keys. + When one is found, + + 1. Check the name for problems, and ignore the name if there are. + + 2. Retrieve the value. + If that succeeds, add the name and value to the staging xfarray and + xfblob. + +2. If the memory usage of the xfarray and xfblob exceed a certain amount of + memory or there are no more attr fork blocks to examine, unlock the file and + add the staged extended attributes to the temporary file. + +3. Use atomic extent swapping to exchange the new and old extended attribute + structures. + The old attribute blocks are now attached to the temporary file. + +4. Reap the temporary file. + +The proposed patchset is the +`extended attribute repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-xattrs>`_ +series. + +Fixing Directories +------------------ + +Fixing directories is difficult with currently available filesystem features, +since directory entries are not redundant. +The offline repair tool scans all inodes to find files with nonzero link count, +and then it scans all directories to establish parentage of those linked files. +Damaged files and directories are zapped, and files with no parent are +moved to the ``/lost+found`` directory. +It does not try to salvage anything. + +The best that online repair can do at this time is to read directory data +blocks and salvage any dirents that look plausible, correct link counts, and +move orphans back into the directory tree. +The salvage process is discussed in the case study at the end of this section. +The :ref:`file link count fsck <nlinks>` code takes care of fixing link counts +and moving orphans to the ``/lost+found`` directory. + +Case Study: Salvaging Directories +````````````````````````````````` + +Unlike extended attributes, directory blocks are all the same size, so +salvaging directories is straightforward: + +1. Find the parent of the directory. + If the dotdot entry is not unreadable, try to confirm that the alleged + parent has a child entry pointing back to the directory being repaired. + Otherwise, walk the filesystem to find it. + +2. Walk the first partition of data fork of the directory to find the directory + entry data blocks. + When one is found, + + a. Walk the directory data block to find candidate entries. + When an entry is found: + + i. Check the name for problems, and ignore the name if there are. + + ii. Retrieve the inumber and grab the inode. + If that succeeds, add the name, inode number, and file type to the + staging xfarray and xblob. + +3. If the memory usage of the xfarray and xfblob exceed a certain amount of + memory or there are no more directory data blocks to examine, unlock the + directory and add the staged dirents into the temporary directory. + Truncate the staging files. + +4. Use atomic extent swapping to exchange the new and old directory structures. + The old directory blocks are now attached to the temporary file. + +5. Reap the temporary file. + +**Future Work Question**: Should repair revalidate the dentry cache when +rebuilding a directory? + +*Answer*: Yes, it should. + +In theory it is necessary to scan all dentry cache entries for a directory to +ensure that one of the following apply: + +1. The cached dentry reflects an ondisk dirent in the new directory. + +2. The cached dentry no longer has a corresponding ondisk dirent in the new + directory and the dentry can be purged from the cache. + +3. The cached dentry no longer has an ondisk dirent but the dentry cannot be + purged. + This is the problem case. + +Unfortunately, the current dentry cache design doesn't provide a means to walk +every child dentry of a specific directory, which makes this a hard problem. +There is no known solution. + +The proposed patchset is the +`directory repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-dirs>`_ +series. + +Parent Pointers +``````````````` + +A parent pointer is a piece of file metadata that enables a user to locate the +file's parent directory without having to traverse the directory tree from the +root. +Without them, reconstruction of directory trees is hindered in much the same +way that the historic lack of reverse space mapping information once hindered +reconstruction of filesystem space metadata. +The parent pointer feature, however, makes total directory reconstruction +possible. + +XFS parent pointers include the dirent name and location of the entry within +the parent directory. +In other words, child files use extended attributes to store pointers to +parents in the form ``(parent_inum, parent_gen, dirent_pos) → (dirent_name)``. +The directory checking process can be strengthened to ensure that the target of +each dirent also contains a parent pointer pointing back to the dirent. +Likewise, each parent pointer can be checked by ensuring that the target of +each parent pointer is a directory and that it contains a dirent matching +the parent pointer. +Both online and offline repair can use this strategy. + +**Note**: The ondisk format of parent pointers is not yet finalized. + ++--------------------------------------------------------------------------+ +| **Historical Sidebar**: | ++--------------------------------------------------------------------------+ +| Directory parent pointers were first proposed as an XFS feature more | +| than a decade ago by SGI. | +| Each link from a parent directory to a child file is mirrored with an | +| extended attribute in the child that could be used to identify the | +| parent directory. | +| Unfortunately, this early implementation had major shortcomings and was | +| never merged into Linux XFS: | +| | +| 1. The XFS codebase of the late 2000s did not have the infrastructure to | +| enforce strong referential integrity in the directory tree. | +| It did not guarantee that a change in a forward link would always be | +| followed up with the corresponding change to the reverse links. | +| | +| 2. Referential integrity was not integrated into offline repair. | +| Checking and repairs were performed on mounted filesystems without | +| taking any kernel or inode locks to coordinate access. | +| It is not clear how this actually worked properly. | +| | +| 3. The extended attribute did not record the name of the directory entry | +| in the parent, so the SGI parent pointer implementation cannot be | +| used to reconnect the directory tree. | +| | +| 4. Extended attribute forks only support 65,536 extents, which means | +| that parent pointer attribute creation is likely to fail at some | +| point before the maximum file link count is achieved. | +| | +| The original parent pointer design was too unstable for something like | +| a file system repair to depend on. | +| Allison Henderson, Chandan Babu, and Catherine Hoang are working on a | +| second implementation that solves all shortcomings of the first. | +| During 2022, Allison introduced log intent items to track physical | +| manipulations of the extended attribute structures. | +| This solves the referential integrity problem by making it possible to | +| commit a dirent update and a parent pointer update in the same | +| transaction. | +| Chandan increased the maximum extent counts of both data and attribute | +| forks, thereby ensuring that the extended attribute structure can grow | +| to handle the maximum hardlink count of any file. | ++--------------------------------------------------------------------------+ + +Case Study: Repairing Directories with Parent Pointers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Directory rebuilding uses a :ref:`coordinated inode scan <iscan>` and +a :ref:`directory entry live update hook <liveupdate>` as follows: + +1. Set up a temporary directory for generating the new directory structure, + an xfblob for storing entry names, and an xfarray for stashing directory + updates. + +2. Set up an inode scanner and hook into the directory entry code to receive + updates on directory operations. + +3. For each parent pointer found in each file scanned, decide if the parent + pointer references the directory of interest. + If so: + + a. Stash an addname entry for this dirent in the xfarray for later. + + b. When finished scanning that file, flush the stashed updates to the + temporary directory. + +4. For each live directory update received via the hook, decide if the child + has already been scanned. + If so: + + a. Stash an addname or removename entry for this dirent update in the + xfarray for later. + We cannot write directly to the temporary directory because hook + functions are not allowed to modify filesystem metadata. + Instead, we stash updates in the xfarray and rely on the scanner thread + to apply the stashed updates to the temporary directory. + +5. When the scan is complete, atomically swap the contents of the temporary + directory and the directory being repaired. + The temporary directory now contains the damaged directory structure. + +6. Reap the temporary directory. + +7. Update the dirent position field of parent pointers as necessary. + This may require the queuing of a substantial number of xattr log intent + items. + +The proposed patchset is the +`parent pointers directory repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=pptrs-online-dir-repair>`_ +series. + +**Unresolved Question**: How will repair ensure that the ``dirent_pos`` fields +match in the reconstructed directory? + +*Answer*: There are a few ways to solve this problem: + +1. The field could be designated advisory, since the other three values are + sufficient to find the entry in the parent. + However, this makes indexed key lookup impossible while repairs are ongoing. + +2. We could allow creating directory entries at specified offsets, which solves + the referential integrity problem but runs the risk that dirent creation + will fail due to conflicts with the free space in the directory. + + These conflicts could be resolved by appending the directory entry and + amending the xattr code to support updating an xattr key and reindexing the + dabtree, though this would have to be performed with the parent directory + still locked. + +3. Same as above, but remove the old parent pointer entry and add a new one + atomically. + +4. Change the ondisk xattr format to ``(parent_inum, name) → (parent_gen)``, + which would provide the attr name uniqueness that we require, without + forcing repair code to update the dirent position. + Unfortunately, this requires changes to the xattr code to support attr + names as long as 263 bytes. + +5. Change the ondisk xattr format to ``(parent_inum, hash(name)) → + (name, parent_gen)``. + If the hash is sufficiently resistant to collisions (e.g. sha256) then + this should provide the attr name uniqueness that we require. + Names shorter than 247 bytes could be stored directly. + +Discussion is ongoing under the `parent pointers patch deluge +<https://www.spinics.net/lists/linux-xfs/msg69397.html>`_. + +Case Study: Repairing Parent Pointers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Online reconstruction of a file's parent pointer information works similarly to +directory reconstruction: + +1. Set up a temporary file for generating a new extended attribute structure, + an `xfblob<xfblob>` for storing parent pointer names, and an xfarray for + stashing parent pointer updates. + +2. Set up an inode scanner and hook into the directory entry code to receive + updates on directory operations. + +3. For each directory entry found in each directory scanned, decide if the + dirent references the file of interest. + If so: + + a. Stash an addpptr entry for this parent pointer in the xfblob and xfarray + for later. + + b. When finished scanning the directory, flush the stashed updates to the + temporary directory. + +4. For each live directory update received via the hook, decide if the parent + has already been scanned. + If so: + + a. Stash an addpptr or removepptr entry for this dirent update in the + xfarray for later. + We cannot write parent pointers directly to the temporary file because + hook functions are not allowed to modify filesystem metadata. + Instead, we stash updates in the xfarray and rely on the scanner thread + to apply the stashed parent pointer updates to the temporary file. + +5. Copy all non-parent pointer extended attributes to the temporary file. + +6. When the scan is complete, atomically swap the attribute fork of the + temporary file and the file being repaired. + The temporary file now contains the damaged extended attribute structure. + +7. Reap the temporary file. + +The proposed patchset is the +`parent pointers repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=pptrs-online-parent-repair>`_ +series. + +Digression: Offline Checking of Parent Pointers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Examining parent pointers in offline repair works differently because corrupt +files are erased long before directory tree connectivity checks are performed. +Parent pointer checks are therefore a second pass to be added to the existing +connectivity checks: + +1. After the set of surviving files has been established (i.e. phase 6), + walk the surviving directories of each AG in the filesystem. + This is already performed as part of the connectivity checks. + +2. For each directory entry found, record the name in an xfblob, and store + ``(child_ag_inum, parent_inum, parent_gen, dirent_pos)`` tuples in a + per-AG in-memory slab. + +3. For each AG in the filesystem, + + a. Sort the per-AG tuples in order of child_ag_inum, parent_inum, and + dirent_pos. + + b. For each inode in the AG, + + 1. Scan the inode for parent pointers. + Record the names in a per-file xfblob, and store ``(parent_inum, + parent_gen, dirent_pos)`` tuples in a per-file slab. + + 2. Sort the per-file tuples in order of parent_inum, and dirent_pos. + + 3. Position one slab cursor at the start of the inode's records in the + per-AG tuple slab. + This should be trivial since the per-AG tuples are in child inumber + order. + + 4. Position a second slab cursor at the start of the per-file tuple slab. + + 5. Iterate the two cursors in lockstep, comparing the parent_ino and + dirent_pos fields of the records under each cursor. + + a. Tuples in the per-AG list but not the per-file list are missing and + need to be written to the inode. + + b. Tuples in the per-file list but not the per-AG list are dangling + and need to be removed from the inode. + + c. For tuples in both lists, update the parent_gen and name components + of the parent pointer if necessary. + +4. Move on to examining link counts, as we do today. + +The proposed patchset is the +`offline parent pointers repair +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=pptrs-repair>`_ +series. + +Rebuilding directories from parent pointers in offline repair is very +challenging because it currently uses a single-pass scan of the filesystem +during phase 3 to decide which files are corrupt enough to be zapped. +This scan would have to be converted into a multi-pass scan: + +1. The first pass of the scan zaps corrupt inodes, forks, and attributes + much as it does now. + Corrupt directories are noted but not zapped. + +2. The next pass records parent pointers pointing to the directories noted + as being corrupt in the first pass. + This second pass may have to happen after the phase 4 scan for duplicate + blocks, if phase 4 is also capable of zapping directories. + +3. The third pass resets corrupt directories to an empty shortform directory. + Free space metadata has not been ensured yet, so repair cannot yet use the + directory building code in libxfs. + +4. At the start of phase 6, space metadata have been rebuilt. + Use the parent pointer information recorded during step 2 to reconstruct + the dirents and add them to the now-empty directories. + +This code has not yet been constructed. + +.. _orphanage: + +The Orphanage +------------- + +Filesystems present files as a directed, and hopefully acyclic, graph. +In other words, a tree. +The root of the filesystem is a directory, and each entry in a directory points +downwards either to more subdirectories or to non-directory files. +Unfortunately, a disruption in the directory graph pointers result in a +disconnected graph, which makes files impossible to access via regular path +resolution. + +Without parent pointers, the directory parent pointer online scrub code can +detect a dotdot entry pointing to a parent directory that doesn't have a link +back to the child directory and the file link count checker can detect a file +that isn't pointed to by any directory in the filesystem. +If such a file has a positive link count, the file is an orphan. + +With parent pointers, directories can be rebuilt by scanning parent pointers +and parent pointers can be rebuilt by scanning directories. +This should reduce the incidence of files ending up in ``/lost+found``. + +When orphans are found, they should be reconnected to the directory tree. +Offline fsck solves the problem by creating a directory ``/lost+found`` to +serve as an orphanage, and linking orphan files into the orphanage by using the +inumber as the name. +Reparenting a file to the orphanage does not reset any of its permissions or +ACLs. + +This process is more involved in the kernel than it is in userspace. +The directory and file link count repair setup functions must use the regular +VFS mechanisms to create the orphanage directory with all the necessary +security attributes and dentry cache entries, just like a regular directory +tree modification. + +Orphaned files are adopted by the orphanage as follows: + +1. Call ``xrep_orphanage_try_create`` at the start of the scrub setup function + to try to ensure that the lost and found directory actually exists. + This also attaches the orphanage directory to the scrub context. + +2. If the decision is made to reconnect a file, take the IOLOCK of both the + orphanage and the file being reattached. + The ``xrep_orphanage_iolock_two`` function follows the inode locking + strategy discussed earlier. + +3. Call ``xrep_orphanage_compute_blkres`` and ``xrep_orphanage_compute_name`` + to compute the new name in the orphanage and the block reservation required. + +4. Use ``xrep_orphanage_adoption_prep`` to reserve resources to the repair + transaction. + +5. Call ``xrep_orphanage_adopt`` to reparent the orphaned file into the lost + and found, and update the kernel dentry cache. + +The proposed patches are in the +`orphanage adoption +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=repair-orphanage>`_ +series. + +6. Userspace Algorithms and Data Structures +=========================================== + +This section discusses the key algorithms and data structures of the userspace +program, ``xfs_scrub``, that provide the ability to drive metadata checks and +repairs in the kernel, verify file data, and look for other potential problems. + +.. _scrubcheck: + +Checking Metadata +----------------- + +Recall the :ref:`phases of fsck work<scrubphases>` outlined earlier. +That structure follows naturally from the data dependencies designed into the +filesystem from its beginnings in 1993. +In XFS, there are several groups of metadata dependencies: + +a. Filesystem summary counts depend on consistency within the inode indices, + the allocation group space btrees, and the realtime volume space + information. + +b. Quota resource counts depend on consistency within the quota file data + forks, inode indices, inode records, and the forks of every file on the + system. + +c. The naming hierarchy depends on consistency within the directory and + extended attribute structures. + This includes file link counts. + +d. Directories, extended attributes, and file data depend on consistency within + the file forks that map directory and extended attribute data to physical + storage media. + +e. The file forks depends on consistency within inode records and the space + metadata indices of the allocation groups and the realtime volume. + This includes quota and realtime metadata files. + +f. Inode records depends on consistency within the inode metadata indices. + +g. Realtime space metadata depend on the inode records and data forks of the + realtime metadata inodes. + +h. The allocation group metadata indices (free space, inodes, reference count, + and reverse mapping btrees) depend on consistency within the AG headers and + between all the AG metadata btrees. + +i. ``xfs_scrub`` depends on the filesystem being mounted and kernel support + for online fsck functionality. + +Therefore, a metadata dependency graph is a convenient way to schedule checking +operations in the ``xfs_scrub`` program: + +- Phase 1 checks that the provided path maps to an XFS filesystem and detect + the kernel's scrubbing abilities, which validates group (i). + +- Phase 2 scrubs groups (g) and (h) in parallel using a threaded workqueue. + +- Phase 3 scans inodes in parallel. + For each inode, groups (f), (e), and (d) are checked, in that order. + +- Phase 4 repairs everything in groups (i) through (d) so that phases 5 and 6 + may run reliably. + +- Phase 5 starts by checking groups (b) and (c) in parallel before moving on + to checking names. + +- Phase 6 depends on groups (i) through (b) to find file data blocks to verify, + to read them, and to report which blocks of which files are affected. + +- Phase 7 checks group (a), having validated everything else. + +Notice that the data dependencies between groups are enforced by the structure +of the program flow. + +Parallel Inode Scans +-------------------- + +An XFS filesystem can easily contain hundreds of millions of inodes. +Given that XFS targets installations with large high-performance storage, +it is desirable to scrub inodes in parallel to minimize runtime, particularly +if the program has been invoked manually from a command line. +This requires careful scheduling to keep the threads as evenly loaded as +possible. + +Early iterations of the ``xfs_scrub`` inode scanner naïvely created a single +workqueue and scheduled a single workqueue item per AG. +Each workqueue item walked the inode btree (with ``XFS_IOC_INUMBERS``) to find +inode chunks and then called bulkstat (``XFS_IOC_BULKSTAT``) to gather enough +information to construct file handles. +The file handle was then passed to a function to generate scrub items for each +metadata object of each inode. +This simple algorithm leads to thread balancing problems in phase 3 if the +filesystem contains one AG with a few large sparse files and the rest of the +AGs contain many smaller files. +The inode scan dispatch function was not sufficiently granular; it should have +been dispatching at the level of individual inodes, or, to constrain memory +consumption, inode btree records. + +Thanks to Dave Chinner, bounded workqueues in userspace enable ``xfs_scrub`` to +avoid this problem with ease by adding a second workqueue. +Just like before, the first workqueue is seeded with one workqueue item per AG, +and it uses INUMBERS to find inode btree chunks. +The second workqueue, however, is configured with an upper bound on the number +of items that can be waiting to be run. +Each inode btree chunk found by the first workqueue's workers are queued to the +second workqueue, and it is this second workqueue that queries BULKSTAT, +creates a file handle, and passes it to a function to generate scrub items for +each metadata object of each inode. +If the second workqueue is too full, the workqueue add function blocks the +first workqueue's workers until the backlog eases. +This doesn't completely solve the balancing problem, but reduces it enough to +move on to more pressing issues. + +The proposed patchsets are the scrub +`performance tweaks +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=scrub-performance-tweaks>`_ +and the +`inode scan rebalance +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=scrub-iscan-rebalance>`_ +series. + +.. _scrubrepair: + +Scheduling Repairs +------------------ + +During phase 2, corruptions and inconsistencies reported in any AGI header or +inode btree are repaired immediately, because phase 3 relies on proper +functioning of the inode indices to find inodes to scan. +Failed repairs are rescheduled to phase 4. +Problems reported in any other space metadata are deferred to phase 4. +Optimization opportunities are always deferred to phase 4, no matter their +origin. + +During phase 3, corruptions and inconsistencies reported in any part of a +file's metadata are repaired immediately if all space metadata were validated +during phase 2. +Repairs that fail or cannot be repaired immediately are scheduled for phase 4. + +In the original design of ``xfs_scrub``, it was thought that repairs would be +so infrequent that the ``struct xfs_scrub_metadata`` objects used to +communicate with the kernel could also be used as the primary object to +schedule repairs. +With recent increases in the number of optimizations possible for a given +filesystem object, it became much more memory-efficient to track all eligible +repairs for a given filesystem object with a single repair item. +Each repair item represents a single lockable object -- AGs, metadata files, +individual inodes, or a class of summary information. + +Phase 4 is responsible for scheduling a lot of repair work in as quick a +manner as is practical. +The :ref:`data dependencies <scrubcheck>` outlined earlier still apply, which +means that ``xfs_scrub`` must try to complete the repair work scheduled by +phase 2 before trying repair work scheduled by phase 3. +The repair process is as follows: + +1. Start a round of repair with a workqueue and enough workers to keep the CPUs + as busy as the user desires. + + a. For each repair item queued by phase 2, + + i. Ask the kernel to repair everything listed in the repair item for a + given filesystem object. + + ii. Make a note if the kernel made any progress in reducing the number + of repairs needed for this object. + + iii. If the object no longer requires repairs, revalidate all metadata + associated with this object. + If the revalidation succeeds, drop the repair item. + If not, requeue the item for more repairs. + + b. If any repairs were made, jump back to 1a to retry all the phase 2 items. + + c. For each repair item queued by phase 3, + + i. Ask the kernel to repair everything listed in the repair item for a + given filesystem object. + + ii. Make a note if the kernel made any progress in reducing the number + of repairs needed for this object. + + iii. If the object no longer requires repairs, revalidate all metadata + associated with this object. + If the revalidation succeeds, drop the repair item. + If not, requeue the item for more repairs. + + d. If any repairs were made, jump back to 1c to retry all the phase 3 items. + +2. If step 1 made any repair progress of any kind, jump back to step 1 to start + another round of repair. + +3. If there are items left to repair, run them all serially one more time. + Complain if the repairs were not successful, since this is the last chance + to repair anything. + +Corruptions and inconsistencies encountered during phases 5 and 7 are repaired +immediately. +Corrupt file data blocks reported by phase 6 cannot be recovered by the +filesystem. + +The proposed patchsets are the +`repair warning improvements +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=scrub-better-repair-warnings>`_, +refactoring of the +`repair data dependency +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=scrub-repair-data-deps>`_ +and +`object tracking +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=scrub-object-tracking>`_, +and the +`repair scheduling +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=scrub-repair-scheduling>`_ +improvement series. + +Checking Names for Confusable Unicode Sequences +----------------------------------------------- + +If ``xfs_scrub`` succeeds in validating the filesystem metadata by the end of +phase 4, it moves on to phase 5, which checks for suspicious looking names in +the filesystem. +These names consist of the filesystem label, names in directory entries, and +the names of extended attributes. +Like most Unix filesystems, XFS imposes the sparest of constraints on the +contents of a name: + +- Slashes and null bytes are not allowed in directory entries. + +- Null bytes are not allowed in userspace-visible extended attributes. + +- Null bytes are not allowed in the filesystem label. + +Directory entries and attribute keys store the length of the name explicitly +ondisk, which means that nulls are not name terminators. +For this section, the term "naming domain" refers to any place where names are +presented together -- all the names in a directory, or all the attributes of a +file. + +Although the Unix naming constraints are very permissive, the reality of most +modern-day Linux systems is that programs work with Unicode character code +points to support international languages. +These programs typically encode those code points in UTF-8 when interfacing +with the C library because the kernel expects null-terminated names. +In the common case, therefore, names found in an XFS filesystem are actually +UTF-8 encoded Unicode data. + +To maximize its expressiveness, the Unicode standard defines separate control +points for various characters that render similarly or identically in writing +systems around the world. +For example, the character "Cyrillic Small Letter A" U+0430 "а" often renders +identically to "Latin Small Letter A" U+0061 "a". + +The standard also permits characters to be constructed in multiple ways -- +either by using a defined code point, or by combining one code point with +various combining marks. +For example, the character "Angstrom Sign U+212B "â„«" can also be expressed +as "Latin Capital Letter A" U+0041 "A" followed by "Combining Ring Above" +U+030A "◌̊". +Both sequences render identically. + +Like the standards that preceded it, Unicode also defines various control +characters to alter the presentation of text. +For example, the character "Right-to-Left Override" U+202E can trick some +programs into rendering "moo\\xe2\\x80\\xaegnp.txt" as "mootxt.png". +A second category of rendering problems involves whitespace characters. +If the character "Zero Width Space" U+200B is encountered in a file name, the +name will render identically to a name that does not have the zero width +space. + +If two names within a naming domain have different byte sequences but render +identically, a user may be confused by it. +The kernel, in its indifference to upper level encoding schemes, permits this. +Most filesystem drivers persist the byte sequence names that are given to them +by the VFS. + +Techniques for detecting confusable names are explained in great detail in +sections 4 and 5 of the +`Unicode Security Mechanisms <https://unicode.org/reports/tr39/>`_ +document. +When ``xfs_scrub`` detects UTF-8 encoding in use on a system, it uses the +Unicode normalization form NFD in conjunction with the confusable name +detection component of +`libicu <https://github.com/unicode-org/icu>`_ +to identify names with a directory or within a file's extended attributes that +could be confused for each other. +Names are also checked for control characters, non-rendering characters, and +mixing of bidirectional characters. +All of these potential issues are reported to the system administrator during +phase 5. + +Media Verification of File Data Extents +--------------------------------------- + +The system administrator can elect to initiate a media scan of all file data +blocks. +This scan after validation of all filesystem metadata (except for the summary +counters) as phase 6. +The scan starts by calling ``FS_IOC_GETFSMAP`` to scan the filesystem space map +to find areas that are allocated to file data fork extents. +Gaps betweeen data fork extents that are smaller than 64k are treated as if +they were data fork extents to reduce the command setup overhead. +When the space map scan accumulates a region larger than 32MB, a media +verification request is sent to the disk as a directio read of the raw block +device. + +If the verification read fails, ``xfs_scrub`` retries with single-block reads +to narrow down the failure to the specific region of the media and recorded. +When it has finished issuing verification requests, it again uses the space +mapping ioctl to map the recorded media errors back to metadata structures +and report what has been lost. +For media errors in blocks owned by files, parent pointers can be used to +construct file paths from inode numbers for user-friendly reporting. + +7. Conclusion and Future Work +============================= + +It is hoped that the reader of this document has followed the designs laid out +in this document and now has some familiarity with how XFS performs online +rebuilding of its metadata indices, and how filesystem users can interact with +that functionality. +Although the scope of this work is daunting, it is hoped that this guide will +make it easier for code readers to understand what has been built, for whom it +has been built, and why. +Please feel free to contact the XFS mailing list with questions. + +FIEXCHANGE_RANGE +---------------- + +As discussed earlier, a second frontend to the atomic extent swap mechanism is +a new ioctl call that userspace programs can use to commit updates to files +atomically. +This frontend has been out for review for several years now, though the +necessary refinements to online repair and lack of customer demand mean that +the proposal has not been pushed very hard. + +Extent Swapping with Regular User Files +``````````````````````````````````````` + +As mentioned earlier, XFS has long had the ability to swap extents between +files, which is used almost exclusively by ``xfs_fsr`` to defragment files. +The earliest form of this was the fork swap mechanism, where the entire +contents of data forks could be exchanged between two files by exchanging the +raw bytes in each inode fork's immediate area. +When XFS v5 came along with self-describing metadata, this old mechanism grew +some log support to continue rewriting the owner fields of BMBT blocks during +log recovery. +When the reverse mapping btree was later added to XFS, the only way to maintain +the consistency of the fork mappings with the reverse mapping index was to +develop an iterative mechanism that used deferred bmap and rmap operations to +swap mappings one at a time. +This mechanism is identical to steps 2-3 from the procedure above except for +the new tracking items, because the atomic extent swap mechanism is an +iteration of an existing mechanism and not something totally novel. +For the narrow case of file defragmentation, the file contents must be +identical, so the recovery guarantees are not much of a gain. + +Atomic extent swapping is much more flexible than the existing swapext +implementations because it can guarantee that the caller never sees a mix of +old and new contents even after a crash, and it can operate on two arbitrary +file fork ranges. +The extra flexibility enables several new use cases: + +- **Atomic commit of file writes**: A userspace process opens a file that it + wants to update. + Next, it opens a temporary file and calls the file clone operation to reflink + the first file's contents into the temporary file. + Writes to the original file should instead be written to the temporary file. + Finally, the process calls the atomic extent swap system call + (``FIEXCHANGE_RANGE``) to exchange the file contents, thereby committing all + of the updates to the original file, or none of them. + +.. _swapext_if_unchanged: + +- **Transactional file updates**: The same mechanism as above, but the caller + only wants the commit to occur if the original file's contents have not + changed. + To make this happen, the calling process snapshots the file modification and + change timestamps of the original file before reflinking its data to the + temporary file. + When the program is ready to commit the changes, it passes the timestamps + into the kernel as arguments to the atomic extent swap system call. + The kernel only commits the changes if the provided timestamps match the + original file. + +- **Emulation of atomic block device writes**: Export a block device with a + logical sector size matching the filesystem block size to force all writes + to be aligned to the filesystem block size. + Stage all writes to a temporary file, and when that is complete, call the + atomic extent swap system call with a flag to indicate that holes in the + temporary file should be ignored. + This emulates an atomic device write in software, and can support arbitrary + scattered writes. + +Vectorized Scrub +---------------- + +As it turns out, the :ref:`refactoring <scrubrepair>` of repair items mentioned +earlier was a catalyst for enabling a vectorized scrub system call. +Since 2018, the cost of making a kernel call has increased considerably on some +systems to mitigate the effects of speculative execution attacks. +This incentivizes program authors to make as few system calls as possible to +reduce the number of times an execution path crosses a security boundary. + +With vectorized scrub, userspace pushes to the kernel the identity of a +filesystem object, a list of scrub types to run against that object, and a +simple representation of the data dependencies between the selected scrub +types. +The kernel executes as much of the caller's plan as it can until it hits a +dependency that cannot be satisfied due to a corruption, and tells userspace +how much was accomplished. +It is hoped that ``io_uring`` will pick up enough of this functionality that +online fsck can use that instead of adding a separate vectored scrub system +call to XFS. + +The relevant patchsets are the +`kernel vectorized scrub +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=vectorized-scrub>`_ +and +`userspace vectorized scrub +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=vectorized-scrub>`_ +series. + +Quality of Service Targets for Scrub +------------------------------------ + +One serious shortcoming of the online fsck code is that the amount of time that +it can spend in the kernel holding resource locks is basically unbounded. +Userspace is allowed to send a fatal signal to the process which will cause +``xfs_scrub`` to exit when it reaches a good stopping point, but there's no way +for userspace to provide a time budget to the kernel. +Given that the scrub codebase has helpers to detect fatal signals, it shouldn't +be too much work to allow userspace to specify a timeout for a scrub/repair +operation and abort the operation if it exceeds budget. +However, most repair functions have the property that once they begin to touch +ondisk metadata, the operation cannot be cancelled cleanly, after which a QoS +timeout is no longer useful. + +Defragmenting Free Space +------------------------ + +Over the years, many XFS users have requested the creation of a program to +clear a portion of the physical storage underlying a filesystem so that it +becomes a contiguous chunk of free space. +Call this free space defragmenter ``clearspace`` for short. + +The first piece the ``clearspace`` program needs is the ability to read the +reverse mapping index from userspace. +This already exists in the form of the ``FS_IOC_GETFSMAP`` ioctl. +The second piece it needs is a new fallocate mode +(``FALLOC_FL_MAP_FREE_SPACE``) that allocates the free space in a region and +maps it to a file. +Call this file the "space collector" file. +The third piece is the ability to force an online repair. + +To clear all the metadata out of a portion of physical storage, clearspace +uses the new fallocate map-freespace call to map any free space in that region +to the space collector file. +Next, clearspace finds all metadata blocks in that region by way of +``GETFSMAP`` and issues forced repair requests on the data structure. +This often results in the metadata being rebuilt somewhere that is not being +cleared. +After each relocation, clearspace calls the "map free space" function again to +collect any newly freed space in the region being cleared. + +To clear all the file data out of a portion of the physical storage, clearspace +uses the FSMAP information to find relevant file data blocks. +Having identified a good target, it uses the ``FICLONERANGE`` call on that part +of the file to try to share the physical space with a dummy file. +Cloning the extent means that the original owners cannot overwrite the +contents; any changes will be written somewhere else via copy-on-write. +Clearspace makes its own copy of the frozen extent in an area that is not being +cleared, and uses ``FIEDEUPRANGE`` (or the :ref:`atomic extent swap +<swapext_if_unchanged>` feature) to change the target file's data extent +mapping away from the area being cleared. +When all other mappings have been moved, clearspace reflinks the space into the +space collector file so that it becomes unavailable. + +There are further optimizations that could apply to the above algorithm. +To clear a piece of physical storage that has a high sharing factor, it is +strongly desirable to retain this sharing factor. +In fact, these extents should be moved first to maximize sharing factor after +the operation completes. +To make this work smoothly, clearspace needs a new ioctl +(``FS_IOC_GETREFCOUNTS``) to report reference count information to userspace. +With the refcount information exposed, clearspace can quickly find the longest, +most shared data extents in the filesystem, and target them first. + +**Future Work Question**: How might the filesystem move inode chunks? + +*Answer*: To move inode chunks, Dave Chinner constructed a prototype program +that creates a new file with the old contents and then locklessly runs around +the filesystem updating directory entries. +The operation cannot complete if the filesystem goes down. +That problem isn't totally insurmountable: create an inode remapping table +hidden behind a jump label, and a log item that tracks the kernel walking the +filesystem to update directory entries. +The trouble is, the kernel can't do anything about open files, since it cannot +revoke them. + +**Future Work Question**: Can static keys be used to minimize the cost of +supporting ``revoke()`` on XFS files? + +*Answer*: Yes. +Until the first revocation, the bailout code need not be in the call path at +all. + +The relevant patchsets are the +`kernel freespace defrag +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=defrag-freespace>`_ +and +`userspace freespace defrag +<https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=defrag-freespace>`_ +series. + +Shrinking Filesystems +--------------------- + +Removing the end of the filesystem ought to be a simple matter of evacuating +the data and metadata at the end of the filesystem, and handing the freed space +to the shrink code. +That requires an evacuation of the space at end of the filesystem, which is a +use of free space defragmentation! diff --git a/Documentation/filesystems/xfs-self-describing-metadata.rst b/Documentation/filesystems/xfs-self-describing-metadata.rst index b79dbf36dc94..a10c4ae6955e 100644 --- a/Documentation/filesystems/xfs-self-describing-metadata.rst +++ b/Documentation/filesystems/xfs-self-describing-metadata.rst @@ -1,4 +1,5 @@ .. SPDX-License-Identifier: GPL-2.0 +.. _xfs_self_describing_metadata: ============================ XFS Self Describing Metadata diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index b9dc0c603f36..56d9913a3370 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -19,7 +19,7 @@ possible we decided to do following: platform devices. - Devices behind real busses where there is a connector resource - are represented as struct spi_device or struct i2c_device. Note + are represented as struct spi_device or struct i2c_client. Note that standard UARTs are not busses so there is no struct uart_device, although some of them may be represented by struct serdev_device. diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst b/Documentation/gpu/amdgpu/display/display-manager.rst index b7abb18cfc82..be2651ecdd7f 100644 --- a/Documentation/gpu/amdgpu/display/display-manager.rst +++ b/Documentation/gpu/amdgpu/display/display-manager.rst @@ -173,7 +173,7 @@ The alpha blending equation is configured from DRM to DC interface by the following path: 1. When updating a :c:type:`drm_plane_state <drm_plane_state>`, DM calls - :c:type:`fill_blending_from_plane_state()` that maps + :c:type:`amdgpu_dm_plane_fill_blending_from_plane_state()` that maps :c:type:`drm_plane_state <drm_plane_state>` attributes to :c:type:`dc_plane_info <dc_plane_info>` struct to be handled in the OS-agnostic component (DC). diff --git a/Documentation/hwmon/acbel-fsg032.rst b/Documentation/hwmon/acbel-fsg032.rst new file mode 100644 index 000000000000..f1684b95e103 --- /dev/null +++ b/Documentation/hwmon/acbel-fsg032.rst @@ -0,0 +1,80 @@ +Kernel driver acbel-fsg032 +========================== + +Supported chips: + + * ACBEL FSG032-00xG power supply. + +Author: Lakshmi Yadlapati <lakshmiy@us.ibm.com> + +Description +----------- + +This driver supports ACBEL FSG032-00xG Power Supply. This driver +is a client to the core PMBus driver. + +Usage Notes +----------- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for +details. + +Sysfs entries +------------- + +The following attributes are supported: + +======================= ====================================================== +curr1_crit Critical maximum current. +curr1_crit_alarm Input current critical alarm. +curr1_input Measured output current. +curr1_label "iin" +curr1_max Maximum input current. +curr1_max_alarm Maximum input current high alarm. +curr1_rated_max Maximum rated input current. +curr2_crit Critical maximum current. +curr2_crit_alarm Output current critical alarm. +curr2_input Measured output current. +curr2_label "iout1" +curr2_max Maximum output current. +curr2_max_alarm Output current high alarm. +curr2_rated_max Maximum rated output current. + + +fan1_alarm Fan 1 warning. +fan1_fault Fan 1 fault. +fan1_input Fan 1 speed in RPM. +fan1_target Set fan speed reference. + +in1_alarm Input voltage under-voltage alarm. +in1_input Measured input voltage. +in1_label "vin" +in1_rated_max Maximum rated input voltage. +in1_rated_min Minimum rated input voltage. +in2_crit Critical maximum output voltage. +in2_crit_alarm Output voltage critical high alarm. +in2_input Measured output voltage. +in2_label "vout1" +in2_lcrit Critical minimum output voltage. +in2_lcrit_alarm Output voltage critical low alarm. +in2_rated_max Maximum rated output voltage. +in2_rated_min Minimum rated output voltage. + +power1_alarm Input fault or alarm. +power1_input Measured input power. +power1_label "pin" +power1_max Input power limit. +power1_rated_max Maximum rated input power. +power2_crit Critical output power limit. +power2_crit_alarm Output power crit alarm limit exceeded. +power2_input Measured output power. +power2_label "pout" +power2_max Output power limit. +power2_max_alarm Output power high alarm. +power2_rated_max Maximum rated output power. + +temp[1-3]_input Measured temperature. +temp[1-2]_max Maximum temperature. +temp[1-3]_rated_max Temperature high alarm. +======================= ====================================================== diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst index 7d0d015b1a52..14b37851af0c 100644 --- a/Documentation/hwmon/aquacomputer_d5next.rst +++ b/Documentation/hwmon/aquacomputer_d5next.rst @@ -12,6 +12,7 @@ Supported devices: * Aquacomputer Octo fan controller * Aquacomputer Quadro fan controller * Aquacomputer High Flow Next sensor +* Aquacomputer Aquastream XT watercooling pump * Aquacomputer Aquastream Ultimate watercooling pump * Aquacomputer Poweradjust 3 fan controller @@ -25,7 +26,8 @@ communicate through proprietary USB HID protocols. The Aquaero devices expose eight physical, eight virtual and four calculated virtual temperature sensors, as well as two flow sensors. The fans expose their -speed (in RPM), power, voltage and current. +speed (in RPM), power, voltage and current. Temperature offsets and fan speeds +can be controlled. For the D5 Next pump, available sensors are pump and fan speed, power, voltage and current, as well as coolant temperature and eight virtual temp sensors. Also @@ -55,6 +57,10 @@ The High Flow Next exposes +5V voltages, water quality, conductivity and flow re A temperature sensor can be connected to it, in which case it provides its reading and an estimation of the dissipated/absorbed power in the liquid cooling loop. +The Aquastream XT pump exposes temperature readings for the coolant, external sensor +and fan IC. It also exposes pump and fan speeds (in RPM), voltages, as well as pump +current. + The Aquastream Ultimate pump exposes coolant temp and an external temp sensor, along with speed, power, voltage and current of both the pump and optionally connected fan. It also exposes pressure and flow speed readings. @@ -75,7 +81,7 @@ Sysfs entries ================ ============================================================== temp[1-20]_input Physical/virtual temperature sensors (in millidegrees Celsius) -temp[1-4]_offset Temperature sensor correction offset (in millidegrees Celsius) +temp[1-8]_offset Temperature sensor correction offset (in millidegrees Celsius) fan[1-8]_input Pump/fan speed (in RPM) / Flow speed (in dL/h) fan5_pulses Quadro flow sensor pulses power[1-8]_input Pump/fan power (in micro Watts) diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst index a4039f2f9ca4..c92c1d3839e4 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -8,6 +8,7 @@ Supported boards: * PRIME X570-PRO * Pro WS X570-ACE * ProArt X570-CREATOR WIFI + * ProArt B550-CREATOR * ROG CROSSHAIR VIII DARK HERO * ROG CROSSHAIR VIII HERO (WI-FI) * ROG CROSSHAIR VIII FORMULA @@ -21,6 +22,7 @@ Supported boards: * ROG STRIX X570-E GAMING WIFI II * ROG STRIX X570-F GAMING * ROG STRIX X570-I GAMING + * ROG STRIX Z390-F GAMING * ROG STRIX Z690-A GAMING WIFI D4 * ROG ZENITH II EXTREME * ROG ZENITH II EXTREME ALPHA diff --git a/Documentation/hwmon/ftsteutates.rst b/Documentation/hwmon/ftsteutates.rst index b3bfec36661d..2abd16830c99 100644 --- a/Documentation/hwmon/ftsteutates.rst +++ b/Documentation/hwmon/ftsteutates.rst @@ -36,7 +36,7 @@ correct path to the alarm file:: echo 0 >XXXX_alarm -Specification of the chip can be found here: +Specifications of the chip can be found at the `Kontron FTP Server <http://ftp.kontron.com/>`_ (username = "anonymous", no password required) +under the following path: -- ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf -- ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf + /Services/Software_Tools/Linux_SystemMonitoring_Watchdog_GPIO/BMC-Teutates_Specification_V1.21.pdf diff --git a/Documentation/hwmon/hwmon-kernel-api.rst b/Documentation/hwmon/hwmon-kernel-api.rst index 5451a6d4c874..c2d1e0299d8d 100644 --- a/Documentation/hwmon/hwmon-kernel-api.rst +++ b/Documentation/hwmon/hwmon-kernel-api.rst @@ -19,21 +19,11 @@ also read Documentation/hwmon/submitting-patches.rst. The API ------- -Each hardware monitoring driver must #include <linux/hwmon.h> and, in most +Each hardware monitoring driver must #include <linux/hwmon.h> and, in some cases, <linux/hwmon-sysfs.h>. linux/hwmon.h declares the following register/unregister functions:: struct device * - hwmon_device_register_with_groups(struct device *dev, const char *name, - void *drvdata, - const struct attribute_group **groups); - - struct device * - devm_hwmon_device_register_with_groups(struct device *dev, - const char *name, void *drvdata, - const struct attribute_group **groups); - - struct device * hwmon_device_register_with_info(struct device *dev, const char *name, void *drvdata, const struct hwmon_chip_info *info, @@ -54,46 +44,30 @@ register/unregister functions:: char *devm_hwmon_sanitize_name(struct device *dev, const char *name); -hwmon_device_register_with_groups registers a hardware monitoring device. -The first parameter of this function is a pointer to the parent device. -The name parameter is a pointer to the hwmon device name. The registration -function will create a name sysfs attribute pointing to this name. -The drvdata parameter is the pointer to the local driver data. -hwmon_device_register_with_groups will attach this pointer to the newly -allocated hwmon device. The pointer can be retrieved by the driver using -dev_get_drvdata() on the hwmon device pointer. The groups parameter is -a pointer to a list of sysfs attribute groups. The list must be NULL terminated. -hwmon_device_register_with_groups creates the hwmon device with name attribute -as well as all sysfs attributes attached to the hwmon device. -This function returns a pointer to the newly created hardware monitoring device -or PTR_ERR for failure. - -devm_hwmon_device_register_with_groups is similar to -hwmon_device_register_with_groups. However, it is device managed, meaning the -hwmon device does not have to be removed explicitly by the removal function. - -hwmon_device_register_with_info is the most comprehensive and preferred means -to register a hardware monitoring device. It creates the standard sysfs -attributes in the hardware monitoring core, letting the driver focus on reading -from and writing to the chip instead of having to bother with sysfs attributes. -The parent device parameter as well as the chip parameter must not be NULL. Its -parameters are described in more detail below. +hwmon_device_register_with_info registers a hardware monitoring device. +It creates the standard sysfs attributes in the hardware monitoring core, +letting the driver focus on reading from and writing to the chip instead +of having to bother with sysfs attributes. The parent device parameter +as well as the chip parameter must not be NULL. Its parameters are described +in more detail below. devm_hwmon_device_register_with_info is similar to hwmon_device_register_with_info. However, it is device managed, meaning the hwmon device does not have to be removed explicitly by the removal function. +All other hardware monitoring device registration functions are deprecated +and must not be used in new drivers. + hwmon_device_unregister deregisters a registered hardware monitoring device. The parameter of this function is the pointer to the registered hardware monitoring device structure. This function must be called from the driver remove function if the hardware monitoring device was registered with -hwmon_device_register_with_groups or hwmon_device_register_with_info. +hwmon_device_register_with_info. devm_hwmon_device_unregister does not normally have to be called. It is only needed for error handling, and only needed if the driver probe fails after -the call to devm_hwmon_device_register_with_groups or -hwmon_device_register_with_info and if the automatic (device managed) -removal would be too late. +the call to hwmon_device_register_with_info and if the automatic (device +managed) removal would be too late. All supported hwmon device registration functions only accept valid device names. Device names including invalid characters (whitespace, '*', or '-') @@ -133,7 +107,7 @@ The hwmon_chip_info structure looks as follows:: struct hwmon_chip_info { const struct hwmon_ops *ops; - const struct hwmon_channel_info **info; + const struct hwmon_channel_info * const *info; }; It contains the following fields: @@ -229,7 +203,7 @@ register (HWMON_T_MAX) as well as a maximum temperature hysteresis register .config = lm75_temp_config, }; - static const struct hwmon_channel_info *lm75_info[] = { + static const struct hwmon_channel_info * const lm75_info[] = { &lm75_chip, &lm75_temp, NULL @@ -238,7 +212,7 @@ register (HWMON_T_MAX) as well as a maximum temperature hysteresis register The HWMON_CHANNEL_INFO() macro can and should be used when possible. With this macro, the above example can be simplified to - static const struct hwmon_channel_info *lm75_info[] = { + static const struct hwmon_channel_info * const lm75_info[] = { HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL), HWMON_CHANNEL_INFO(temp, @@ -351,11 +325,9 @@ Return value: Driver-provided sysfs attributes -------------------------------- -If the hardware monitoring device is registered with -hwmon_device_register_with_info or devm_hwmon_device_register_with_info, -it is most likely not necessary to provide sysfs attributes. Only additional -non-standard sysfs attributes need to be provided when one of those registration -functions is used. +In most situations it should not be necessary for a driver to provide sysfs +attributes since the hardware monitoring core creates those internally. +Only additional non-standard sysfs attributes need to be provided. The header file linux/hwmon-sysfs.h provides a number of useful macros to declare and use hardware monitoring sysfs attributes. diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index f1fe75f596a5..fa1208c62855 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -22,6 +22,7 @@ Hardware Monitoring Kernel Drivers abituguru abituguru3 + acbel-fsg032 acpi_power_meter ad7314 adc128d818 @@ -184,6 +185,7 @@ Hardware Monitoring Kernel Drivers sch5627 sch5636 scpi-hwmon + sfctemp sht15 sht21 sht3x diff --git a/Documentation/hwmon/sfctemp.rst b/Documentation/hwmon/sfctemp.rst new file mode 100644 index 000000000000..9fbd5bb1f356 --- /dev/null +++ b/Documentation/hwmon/sfctemp.rst @@ -0,0 +1,33 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver sfctemp +===================== + +Supported chips: + - StarFive JH7100 + - StarFive JH7110 + +Authors: + - Emil Renner Berthing <kernel@esmil.dk> + +Description +----------- + +This driver adds support for reading the built-in temperature sensor on the +JH7100 and JH7110 RISC-V SoCs by StarFive Technology Co. Ltd. + +``sysfs`` interface +------------------- + +The temperature sensor can be enabled, disabled and queried via the standard +hwmon interface in sysfs under ``/sys/class/hwmon/hwmonX`` for some value of +``X``: + +================ ==== ============================================= +Name Perm Description +================ ==== ============================================= +temp1_enable RW Enable or disable temperature sensor. + Automatically enabled by the driver, + but may be disabled to save power. +temp1_input RO Temperature reading in milli-degrees Celsius. +================ ==== ============================================= diff --git a/Documentation/hwmon/sysfs-interface.rst b/Documentation/hwmon/sysfs-interface.rst index 209626fb2405..f76e9f8cc1ad 100644 --- a/Documentation/hwmon/sysfs-interface.rst +++ b/Documentation/hwmon/sysfs-interface.rst @@ -201,7 +201,7 @@ PWM Pulse width modulation fan control. `pwm[1-*]_enable` - Fan speed control method: + Fan speed control method. `pwm[1-*]_mode` direct current or pulse-width modulation. diff --git a/Documentation/index.rst b/Documentation/index.rst index 76d1a3ec9be3..9dfdc826618c 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -99,7 +99,7 @@ Architecture-specific documentation .. toctree:: :maxdepth: 2 - arch + arch/index Other documentation diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst index 5202186728b4..e22621f4af0b 100644 --- a/Documentation/kbuild/kbuild.rst +++ b/Documentation/kbuild/kbuild.rst @@ -160,7 +160,6 @@ directory name found in the arch/ directory. But some architectures such as x86 and sparc have aliases. - x86: i386 for 32 bit, x86_64 for 64 bit -- sh: sh for 32 bit, sh64 for 64 bit - sparc: sparc32 for 32 bit, sparc64 for 64 bit CROSS_COMPILE diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index bfb51685073c..c3851fe1900d 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -171,6 +171,10 @@ Getting Help Getting LLVM ------------- +We provide prebuilt stable versions of LLVM on `kernel.org <https://kernel.org/pub/tools/llvm/>`_. +Below are links that may be useful for building LLVM from source or procuring +it through a distribution's package manager. + - https://releases.llvm.org/download.html - https://github.com/llvm/llvm-project - https://llvm.org/docs/GettingStarted.html diff --git a/Documentation/kernel-hacking/false-sharing.rst b/Documentation/kernel-hacking/false-sharing.rst new file mode 100644 index 000000000000..122b0e124656 --- /dev/null +++ b/Documentation/kernel-hacking/false-sharing.rst @@ -0,0 +1,206 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +False Sharing +============= + +What is False Sharing +===================== +False sharing is related with cache mechanism of maintaining the data +coherence of one cache line stored in multiple CPU's caches; then +academic definition for it is in [1]_. Consider a struct with a +refcount and a string:: + + struct foo { + refcount_t refcount; + ... + char name[16]; + } ____cacheline_internodealigned_in_smp; + +Member 'refcount'(A) and 'name'(B) _share_ one cache line like below:: + + +-----------+ +-----------+ + | CPU 0 | | CPU 1 | + +-----------+ +-----------+ + / | + / | + V V + +----------------------+ +----------------------+ + | A B | Cache 0 | A B | Cache 1 + +----------------------+ +----------------------+ + | | + ---------------------------+------------------+----------------------------- + | | + +----------------------+ + | | + +----------------------+ + Main Memory | A B | + +----------------------+ + +'refcount' is modified frequently, but 'name' is set once at object +creation time and is never modified. When many CPUs access 'foo' at +the same time, with 'refcount' being only bumped by one CPU frequently +and 'name' being read by other CPUs, all those reading CPUs have to +reload the whole cache line over and over due to the 'sharing', even +though 'name' is never changed. + +There are many real-world cases of performance regressions caused by +false sharing. One of these is a rw_semaphore 'mmap_lock' inside +mm_struct struct, whose cache line layout change triggered a +regression and Linus analyzed in [2]_. + +There are two key factors for a harmful false sharing: + +* A global datum accessed (shared) by many CPUs +* In the concurrent accesses to the data, there is at least one write + operation: write/write or write/read cases. + +The sharing could be from totally unrelated kernel components, or +different code paths of the same kernel component. + + +False Sharing Pitfalls +====================== +Back in time when one platform had only one or a few CPUs, hot data +members could be purposely put in the same cache line to make them +cache hot and save cacheline/TLB, like a lock and the data protected +by it. But for recent large system with hundreds of CPUs, this may +not work when the lock is heavily contended, as the lock owner CPU +could write to the data, while other CPUs are busy spinning the lock. + +Looking at past cases, there are several frequently occurring patterns +for false sharing: + +* lock (spinlock/mutex/semaphore) and data protected by it are + purposely put in one cache line. +* global data being put together in one cache line. Some kernel + subsystems have many global parameters of small size (4 bytes), + which can easily be grouped together and put into one cache line. +* data members of a big data structure randomly sitting together + without being noticed (cache line is usually 64 bytes or more), + like 'mem_cgroup' struct. + +Following 'mitigation' section provides real-world examples. + +False sharing could easily happen unless they are intentionally +checked, and it is valuable to run specific tools for performance +critical workloads to detect false sharing affecting performance case +and optimize accordingly. + + +How to detect and analyze False Sharing +======================================== +perf record/report/stat are widely used for performance tuning, and +once hotspots are detected, tools like 'perf-c2c' and 'pahole' can +be further used to detect and pinpoint the possible false sharing +data structures. 'addr2line' is also good at decoding instruction +pointer when there are multiple layers of inline functions. + +perf-c2c can capture the cache lines with most false sharing hits, +decoded functions (line number of file) accessing that cache line, +and in-line offset of the data. Simple commands are:: + + $ perf c2c record -ag sleep 3 + $ perf c2c report --call-graph none -k vmlinux + +When running above during testing will-it-scale's tlb_flush1 case, +perf reports something like:: + + Total records : 1658231 + Locked Load/Store Operations : 89439 + Load Operations : 623219 + Load Local HITM : 92117 + Load Remote HITM : 139 + + #---------------------------------------------------------------------- + 4 0 2374 0 0 0 0xff1100088366d880 + #---------------------------------------------------------------------- + 0.00% 42.29% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff81373b7b 0 231 129 5312 64 [k] __mod_lruvec_page_state [kernel.vmlinux] memcontrol.h:752 1 + 0.00% 13.10% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff81374718 0 226 97 3551 64 [k] folio_lruvec_lock_irqsave [kernel.vmlinux] memcontrol.h:752 1 + 0.00% 11.20% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff812c29bf 0 170 136 555 64 [k] lru_add_fn [kernel.vmlinux] mm_inline.h:41 1 + 0.00% 7.62% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff812c3ec5 0 175 108 632 64 [k] release_pages [kernel.vmlinux] mm_inline.h:41 1 + 0.00% 23.29% 0.00% 0.00% 0.00% 0x10 1 1 0xffffffff81372d0a 0 234 279 1051 64 [k] __mod_memcg_lruvec_state [kernel.vmlinux] memcontrol.c:736 1 + +A nice introduction for perf-c2c is [3]_. + +'pahole' decodes data structure layouts delimited in cache line +granularity. Users can match the offset in perf-c2c output with +pahole's decoding to locate the exact data members. For global +data, users can search the data address in System.map. + + +Possible Mitigations +==================== +False sharing does not always need to be mitigated. False sharing +mitigations should balance performance gains with complexity and +space consumption. Sometimes, lower performance is OK, and it's +unnecessary to hyper-optimize every rarely used data structure or +a cold data path. + +False sharing hurting performance cases are seen more frequently with +core count increasing. Because of these detrimental effects, many +patches have been proposed across variety of subsystems (like +networking and memory management) and merged. Some common mitigations +(with examples) are: + +* Separate hot global data in its own dedicated cache line, even if it + is just a 'short' type. The downside is more consumption of memory, + cache line and TLB entries. + + - Commit 91b6d3256356 ("net: cache align tcp_memory_allocated, tcp_sockets_allocated") + +* Reorganize the data structure, separate the interfering members to + different cache lines. One downside is it may introduce new false + sharing of other members. + + - Commit 802f1d522d5f ("mm: page_counter: re-layout structure to reduce false sharing") + +* Replace 'write' with 'read' when possible, especially in loops. + Like for some global variable, use compare(read)-then-write instead + of unconditional write. For example, use:: + + if (!test_bit(XXX)) + set_bit(XXX); + + instead of directly "set_bit(XXX);", similarly for atomic_t data:: + + if (atomic_read(XXX) == AAA) + atomic_set(XXX, BBB); + + - Commit 7b1002f7cfe5 ("bcache: fixup bcache_dev_sectors_dirty_add() multithreaded CPU false sharing") + - Commit 292648ac5cf1 ("mm: gup: allow FOLL_PIN to scale in SMP") + +* Turn hot global data to 'per-cpu data + global data' when possible, + or reasonably increase the threshold for syncing per-cpu data to + global data, to reduce or postpone the 'write' to that global data. + + - Commit 520f897a3554 ("ext4: use percpu_counters for extent_status cache hits/misses") + - Commit 56f3547bfa4d ("mm: adjust vm_committed_as_batch according to vm overcommit policy") + +Surely, all mitigations should be carefully verified to not cause side +effects. To avoid introducing false sharing when coding, it's better +to: + +* Be aware of cache line boundaries +* Group mostly read-only fields together +* Group things that are written at the same time together +* Separate frequently read and frequently written fields on + different cache lines. + +and better add a comment stating the false sharing consideration. + +One note is, sometimes even after a severe false sharing is detected +and solved, the performance may still have no obvious improvement as +the hotspot switches to a new place. + + +Miscellaneous +============= +One open issue is that kernel has an optional data structure +randomization mechanism, which also randomizes the situation of cache +line sharing of data members. + + +.. [1] https://en.wikipedia.org/wiki/False_sharing +.. [2] https://lore.kernel.org/lkml/CAHk-=whoqV=cX5VC80mmR9rr+Z+yQ6fiQZm36Fb-izsanHg23w@mail.gmail.com/ +.. [3] https://joemario.github.io/blog/2016/09/01/c2c-blog/ diff --git a/Documentation/kernel-hacking/index.rst b/Documentation/kernel-hacking/index.rst index f53027652290..79c03bac99a2 100644 --- a/Documentation/kernel-hacking/index.rst +++ b/Documentation/kernel-hacking/index.rst @@ -9,3 +9,4 @@ Kernel Hacking Guides hacking locking + false-sharing diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt index 2160382c86be..e9c30dc75884 100644 --- a/Documentation/leds/well-known-leds.txt +++ b/Documentation/leds/well-known-leds.txt @@ -70,3 +70,33 @@ Good: "platform:*:charging" (allwinner sun50i) * Screen Good: ":backlight" (Motorola Droid 4) + +* Ethernet LEDs + +Currently two types of Network LEDs are support, those controlled by +the PHY and those by the MAC. In theory both can be present at the +same time for one Linux netdev, hence the names need to differ between +MAC and PHY. + +Do not use the netdev name, such as eth0, enp1s0. These are not stable +and are not unique. They also don't differentiate between MAC and PHY. + +** MAC LEDs + +Good: f1070000.ethernet:white:WAN +Good: mdio_mux-0.1:00:green:left +Good: 0000:02:00.0:yellow:top + +The first part must uniquely name the MAC controller. Then follows the +colour. WAN/LAN should be used for a single LED. If there are +multiple LEDs, use left/right, or top/bottom to indicate their +position on the RJ45 socket. + +** PHY LEDs + +Good: f1072004.mdio-mii:00: white:WAN +Good: !mdio-mux!mdio@2!switch@0!mdio:01:green:right +Good: r8169-0-200:00:yellow:bottom + +The first part must uniquely name the PHY. This often means uniquely +identifying the MDIO bus controller, and the address on the bus. diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README index 7f5c6c3ed6c3..658d37860d39 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -9,7 +9,7 @@ a kernel test module based on a litmus test, please see tools/memory-model/README. -atomic (/atomic derectory) +atomic (/atomic directory) -------------------------- Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus diff --git a/Documentation/litmus-tests/locking/DCL-broken.litmus b/Documentation/litmus-tests/locking/DCL-broken.litmus new file mode 100644 index 000000000000..bfb7ba4316d6 --- /dev/null +++ b/Documentation/litmus-tests/locking/DCL-broken.litmus @@ -0,0 +1,54 @@ +C DCL-broken + +(* + * Result: Sometimes + * + * This litmus test demonstrates more than just locking is required to + * correctly implement double-checked locking. + *) + +{ + int flag; + int data; +} + +P0(int *flag, int *data, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + r0 = READ_ONCE(*flag); + if (r0 == 0) { + spin_lock(lck); + r1 = READ_ONCE(*flag); + if (r1 == 0) { + WRITE_ONCE(*data, 1); + WRITE_ONCE(*flag, 1); + } + spin_unlock(lck); + } + r2 = READ_ONCE(*data); +} + +P1(int *flag, int *data, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + r0 = READ_ONCE(*flag); + if (r0 == 0) { + spin_lock(lck); + r1 = READ_ONCE(*flag); + if (r1 == 0) { + WRITE_ONCE(*data, 1); + WRITE_ONCE(*flag, 1); + } + spin_unlock(lck); + } + r2 = READ_ONCE(*data); +} + +locations [flag;data;0:r0;0:r1;1:r0;1:r1] +exists (0:r2=0 \/ 1:r2=0) diff --git a/Documentation/litmus-tests/locking/DCL-fixed.litmus b/Documentation/litmus-tests/locking/DCL-fixed.litmus new file mode 100644 index 000000000000..d1b60bcb0c8f --- /dev/null +++ b/Documentation/litmus-tests/locking/DCL-fixed.litmus @@ -0,0 +1,55 @@ +C DCL-fixed + +(* + * Result: Never + * + * This litmus test demonstrates that double-checked locking can be + * reliable given proper use of smp_load_acquire() and smp_store_release() + * in addition to the locking. + *) + +{ + int flag; + int data; +} + +P0(int *flag, int *data, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + r0 = smp_load_acquire(flag); + if (r0 == 0) { + spin_lock(lck); + r1 = READ_ONCE(*flag); + if (r1 == 0) { + WRITE_ONCE(*data, 1); + smp_store_release(flag, 1); + } + spin_unlock(lck); + } + r2 = READ_ONCE(*data); +} + +P1(int *flag, int *data, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + r0 = smp_load_acquire(flag); + if (r0 == 0) { + spin_lock(lck); + r1 = READ_ONCE(*flag); + if (r1 == 0) { + WRITE_ONCE(*data, 1); + smp_store_release(flag, 1); + } + spin_unlock(lck); + } + r2 = READ_ONCE(*data); +} + +locations [flag;data;0:r0;0:r1;1:r0;1:r1] +exists (0:r2=0 \/ 1:r2=0) diff --git a/Documentation/litmus-tests/locking/RM-broken.litmus b/Documentation/litmus-tests/locking/RM-broken.litmus new file mode 100644 index 000000000000..b7ef30cedfe5 --- /dev/null +++ b/Documentation/litmus-tests/locking/RM-broken.litmus @@ -0,0 +1,41 @@ +C RM-broken + +(* + * Result: DEADLOCK + * + * This litmus test demonstrates that the old "roach motel" approach + * to locking, where code can be freely moved into critical sections, + * cannot be used in the Linux kernel. + *) + +{ + int x; + atomic_t y; +} + +P0(int *x, atomic_t *y, spinlock_t *lck) +{ + int r2; + + spin_lock(lck); + r2 = atomic_inc_return(y); + WRITE_ONCE(*x, 1); + spin_unlock(lck); +} + +P1(int *x, atomic_t *y, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + spin_lock(lck); + r0 = READ_ONCE(*x); + r1 = READ_ONCE(*x); + r2 = atomic_inc_return(y); + spin_unlock(lck); +} + +locations [x;0:r2;1:r0;1:r1;1:r2] +filter (1:r0=0 /\ 1:r1=1) +exists (1:r2=1) diff --git a/Documentation/litmus-tests/locking/RM-fixed.litmus b/Documentation/litmus-tests/locking/RM-fixed.litmus new file mode 100644 index 000000000000..b62817559616 --- /dev/null +++ b/Documentation/litmus-tests/locking/RM-fixed.litmus @@ -0,0 +1,41 @@ +C RM-fixed + +(* + * Result: Never + * + * This litmus test demonstrates that the old "roach motel" approach + * to locking, where code can be freely moved into critical sections, + * cannot be used in the Linux kernel. + *) + +{ + int x; + atomic_t y; +} + +P0(int *x, atomic_t *y, spinlock_t *lck) +{ + int r2; + + spin_lock(lck); + r2 = atomic_inc_return(y); + WRITE_ONCE(*x, 1); + spin_unlock(lck); +} + +P1(int *x, atomic_t *y, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + r0 = READ_ONCE(*x); + r1 = READ_ONCE(*x); + spin_lock(lck); + r2 = atomic_inc_return(y); + spin_unlock(lck); +} + +locations [x;0:r2;1:r0;1:r1;1:r2] +filter (1:r0=0 /\ 1:r1=1) +exists (1:r2=1) diff --git a/Documentation/livepatch/module-elf-format.rst b/Documentation/livepatch/module-elf-format.rst index d48f530c0881..a03ed02ec57e 100644 --- a/Documentation/livepatch/module-elf-format.rst +++ b/Documentation/livepatch/module-elf-format.rst @@ -1,8 +1,8 @@ =========================== -Livepatch module Elf format +Livepatch module ELF format =========================== -This document outlines the Elf format requirements that livepatch modules must follow. +This document outlines the ELF format requirements that livepatch modules must follow. .. Table of Contents @@ -20,17 +20,17 @@ code. So, instead of duplicating code and re-implementing what the module loader can already do, livepatch leverages existing code in the module loader to perform the all the arch-specific relocation work. Specifically, livepatch reuses the apply_relocate_add() function in the module loader to -write relocations. The patch module Elf format described in this document +write relocations. The patch module ELF format described in this document enables livepatch to be able to do this. The hope is that this will make livepatch more easily portable to other architectures and reduce the amount of arch-specific code required to port livepatch to a particular architecture. Since apply_relocate_add() requires access to a module's section header -table, symbol table, and relocation section indices, Elf information is +table, symbol table, and relocation section indices, ELF information is preserved for livepatch modules (see section 5). Livepatch manages its own relocation sections and symbols, which are described in this document. The -Elf constants used to mark livepatch symbols and relocation sections were +ELF constants used to mark livepatch symbols and relocation sections were selected from OS-specific ranges according to the definitions from glibc. Why does livepatch need to write its own relocations? @@ -43,7 +43,7 @@ reject the livepatch module. Furthermore, we cannot apply relocations that affect modules not yet loaded at patch module load time (e.g. a patch to a driver that is not loaded). Formerly, livepatch solved this problem by embedding special "dynrela" (dynamic rela) sections in the resulting patch -module Elf output. Using these dynrela sections, livepatch could resolve +module ELF output. Using these dynrela sections, livepatch could resolve symbols while taking into account its scope and what module the symbol belongs to, and then manually apply the dynamic relocations. However this approach required livepatch to supply arch-specific code in order to write @@ -80,7 +80,7 @@ Example: 3. Livepatch relocation sections ================================ -A livepatch module manages its own Elf relocation sections to apply +A livepatch module manages its own ELF relocation sections to apply relocations to modules as well as to the kernel (vmlinux) at the appropriate time. For example, if a patch module patches a driver that is not currently loaded, livepatch will apply the corresponding livepatch @@ -95,7 +95,7 @@ also possible for a livepatch module to have no livepatch relocation sections, as in the case of the sample livepatch module (see samples/livepatch). -Since Elf information is preserved for livepatch modules (see Section 5), a +Since ELF information is preserved for livepatch modules (see Section 5), a livepatch relocation section can be applied simply by passing in the appropriate section index to apply_relocate_add(), which then uses it to access the relocation section and apply the relocations. @@ -291,12 +291,12 @@ Examples: Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20). "OS" means OS-specific. -5. Symbol table and Elf section access +5. Symbol table and ELF section access ====================================== A livepatch module's symbol table is accessible through module->symtab. Since apply_relocate_add() requires access to a module's section headers, -symbol table, and relocation section indices, Elf information is preserved for +symbol table, and relocation section indices, ELF information is preserved for livepatch modules and is made accessible by the module loader through module->klp_info, which is a :c:type:`klp_modinfo` struct. When a livepatch module loads, this struct is filled in by the module loader. diff --git a/Documentation/livepatch/reliable-stacktrace.rst b/Documentation/livepatch/reliable-stacktrace.rst index 67459d2ca2af..d56bb706172f 100644 --- a/Documentation/livepatch/reliable-stacktrace.rst +++ b/Documentation/livepatch/reliable-stacktrace.rst @@ -183,7 +183,7 @@ trampoline or return trampoline. For example, considering the x86_64 .. code-block:: none SYM_CODE_START(return_to_handler) - UNWIND_HINT_EMPTY + UNWIND_HINT_UNDEFINED subq $24, %rsp /* Save the return values */ diff --git a/Documentation/maintainer/rebasing-and-merging.rst b/Documentation/maintainer/rebasing-and-merging.rst index 09f988e7fa71..85800ce95ae5 100644 --- a/Documentation/maintainer/rebasing-and-merging.rst +++ b/Documentation/maintainer/rebasing-and-merging.rst @@ -213,11 +213,7 @@ point rather than some random spot. If your upstream-bound branch has emptied entirely into the mainline during the merge window, you can pull it forward with a command like:: - git merge v5.2-rc1^0 - -The "^0" will cause Git to do a fast-forward merge (which should be -possible in this situation), thus avoiding the addition of a spurious merge -commit. + git merge --ff-only v5.2-rc1 The guidelines laid out above are just that: guidelines. There will always be situations that call out for a different solution, and these guidelines diff --git a/Documentation/mm/active_mm.rst b/Documentation/mm/active_mm.rst index 45d89f8fb3a8..d096fc091e23 100644 --- a/Documentation/mm/active_mm.rst +++ b/Documentation/mm/active_mm.rst @@ -2,6 +2,12 @@ Active MM ========= +Note, the mm_count refcount may no longer include the "lazy" users +(running tasks with ->active_mm == mm && ->mm == NULL) on kernels +with CONFIG_MMU_LAZY_TLB_REFCOUNT=n. Taking and releasing these lazy +references must be done with mmgrab_lazy_tlb() and mmdrop_lazy_tlb() +helpers, which abstract this config option. + :: List: linux-kernel diff --git a/Documentation/mm/arch_pgtable_helpers.rst b/Documentation/mm/arch_pgtable_helpers.rst index 30d9a09f01f4..af3891f895b0 100644 --- a/Documentation/mm/arch_pgtable_helpers.rst +++ b/Documentation/mm/arch_pgtable_helpers.rst @@ -214,7 +214,7 @@ HugeTLB Page Table Helpers +---------------------------+--------------------------------------------------+ | pte_huge | Tests a HugeTLB | +---------------------------+--------------------------------------------------+ -| pte_mkhuge | Creates a HugeTLB | +| arch_make_huge_pte | Creates a HugeTLB | +---------------------------+--------------------------------------------------+ | huge_pte_dirty | Tests a dirty HugeTLB | +---------------------------+--------------------------------------------------+ diff --git a/Documentation/mm/hugetlbfs_reserv.rst b/Documentation/mm/hugetlbfs_reserv.rst index 3d05d64de9b4..d9c2b0f01dcd 100644 --- a/Documentation/mm/hugetlbfs_reserv.rst +++ b/Documentation/mm/hugetlbfs_reserv.rst @@ -5,10 +5,10 @@ Hugetlbfs Reservation Overview ======== -Huge pages as described at Documentation/mm/hugetlbpage.rst are typically -preallocated for application use. These huge pages are instantiated in a -task's address space at page fault time if the VMA indicates huge pages are -to be used. If no huge page exists at page fault time, the task is sent +Huge pages as described at Documentation/admin-guide/mm/hugetlbpage.rst are +typically preallocated for application use. These huge pages are instantiated +in a task's address space at page fault time if the VMA indicates huge pages +are to be used. If no huge page exists at page fault time, the task is sent a SIGBUS and often dies an unhappy death. Shortly after huge page support was added, it was determined that it would be better to detect a shortage of huge pages at mmap() time. The idea is that if there were not enough diff --git a/Documentation/mm/multigen_lru.rst b/Documentation/mm/multigen_lru.rst index 5f1f6ecbb79b..52ed5092022f 100644 --- a/Documentation/mm/multigen_lru.rst +++ b/Documentation/mm/multigen_lru.rst @@ -103,7 +103,8 @@ moving across tiers only involves atomic operations on ``folio->flags`` and therefore has a negligible cost. A feedback loop modeled after the PID controller monitors refaults over all the tiers from anon and file types and decides which tiers from which types to -evict or protect. +evict or protect. The desired effect is to balance refault percentages +between anon and file types proportional to the swappiness level. There are two conceptually independent procedures: the aging and the eviction. They form a closed-loop system, i.e., the page reclaim. @@ -156,6 +157,27 @@ This time-based approach has the following advantages: and memory sizes. 2. It is more reliable because it is directly wired to the OOM killer. +``mm_struct`` list +------------------ +An ``mm_struct`` list is maintained for each memcg, and an +``mm_struct`` follows its owner task to the new memcg when this task +is migrated. + +A page table walker iterates ``lruvec_memcg()->mm_list`` and calls +``walk_page_range()`` with each ``mm_struct`` on this list to scan +PTEs. When multiple page table walkers iterate the same list, each of +them gets a unique ``mm_struct``, and therefore they can run in +parallel. + +Page table walkers ignore any misplaced pages, e.g., if an +``mm_struct`` was migrated, pages left in the previous memcg will be +ignored when the current memcg is under reclaim. Similarly, page table +walkers will ignore pages from nodes other than the one under reclaim. + +This infrastructure also tracks the usage of ``mm_struct`` between +context switches so that page table walkers can skip processes that +have been sleeping since the last iteration. + Rmap/PT walk feedback --------------------- Searching the rmap for PTEs mapping each page on an LRU list (to test @@ -170,7 +192,7 @@ promotes hot pages. If the scan was done cacheline efficiently, it adds the PMD entry pointing to the PTE table to the Bloom filter. This forms a feedback loop between the eviction and the aging. -Bloom Filters +Bloom filters ------------- Bloom filters are a space and memory efficient data structure for set membership test, i.e., test if an element is not in the set or may be @@ -186,6 +208,18 @@ is false positive, the cost is an additional scan of a range of PTEs, which may yield hot pages anyway. Parameters of the filter itself can control the false positive rate in the limit. +PID controller +-------------- +A feedback loop modeled after the Proportional-Integral-Derivative +(PID) controller monitors refaults over anon and file types and +decides which type to evict when both types are available from the +same generation. + +The PID controller uses generations rather than the wall clock as the +time domain because a CPU can scan pages at different rates under +varying memory pressure. It calculates a moving average for each new +generation to avoid being permanently locked in a suboptimal state. + Memcg LRU --------- An memcg LRU is a per-node LRU of memcgs. It is also an LRU of LRUs, @@ -223,9 +257,9 @@ parts: * Generations * Rmap walks -* Page table walks -* Bloom filters -* PID controller +* Page table walks via ``mm_struct`` list +* Bloom filters for rmap/PT walk feedback +* PID controller for refault feedback The aging and the eviction form a producer-consumer model; specifically, the latter drives the former by the sliding window over diff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst index f9d7ea4b9dca..531e73b003dd 100644 --- a/Documentation/mm/physical_memory.rst +++ b/Documentation/mm/physical_memory.rst @@ -19,7 +19,7 @@ a bank of memory very suitable for DMA near peripheral devices. Each bank is called a node and the concept is represented under Linux by a ``struct pglist_data`` even if the architecture is UMA. This structure is -always referenced to by it's typedef ``pg_data_t``. ``A pg_data_t`` structure +always referenced by its typedef ``pg_data_t``. A ``pg_data_t`` structure for a particular node can be referenced by ``NODE_DATA(nid)`` macro where ``nid`` is the ID of that node. @@ -66,7 +66,7 @@ one of the types described below. also populated on boot using one of ``kernelcore``, ``movablecore`` and ``movable_node`` kernel command line parameters. See Documentation/mm/page_migration.rst and - Documentation/admin-guide/mm/memory_hotplug.rst for additional details. + Documentation/admin-guide/mm/memory-hotplug.rst for additional details. * ``ZONE_DEVICE`` represents memory residing on devices such as PMEM and GPU. It has different characteristics than RAM zone types and it exists to provide @@ -114,6 +114,25 @@ RAM equally split between two nodes, there will be ``ZONE_DMA32``, | DMA32 | NORMAL | MOVABLE | | NORMAL | MOVABLE | +---------+----------+-----------+ +------------+-------------+ + +Memory banks may belong to interleaving nodes. In the example below an x86 +machine has 16 Gbytes of RAM in 4 memory banks, even banks belong to node 0 +and odd banks belong to node 1:: + + + 0 4G 8G 12G 16G + +-------------+ +-------------+ +-------------+ +-------------+ + | node 0 | | node 1 | | node 0 | | node 1 | + +-------------+ +-------------+ +-------------+ +-------------+ + + 0 16M 4G + +-----+-------+ +-------------+ +-------------+ +-------------+ + | DMA | DMA32 | | NORMAL | | NORMAL | | NORMAL | + +-----+-------+ +-------------+ +-------------+ +-------------+ + +In this case node 0 will span from 0 to 12 Gbytes and node 1 will span from +4 to 16 Gbytes. + .. _nodes: Nodes diff --git a/Documentation/mm/unevictable-lru.rst b/Documentation/mm/unevictable-lru.rst index 92ac5dca420c..d5ac8511eb67 100644 --- a/Documentation/mm/unevictable-lru.rst +++ b/Documentation/mm/unevictable-lru.rst @@ -42,6 +42,8 @@ The unevictable list addresses the following classes of unevictable pages: * Those owned by ramfs. + * Those owned by tmpfs with the noswap mount option. + * Those mapped into SHM_LOCK'd shared memory regions. * Those mapped into VM_LOCKED [mlock()ed] VMAs. diff --git a/Documentation/mm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst index 64d127bfc221..a3c26d587752 100644 --- a/Documentation/mm/zsmalloc.rst +++ b/Documentation/mm/zsmalloc.rst @@ -39,13 +39,12 @@ With CONFIG_ZSMALLOC_STAT, we could see zsmalloc internal information via # cat /sys/kernel/debug/zsmalloc/zram0/classes - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage + class size 10% 20% 30% 40% 50% 60% 70% 80% 90% 99% 100% obj_allocated obj_used pages_used pages_per_zspage freeable ... ... - 9 176 0 1 186 129 8 4 - 10 192 1 0 2880 2872 135 3 - 11 208 0 1 819 795 42 2 - 12 224 0 1 219 159 12 4 + 30 512 0 12 4 1 0 1 0 0 1 0 414 3464 3346 433 1 14 + 31 528 2 7 2 2 1 0 1 0 0 2 117 4154 3793 536 4 44 + 32 544 6 3 4 1 2 1 0 0 0 1 260 4170 3965 556 2 26 ... ... @@ -54,10 +53,28 @@ class index size object size zspage stores -almost_empty - the number of ZS_ALMOST_EMPTY zspages(see below) -almost_full - the number of ZS_ALMOST_FULL zspages(see below) +10% + the number of zspages with usage ratio less than 10% (see below) +20% + the number of zspages with usage ratio between 10% and 20% +30% + the number of zspages with usage ratio between 20% and 30% +40% + the number of zspages with usage ratio between 30% and 40% +50% + the number of zspages with usage ratio between 40% and 50% +60% + the number of zspages with usage ratio between 50% and 60% +70% + the number of zspages with usage ratio between 60% and 70% +80% + the number of zspages with usage ratio between 70% and 80% +90% + the number of zspages with usage ratio between 80% and 90% +99% + the number of zspages with usage ratio between 90% and 99% +100% + the number of zspages with usage ratio 100% obj_allocated the number of objects allocated obj_used @@ -66,19 +83,14 @@ pages_used the number of pages allocated for the class pages_per_zspage the number of 0-order pages to make a zspage +freeable + the approximate number of pages class compaction can free -We assign a zspage to ZS_ALMOST_EMPTY fullness group when n <= N / f, where - -* n = number of allocated objects -* N = total number of objects zspage can store -* f = fullness_threshold_frac(ie, 4 at the moment) - -Similarly, we assign zspage to: - -* ZS_ALMOST_FULL when n > N / f -* ZS_EMPTY when n == 0 -* ZS_FULL when n == N - +Each zspage maintains inuse counter which keeps track of the number of +objects stored in the zspage. The inuse counter determines the zspage's +"fullness group" which is calculated as the ratio of the "inuse" objects to +the total number of objects the zspage can hold (objs_per_zspage). The +closer the inuse counter is to objs_per_zspage, the better. Internals ========= @@ -94,10 +106,10 @@ of objects that each zspage can store. For instance, consider the following size classes::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable ... - 94 1536 0 0 0 0 0 3 0 - 100 1632 0 0 0 0 0 2 0 + 94 1536 0 .... 0 0 0 0 3 0 + 100 1632 0 .... 0 0 0 0 2 0 ... @@ -134,10 +146,11 @@ reduces memory wastage. Let's take a closer look at the bottom of `/sys/kernel/debug/zsmalloc/zramX/classes`::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable + ... - 202 3264 0 0 0 0 0 4 0 - 254 4096 0 0 0 0 0 1 0 + 202 3264 0 .. 0 0 0 0 4 0 + 254 4096 0 .. 0 0 0 0 1 0 ... Size class #202 stores objects of size 3264 bytes and has a maximum of 4 pages @@ -151,40 +164,42 @@ efficient storage of large objects. For zspage chain size of 8, huge class watermark becomes 3632 bytes::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable + ... - 202 3264 0 0 0 0 0 4 0 - 211 3408 0 0 0 0 0 5 0 - 217 3504 0 0 0 0 0 6 0 - 222 3584 0 0 0 0 0 7 0 - 225 3632 0 0 0 0 0 8 0 - 254 4096 0 0 0 0 0 1 0 + 202 3264 0 .. 0 0 0 0 4 0 + 211 3408 0 .. 0 0 0 0 5 0 + 217 3504 0 .. 0 0 0 0 6 0 + 222 3584 0 .. 0 0 0 0 7 0 + 225 3632 0 .. 0 0 0 0 8 0 + 254 4096 0 .. 0 0 0 0 1 0 ... For zspage chain size of 16, huge class watermark becomes 3840 bytes::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable + ... - 202 3264 0 0 0 0 0 4 0 - 206 3328 0 0 0 0 0 13 0 - 207 3344 0 0 0 0 0 9 0 - 208 3360 0 0 0 0 0 14 0 - 211 3408 0 0 0 0 0 5 0 - 212 3424 0 0 0 0 0 16 0 - 214 3456 0 0 0 0 0 11 0 - 217 3504 0 0 0 0 0 6 0 - 219 3536 0 0 0 0 0 13 0 - 222 3584 0 0 0 0 0 7 0 - 223 3600 0 0 0 0 0 15 0 - 225 3632 0 0 0 0 0 8 0 - 228 3680 0 0 0 0 0 9 0 - 230 3712 0 0 0 0 0 10 0 - 232 3744 0 0 0 0 0 11 0 - 234 3776 0 0 0 0 0 12 0 - 235 3792 0 0 0 0 0 13 0 - 236 3808 0 0 0 0 0 14 0 - 238 3840 0 0 0 0 0 15 0 - 254 4096 0 0 0 0 0 1 0 + 202 3264 0 .. 0 0 0 0 4 0 + 206 3328 0 .. 0 0 0 0 13 0 + 207 3344 0 .. 0 0 0 0 9 0 + 208 3360 0 .. 0 0 0 0 14 0 + 211 3408 0 .. 0 0 0 0 5 0 + 212 3424 0 .. 0 0 0 0 16 0 + 214 3456 0 .. 0 0 0 0 11 0 + 217 3504 0 .. 0 0 0 0 6 0 + 219 3536 0 .. 0 0 0 0 13 0 + 222 3584 0 .. 0 0 0 0 7 0 + 223 3600 0 .. 0 0 0 0 15 0 + 225 3632 0 .. 0 0 0 0 8 0 + 228 3680 0 .. 0 0 0 0 9 0 + 230 3712 0 .. 0 0 0 0 10 0 + 232 3744 0 .. 0 0 0 0 11 0 + 234 3776 0 .. 0 0 0 0 12 0 + 235 3792 0 .. 0 0 0 0 13 0 + 236 3808 0 .. 0 0 0 0 14 0 + 238 3840 0 .. 0 0 0 0 15 0 + 254 4096 0 .. 0 0 0 0 1 0 ... Overall the combined zspage chain size effect on zsmalloc pool configuration::: @@ -214,9 +229,10 @@ zram as a build artifacts storage (Linux kernel compilation). zsmalloc classes stats::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable + ... - Total 13 51 413836 412973 159955 3 + Total 13 .. 51 413836 412973 159955 3 zram mm_stat::: @@ -227,9 +243,10 @@ zram as a build artifacts storage (Linux kernel compilation). zsmalloc classes stats::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable + ... - Total 18 87 414852 412978 156666 0 + Total 18 .. 87 414852 412978 156666 0 zram mm_stat::: diff --git a/Documentation/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml index bbcfa2472b04..8e8c17b0a6c6 100644 --- a/Documentation/netlink/genetlink-c.yaml +++ b/Documentation/netlink/genetlink-c.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0 +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) %YAML 1.2 --- $id: http://kernel.org/schemas/netlink/genetlink-c.yaml# @@ -33,10 +33,10 @@ properties: protocol: description: Schema compatibility level. Default is "genetlink". enum: [ genetlink, genetlink-c ] - # Start genetlink-c uapi-header: description: Path to the uAPI header, default is linux/${family-name}.h type: string + # Start genetlink-c c-family-name: description: Name of the define for the family name. type: string diff --git a/Documentation/netlink/genetlink-legacy.yaml b/Documentation/netlink/genetlink-legacy.yaml index 5642925c4ceb..b33541a51d6b 100644 --- a/Documentation/netlink/genetlink-legacy.yaml +++ b/Documentation/netlink/genetlink-legacy.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0 +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) %YAML 1.2 --- $id: http://kernel.org/schemas/netlink/genetlink-legacy.yaml# @@ -33,10 +33,10 @@ properties: protocol: description: Schema compatibility level. Default is "genetlink". enum: [ genetlink, genetlink-c, genetlink-legacy ] # Trim - # Start genetlink-c uapi-header: description: Path to the uAPI header, default is linux/${family-name}.h type: string + # Start genetlink-c c-family-name: description: Name of the define for the family name. type: string @@ -218,6 +218,11 @@ properties: description: Max length for a string or a binary attribute. $ref: '#/$defs/len-or-define' sub-type: *attr-type + # Start genetlink-legacy + struct: + description: Name of the struct type used for the attribute. + type: string + # End genetlink-legacy # Make sure name-prefix does not appear in subsets (subsets inherit naming) dependencies: @@ -256,6 +261,14 @@ properties: async-enum: description: Name for the enum type with notifications/events. type: string + # Start genetlink-legacy + fixed-header: &fixed-header + description: | + Name of the structure defining the optional fixed-length protocol + header. This header is placed in a message after the netlink and + genetlink headers and before any attributes. + type: string + # End genetlink-legacy list: description: List of commands type: array @@ -288,6 +301,9 @@ properties: type: array items: enum: [ strict, dump ] + # Start genetlink-legacy + fixed-header: *fixed-header + # End genetlink-legacy do: &subop-type description: Main command handler. type: object diff --git a/Documentation/netlink/genetlink.yaml b/Documentation/netlink/genetlink.yaml index 62a922755ce2..d8b2cdeba058 100644 --- a/Documentation/netlink/genetlink.yaml +++ b/Documentation/netlink/genetlink.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0 +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) %YAML 1.2 --- $id: http://kernel.org/schemas/netlink/genetlink-legacy.yaml# @@ -33,6 +33,9 @@ properties: protocol: description: Schema compatibility level. Default is "genetlink". enum: [ genetlink ] + uapi-header: + description: Path to the uAPI header, default is linux/${family-name}.h + type: string definitions: description: List of type and constant definitions (enums, flags, defines). diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml new file mode 100644 index 000000000000..90641668232e --- /dev/null +++ b/Documentation/netlink/specs/devlink.yaml @@ -0,0 +1,198 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: devlink + +protocol: genetlink-legacy + +doc: Partial family for Devlink. + +attribute-sets: + - + name: devlink + attributes: + - + name: bus-name + type: string + value: 1 + - + name: dev-name + type: string + - + name: port-index + type: u32 + + # TODO: fill in the attributes in between + + - + name: info-driver-name + type: string + value: 98 + - + name: info-serial-number + type: string + - + name: info-version-fixed + type: nest + multi-attr: true + nested-attributes: dl-info-version + - + name: info-version-running + type: nest + multi-attr: true + nested-attributes: dl-info-version + - + name: info-version-stored + type: nest + multi-attr: true + nested-attributes: dl-info-version + - + name: info-version-name + type: string + - + name: info-version-value + type: string + + # TODO: fill in the attributes in between + + - + name: reload-failed + type: u8 + value: 136 + + # TODO: fill in the attributes in between + + - + name: reload-action + type: u8 + value: 153 + + # TODO: fill in the attributes in between + + - + name: dev-stats + type: nest + value: 156 + nested-attributes: dl-dev-stats + - + name: reload-stats + type: nest + nested-attributes: dl-reload-stats + - + name: reload-stats-entry + type: nest + multi-attr: true + nested-attributes: dl-reload-stats-entry + - + name: reload-stats-limit + type: u8 + - + name: reload-stats-value + type: u32 + - + name: remote-reload-stats + type: nest + nested-attributes: dl-reload-stats + - + name: reload-action-info + type: nest + nested-attributes: dl-reload-act-info + - + name: reload-action-stats + type: nest + nested-attributes: dl-reload-act-stats + - + name: dl-dev-stats + subset-of: devlink + attributes: + - + name: reload-stats + type: nest + - + name: remote-reload-stats + type: nest + - + name: dl-reload-stats + subset-of: devlink + attributes: + - + name: reload-action-info + type: nest + - + name: dl-reload-act-info + subset-of: devlink + attributes: + - + name: reload-action + type: u8 + - + name: reload-action-stats + type: nest + - + name: dl-reload-act-stats + subset-of: devlink + attributes: + - + name: reload-stats-entry + type: nest + - + name: dl-reload-stats-entry + subset-of: devlink + attributes: + - + name: reload-stats-limit + type: u8 + - + name: reload-stats-value + type: u32 + - + name: dl-info-version + subset-of: devlink + attributes: + - + name: info-version-name + type: string + - + name: info-version-value + type: string + +operations: + enum-model: directional + list: + - + name: get + doc: Get devlink instances. + attribute-set: devlink + + do: + request: + value: 1 + attributes: &dev-id-attrs + - bus-name + - dev-name + reply: &get-reply + value: 3 + attributes: + - bus-name + - dev-name + - reload-failed + - reload-action + - dev-stats + dump: + reply: *get-reply + + # TODO: fill in the operations in between + + - + name: info-get + doc: Get device information, like driver name, hardware and firmware versions etc. + attribute-set: devlink + + do: + request: + value: 51 + attributes: *dev-id-attrs + reply: + value: 51 + attributes: + - bus-name + - dev-name diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml index 08b776908d15..129f413ea349 100644 --- a/Documentation/netlink/specs/ethtool.yaml +++ b/Documentation/netlink/specs/ethtool.yaml @@ -1,9 +1,17 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + name: ethtool protocol: genetlink-legacy doc: Partial family for Ethtool Netlink. +definitions: + - + name: udp-tunnel-type + type: enum + entries: [ vxlan, geneve, vxlan-gpe ] + attribute-sets: - name: header @@ -11,7 +19,6 @@ attribute-sets: - name: dev-index type: u32 - value: 1 - name: dev-name type: string @@ -25,7 +32,6 @@ attribute-sets: - name: index type: u32 - value: 1 - name: name type: string @@ -38,15 +44,14 @@ attribute-sets: - name: bit type: nest + multi-attr: true nested-attributes: bitset-bit - value: 1 - name: bitset attributes: - name: nomask type: flag - value: 1 - name: size type: u32 @@ -56,12 +61,27 @@ attribute-sets: nested-attributes: bitset-bits - + name: u64-array + attributes: + - + name: u64 + type: nest + multi-attr: true + nested-attributes: u64 + - + name: s32-array + attributes: + - + name: s32 + type: nest + multi-attr: true + nested-attributes: s32 + - name: string attributes: - name: index type: u32 - value: 1 - name: value type: string @@ -71,7 +91,6 @@ attribute-sets: - name: string type: nest - value: 1 multi-attr: true nested-attributes: string - @@ -80,7 +99,6 @@ attribute-sets: - name: id type: u32 - value: 1 - name: count type: u32 @@ -96,14 +114,12 @@ attribute-sets: name: stringset type: nest multi-attr: true - value: 1 nested-attributes: stringset - name: strset attributes: - name: header - value: 1 type: nest nested-attributes: header - @@ -119,7 +135,6 @@ attribute-sets: attributes: - name: header - value: 1 type: nest nested-attributes: header - @@ -132,7 +147,6 @@ attribute-sets: attributes: - name: header - value: 1 type: nest nested-attributes: header - @@ -174,13 +188,18 @@ attribute-sets: - name: rx-push type: u8 + - + name: tx-push-buf-len + type: u32 + - + name: tx-push-buf-len-max + type: u32 - name: mm-stat attributes: - name: pad - value: 1 type: pad - name: reassembly-errors @@ -205,7 +224,6 @@ attribute-sets: attributes: - name: header - value: 1 type: nest nested-attributes: header - @@ -239,6 +257,657 @@ attribute-sets: name: stats type: nest nested-attributes: mm-stat + - + name: linkinfo + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: port + type: u8 + - + name: phyaddr + type: u8 + - + name: tp-mdix + type: u8 + - + name: tp-mdix-ctrl + type: u8 + - + name: transceiver + type: u8 + - + name: linkmodes + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: autoneg + type: u8 + - + name: ours + type: nest + nested-attributes: bitset + - + name: peer + type: nest + nested-attributes: bitset + - + name: speed + type: u32 + - + name: duplex + type: u8 + - + name: master-slave-cfg + type: u8 + - + name: master-slave-state + type: u8 + - + name: master-slave-lanes + type: u32 + - + name: rate-matching + type: u8 + - + name: linkstate + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: link + type: u8 + - + name: sqi + type: u32 + - + name: sqi-max + type: u32 + - + name: ext-state + type: u8 + - + name: ext-substate + type: u8 + - + name: down-cnt + type: u32 + - + name: debug + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: msgmask + type: nest + nested-attributes: bitset + - + name: wol + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: modes + type: nest + nested-attributes: bitset + - + name: sopass + type: binary + - + name: features + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: hw + type: nest + nested-attributes: bitset + - + name: wanted + type: nest + nested-attributes: bitset + - + name: active + type: nest + nested-attributes: bitset + - + name: nochange + type: nest + nested-attributes: bitset + - + name: channels + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: rx-max + type: u32 + - + name: tx-max + type: u32 + - + name: other-max + type: u32 + - + name: combined-max + type: u32 + - + name: rx-count + type: u32 + - + name: tx-count + type: u32 + - + name: other-count + type: u32 + - + name: combined-count + type: u32 + + - + name: coalesce + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: rx-usecs + type: u32 + - + name: rx-max-frames + type: u32 + - + name: rx-usecs-irq + type: u32 + - + name: rx-max-frames-irq + type: u32 + - + name: tx-usecs + type: u32 + - + name: tx-max-frames + type: u32 + - + name: tx-usecs-irq + type: u32 + - + name: tx-max-frames-irq + type: u32 + - + name: stats-block-usecs + type: u32 + - + name: use-adaptive-rx + type: u8 + - + name: use-adaptive-tx + type: u8 + - + name: pkt-rate-low + type: u32 + - + name: rx-usecs-low + type: u32 + - + name: rx-max-frames-low + type: u32 + - + name: tx-usecs-low + type: u32 + - + name: tx-max-frames-low + type: u32 + - + name: pkt-rate-high + type: u32 + - + name: rx-usecs-high + type: u32 + - + name: rx-max-frames-high + type: u32 + - + name: tx-usecs-high + type: u32 + - + name: tx-max-frames-high + type: u32 + - + name: rate-sample-interval + type: u32 + - + name: use-cqe-mode-tx + type: u8 + - + name: use-cqe-mode-rx + type: u8 + - + name: tx-aggr-max-bytes + type: u32 + - + name: tx-aggr-max-frames + type: u32 + - + name: tx-aggr-time-usecs + type: u32 + - + name: pause-stat + attributes: + - + name: pad + type: u32 + - + name: tx-frames + type: u64 + - + name: rx-frames + type: u64 + - + name: pause + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: autoneg + type: u8 + - + name: rx + type: u8 + - + name: tx + type: u8 + - + name: stats + type: nest + nested-attributes: pause-stat + - + name: stats-src + type: u32 + - + name: eee + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: modes-ours + type: nest + nested-attributes: bitset + - + name: modes-peer + type: nest + nested-attributes: bitset + - + name: active + type: u8 + - + name: enabled + type: u8 + - + name: tx-lpi-enabled + type: u8 + - + name: tx-lpi-timer + type: u32 + - + name: tsinfo + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: timestamping + type: nest + nested-attributes: bitset + - + name: tx-types + type: nest + nested-attributes: bitset + - + name: rx-filters + type: nest + nested-attributes: bitset + - + name: phc-index + type: u32 + - + name: cable-test-nft-nest-result + attributes: + - + name: pair + type: u8 + - + name: code + type: u8 + - + name: cable-test-nft-nest-fault-length + attributes: + - + name: pair + type: u8 + - + name: cm + type: u32 + - + name: cable-test-nft-nest + attributes: + - + name: result + type: nest + nested-attributes: cable-test-nft-nest-result + - + name: fault-length + type: nest + nested-attributes: cable-test-nft-nest-fault-length + - + name: cable-test + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: status + type: u8 + - + name: nest + type: nest + nested-attributes: cable-test-nft-nest + - + name: cable-test-tdr-cfg + attributes: + - + name: first + type: u32 + - + name: last + type: u32 + - + name: step + type: u32 + - + name: pari + type: u8 + - + name: cable-test-tdr + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: cfg + type: nest + nested-attributes: cable-test-tdr-cfg + - + name: tunnel-info-udp-entry + attributes: + - + name: port + type: u16 + byte-order: big-endian + - + name: type + type: u32 + enum: udp-tunnel-type + - + name: tunnel-info-udp-table + attributes: + - + name: size + type: u32 + - + name: types + type: nest + nested-attributes: bitset + - + name: udp-ports + type: nest + nested-attributes: tunnel-info-udp-entry + - + name: tunnel-info + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: udp-ports + type: nest + nested-attributes: tunnel-info-udp-table + - + name: fec-stat + attributes: + - + name: pad + type: u8 + - + name: corrected + type: nest + nested-attributes: u64-array + - + name: uncorr + type: nest + nested-attributes: u64-array + - + name: corr-bits + type: nest + nested-attributes: u64-array + - + name: fec + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: modes + type: nest + nested-attributes: bitset + - + name: auto + type: u8 + - + name: active + type: u32 + - + name: stats + type: nest + nested-attributes: fec-stat + - + name: module-eeprom + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: offset + type: u32 + - + name: length + type: u32 + - + name: page + type: u8 + - + name: bank + type: u8 + - + name: i2c-address + type: u8 + - + name: data + type: binary + - + name: stats-grp + attributes: + - + name: pad + type: u32 + - + name: id + type: u32 + - + name: ss-id + type: u32 + - + name: stat + type: nest + nested-attributes: u64 + - + name: hist-rx + type: nest + nested-attributes: u64 + - + name: hist-tx + type: nest + nested-attributes: u64 + - + name: hist-bkt-low + type: u32 + - + name: hist-bkt-hi + type: u32 + - + name: hist-bkt-val + type: u64 + - + name: stats + attributes: + - + name: pad + type: u32 + - + name: header + type: nest + nested-attributes: header + - + name: groups + type: nest + nested-attributes: bitset + - + name: grp + type: nest + nested-attributes: stats-grp + - + name: src + type: u32 + - + name: phc-vclocks + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: num + type: u32 + - + name: index + type: nest + nested-attributes: s32-array + - + name: module + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: power-mode-policy + type: u8 + - + name: power-mode + type: u8 + - + name: pse + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: admin-state + type: u32 + - + name: admin-control + type: u32 + - + name: pw-d-status + type: u32 + - + name: rss + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: context + type: u32 + - + name: hfunc + type: u32 + - + name: indir + type: binary + - + name: hkey + type: binary + - + name: plca + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: version + type: u16 + - + name: enabled + type: u8 + - + name: status + type: u8 + - + name: node-cnt + type: u32 + - + name: node-id + type: u32 + - + name: to-tmr + type: u32 + - + name: burst-cnt + type: u32 + - + name: burst-tmr + type: u32 operations: enum-model: directional @@ -251,20 +920,197 @@ operations: do: &strset-get-op request: - value: 1 attributes: - header - stringsets - counts-only reply: - value: 1 attributes: - header - stringsets dump: *strset-get-op + - + name: linkinfo-get + doc: Get link info. + + attribute-set: linkinfo + + do: &linkinfo-get-op + request: + attributes: + - header + reply: + attributes: &linkinfo + - header + - port + - phyaddr + - tp-mdix + - tp-mdix-ctrl + - transceiver + dump: *linkinfo-get-op + - + name: linkinfo-set + doc: Set link info. + + attribute-set: linkinfo + + do: + request: + attributes: *linkinfo + - + name: linkinfo-ntf + doc: Notification for change in link info. + notify: linkinfo-get + - + name: linkmodes-get + doc: Get link modes. + + attribute-set: linkmodes + + do: &linkmodes-get-op + request: + attributes: + - header + reply: + attributes: &linkmodes + - header + - autoneg + - ours + - peer + - speed + - duplex + - master-slave-cfg + - master-slave-state + - master-slave-lanes + - rate-matching + dump: *linkmodes-get-op + - + name: linkmodes-set + doc: Set link modes. + + attribute-set: linkmodes + + do: + request: + attributes: *linkmodes + - + name: linkmodes-ntf + doc: Notification for change in link modes. + notify: linkmodes-get + - + name: linkstate-get + doc: Get link state. + + attribute-set: linkstate + + do: &linkstate-get-op + request: + attributes: + - header + reply: + attributes: + - header + - link + - sqi + - sqi-max + - ext-state + - ext-substate + - down-cnt + dump: *linkstate-get-op + - + name: debug-get + doc: Get debug message mask. + + attribute-set: debug + + do: &debug-get-op + request: + attributes: + - header + reply: + attributes: &debug + - header + - msgmask + dump: *debug-get-op + - + name: debug-set + doc: Set debug message mask. + + attribute-set: debug - # TODO: fill in the requests in between + do: + request: + attributes: *debug + - + name: debug-ntf + doc: Notification for change in debug message mask. + notify: debug-get + - + name: wol-get + doc: Get WOL params. + + attribute-set: wol + + do: &wol-get-op + request: + attributes: + - header + reply: + attributes: &wol + - header + - modes + - sopass + dump: *wol-get-op + - + name: wol-set + doc: Set WOL params. + + attribute-set: wol + + do: + request: + attributes: *wol + - + name: wol-ntf + doc: Notification for change in WOL params. + notify: wol-get + - + name: features-get + doc: Get features. + + attribute-set: features + + do: &feature-get-op + request: + attributes: + - header + reply: + attributes: &feature + - header + # User-changeable features. + - hw + # User-requested features. + - wanted + # Currently active features. + - active + # Unchangeable features. + - nochange + dump: *feature-get-op + - + name: features-set + doc: Set features. + + attribute-set: features + do: &feature-set-op + request: + attributes: *feature + reply: + attributes: *feature + - + name: features-ntf + doc: Notification for change in features. + notify: features-get - name: privflags-get doc: Get device private flags. @@ -273,12 +1119,10 @@ operations: do: &privflag-get-op request: - value: 13 attributes: - header reply: - value: 14 - attributes: + attributes: &privflag - header - flags dump: *privflag-get-op @@ -290,9 +1134,7 @@ operations: do: request: - attributes: - - header - - flags + attributes: *privflag - name: privflags-ntf doc: Notification for change in device private flags. @@ -309,7 +1151,7 @@ operations: attributes: - header reply: - attributes: + attributes: &ring - header - rx-max - rx-mini-max @@ -324,6 +1166,8 @@ operations: - cqe-size - tx-push - rx-push + - tx-push-buf-len + - tx-push-buf-len-max dump: *ring-get-op - name: rings-set @@ -333,24 +1177,431 @@ operations: do: request: + attributes: *ring + - + name: rings-ntf + doc: Notification for change in ring params. + notify: rings-get + - + name: channels-get + doc: Get channel params. + + attribute-set: channels + + do: &channel-get-op + request: + attributes: + - header + reply: + attributes: &channel + - header + - rx-max + - tx-max + - other-max + - combined-max + - rx-count + - tx-count + - other-count + - combined-count + dump: *channel-get-op + - + name: channels-set + doc: Set channel params. + + attribute-set: channels + + do: + request: + attributes: *channel + - + name: channels-ntf + doc: Notification for change in channel params. + notify: channels-get + - + name: coalesce-get + doc: Get coalesce params. + + attribute-set: coalesce + + do: &coalesce-get-op + request: + attributes: + - header + reply: + attributes: &coalesce + - header + - rx-usecs + - rx-max-frames + - rx-usecs-irq + - rx-max-frames-irq + - tx-usecs + - tx-max-frames + - tx-usecs-irq + - tx-max-frames-irq + - stats-block-usecs + - use-adaptive-rx + - use-adaptive-tx + - pkt-rate-low + - rx-usecs-low + - rx-max-frames-low + - tx-usecs-low + - tx-max-frames-low + - pkt-rate-high + - rx-usecs-high + - rx-max-frames-high + - tx-usecs-high + - tx-max-frames-high + - rate-sample-interval + - use-cqe-mode-tx + - use-cqe-mode-rx + - tx-aggr-max-bytes + - tx-aggr-max-frames + - tx-aggr-time-usecs + dump: *coalesce-get-op + - + name: coalesce-set + doc: Set coalesce params. + + attribute-set: coalesce + + do: + request: + attributes: *coalesce + - + name: coalesce-ntf + doc: Notification for change in coalesce params. + notify: coalesce-get + - + name: pause-get + doc: Get pause params. + + attribute-set: pause + + do: &pause-get-op + request: attributes: - header + reply: + attributes: &pause + - header + - autoneg - rx - - rx-mini - - rx-jumbo - tx - - rx-buf-len - - tcp-data-split - - cqe-size - - tx-push - - rx-push + - stats + - stats-src + dump: *pause-get-op - - name: rings-ntf - doc: Notification for change in ring params. - notify: rings-get + name: pause-set + doc: Set pause params. + + attribute-set: pause + + do: + request: + attributes: *pause + - + name: pause-ntf + doc: Notification for change in pause params. + notify: pause-get + - + name: eee-get + doc: Get eee params. + + attribute-set: eee + + do: &eee-get-op + request: + attributes: + - header + reply: + attributes: &eee + - header + - modes-ours + - modes-peer + - active + - enabled + - tx-lpi-enabled + - tx-lpi-timer + dump: *eee-get-op + - + name: eee-set + doc: Set eee params. + + attribute-set: eee + + do: + request: + attributes: *eee + - + name: eee-ntf + doc: Notification for change in eee params. + notify: eee-get + - + name: tsinfo-get + doc: Get tsinfo params. + + attribute-set: tsinfo + + do: &tsinfo-get-op + request: + attributes: + - header + reply: + attributes: + - header + - timestamping + - tx-types + - rx-filters + - phc-index + dump: *tsinfo-get-op + - + name: cable-test-act + doc: Cable test. + + attribute-set: cable-test + + do: + request: + attributes: + - header + reply: + attributes: + - header + - cable-test-nft-nest + - + name: cable-test-tdr-act + doc: Cable test TDR. + + attribute-set: cable-test-tdr + + do: + request: + attributes: + - header + reply: + attributes: + - header + - cable-test-tdr-cfg + - + name: tunnel-info-get + doc: Get tsinfo params. + + attribute-set: tunnel-info + + do: &tunnel-info-get-op + request: + attributes: + - header + reply: + attributes: + - header + - udp-ports + dump: *tunnel-info-get-op + - + name: fec-get + doc: Get FEC params. - # TODO: fill in the requests in between + attribute-set: fec + do: &fec-get-op + request: + attributes: + - header + reply: + attributes: &fec + - header + - modes + - auto + - active + - stats + dump: *fec-get-op + - + name: fec-set + doc: Set FEC params. + + attribute-set: fec + + do: + request: + attributes: *fec + - + name: fec-ntf + doc: Notification for change in FEC params. + notify: fec-get + - + name: module-eeprom-get + doc: Get module EEPROM params. + + attribute-set: module-eeprom + + do: &module-eeprom-get-op + request: + attributes: + - header + reply: + attributes: + - header + - offset + - length + - page + - bank + - i2c-address + - data + dump: *module-eeprom-get-op + - + name: stats-get + doc: Get statistics. + + attribute-set: stats + + do: &stats-get-op + request: + attributes: + - header + - groups + reply: + attributes: + - header + - groups + - grp + - src + dump: *stats-get-op + - + name: phc-vclocks-get + doc: Get PHC VCLOCKs. + + attribute-set: phc-vclocks + + do: &phc-vclocks-get-op + request: + attributes: + - header + reply: + attributes: + - header + - num + dump: *phc-vclocks-get-op + - + name: module-get + doc: Get module params. + + attribute-set: module + + do: &module-get-op + request: + attributes: + - header + reply: + attributes: &module + - header + - power-mode-policy + - power-mode + dump: *module-get-op + - + name: module-set + doc: Set module params. + + attribute-set: module + + do: + request: + attributes: *module + - + name: module-ntf + doc: Notification for change in module params. + notify: module-get + - + name: pse-get + doc: Get Power Sourcing Equipment params. + + attribute-set: pse + + do: &pse-get-op + request: + attributes: + - header + reply: + attributes: &pse + - header + - admin-state + - admin-control + - pw-d-status + dump: *pse-get-op + - + name: pse-set + doc: Set Power Sourcing Equipment params. + + attribute-set: pse + + do: + request: + attributes: *pse + - + name: rss-get + doc: Get RSS params. + + attribute-set: rss + + do: &rss-get-op + request: + attributes: + - header + reply: + attributes: + - header + - context + - hfunc + - indir + - hkey + dump: *rss-get-op + - + name: plca-get + doc: Get PLCA params. + + attribute-set: plca + + do: &plca-get-op + request: + attributes: + - header + reply: + attributes: &plca + - header + - version + - enabled + - status + - node-cnt + - node-id + - to-tmr + - burst-cnt + - burst-tmr + dump: *plca-get-op + - + name: plca-set + doc: Set PLCA params. + + attribute-set: plca + + do: + request: + attributes: *plca + - + name: plca-get-status + doc: Get PLCA status params. + + attribute-set: plca + + do: &plca-get-status-op + request: + attributes: + - header + reply: + attributes: *plca + dump: *plca-get-status-op + - + name: plca-ntf + doc: Notification for change in PLCA params. + notify: plca-get - name: mm-get doc: Get MAC Merge configuration and state @@ -359,11 +1610,9 @@ operations: do: &mm-get-op request: - value: 42 attributes: - header reply: - value: 42 attributes: - header - pmac-enabled diff --git a/Documentation/netlink/specs/fou.yaml b/Documentation/netlink/specs/fou.yaml index 266c386eedf3..3e13826a3fdf 100644 --- a/Documentation/netlink/specs/fou.yaml +++ b/Documentation/netlink/specs/fou.yaml @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + name: fou protocol: genetlink-legacy @@ -26,6 +28,7 @@ attribute-sets: - name: unspec type: unused + value: 0 - name: port type: u16 @@ -71,6 +74,7 @@ operations: - name: unspec doc: unused + value: 0 - name: add diff --git a/Documentation/netlink/specs/handshake.yaml b/Documentation/netlink/specs/handshake.yaml new file mode 100644 index 000000000000..614f1a585511 --- /dev/null +++ b/Documentation/netlink/specs/handshake.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) +# +# Author: Chuck Lever <chuck.lever@oracle.com> +# +# Copyright (c) 2023, Oracle and/or its affiliates. +# + +name: handshake + +protocol: genetlink + +doc: Netlink protocol to request a transport layer security handshake. + +definitions: + - + type: enum + name: handler-class + value-start: 0 + entries: [ none, tlshd, max ] + - + type: enum + name: msg-type + value-start: 0 + entries: [ unspec, clienthello, serverhello ] + - + type: enum + name: auth + value-start: 0 + entries: [ unspec, unauth, psk, x509 ] + +attribute-sets: + - + name: x509 + attributes: + - + name: cert + type: u32 + - + name: privkey + type: u32 + - + name: accept + attributes: + - + name: sockfd + type: u32 + - + name: handler-class + type: u32 + enum: handler-class + - + name: message-type + type: u32 + enum: msg-type + - + name: timeout + type: u32 + - + name: auth-mode + type: u32 + enum: auth + - + name: peer-identity + type: u32 + multi-attr: true + - + name: certificate + type: nest + nested-attributes: x509 + multi-attr: true + - + name: done + attributes: + - + name: status + type: u32 + - + name: sockfd + type: u32 + - + name: remote-auth + type: u32 + multi-attr: true + +operations: + list: + - + name: ready + doc: Notify handlers that a new handshake request is waiting + notify: accept + - + name: accept + doc: Handler retrieves next queued handshake request + attribute-set: accept + flags: [ admin-perm ] + do: + request: + attributes: + - handler-class + reply: + attributes: + - sockfd + - message-type + - timeout + - auth-mode + - peer-identity + - certificate + - + name: done + doc: Handler reports handshake completion + attribute-set: done + do: + request: + attributes: + - status + - sockfd + - remote-auth + +mcast-groups: + list: + - + name: none + - + name: tlshd diff --git a/Documentation/netlink/specs/netdev.yaml b/Documentation/netlink/specs/netdev.yaml index cffef09729f1..b99e7ffef7a1 100644 --- a/Documentation/netlink/specs/netdev.yaml +++ b/Documentation/netlink/specs/netdev.yaml @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + name: netdev doc: @@ -7,6 +9,7 @@ definitions: - type: flags name: xdp-act + render-max: true entries: - name: basic @@ -48,7 +51,6 @@ attribute-sets: name: ifindex doc: netdev ifindex type: u32 - value: 1 checks: min: 1 - @@ -66,7 +68,6 @@ operations: - name: dev-get doc: Get / dump information about a netdev. - value: 1 attribute-set: dev do: request: diff --git a/Documentation/netlink/specs/ovs_datapath.yaml b/Documentation/netlink/specs/ovs_datapath.yaml new file mode 100644 index 000000000000..6d71db8c4416 --- /dev/null +++ b/Documentation/netlink/specs/ovs_datapath.yaml @@ -0,0 +1,153 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: ovs_datapath +version: 2 +protocol: genetlink-legacy + +doc: + OVS datapath configuration over generic netlink. + +definitions: + - + name: ovs-header + type: struct + members: + - + name: dp-ifindex + type: u32 + - + name: user-features + type: flags + entries: + - + name: unaligned + doc: Allow last Netlink attribute to be unaligned + - + name: vport-pids + doc: Allow datapath to associate multiple Netlink PIDs to each vport + - + name: tc-recirc-sharing + doc: Allow tc offload recirc sharing + - + name: dispatch-upcall-per-cpu + doc: Allow per-cpu dispatch of upcalls + - + name: datapath-stats + type: struct + members: + - + name: hit + type: u64 + - + name: missed + type: u64 + - + name: lost + type: u64 + - + name: flows + type: u64 + - + name: megaflow-stats + type: struct + members: + - + name: mask-hit + type: u64 + - + name: masks + type: u32 + - + name: padding + type: u32 + - + name: cache-hits + type: u64 + - + name: pad1 + type: u64 + +attribute-sets: + - + name: datapath + attributes: + - + name: name + type: string + - + name: upcall-pid + doc: upcall pid + type: u32 + - + name: stats + type: binary + struct: datapath-stats + - + name: megaflow-stats + type: binary + struct: megaflow-stats + - + name: user-features + type: u32 + enum: user-features + enum-as-flags: true + - + name: pad + type: unused + - + name: masks-cache-size + type: u32 + - + name: per-cpu-pids + type: binary + sub-type: u32 + +operations: + fixed-header: ovs-header + list: + - + name: dp-get + doc: Get / dump OVS data path configuration and state + value: 3 + attribute-set: datapath + do: &dp-get-op + request: + attributes: + - name + reply: + attributes: + - name + - upcall-pid + - stats + - megaflow-stats + - user-features + - masks-cache-size + - per-cpu-pids + dump: *dp-get-op + - + name: dp-new + doc: Create new OVS data path + value: 1 + attribute-set: datapath + do: + request: + attributes: + - dp-ifindex + - name + - upcall-pid + - user-features + - + name: dp-del + doc: Delete existing OVS data path + value: 2 + attribute-set: datapath + do: + request: + attributes: + - dp-ifindex + - name + +mcast-groups: + list: + - + name: ovs_datapath diff --git a/Documentation/netlink/specs/ovs_vport.yaml b/Documentation/netlink/specs/ovs_vport.yaml new file mode 100644 index 000000000000..8e55622ddf11 --- /dev/null +++ b/Documentation/netlink/specs/ovs_vport.yaml @@ -0,0 +1,139 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: ovs_vport +version: 2 +protocol: genetlink-legacy + +doc: + OVS vport configuration over generic netlink. + +definitions: + - + name: ovs-header + type: struct + members: + - + name: dp-ifindex + type: u32 + - + name: vport-type + type: enum + entries: [ unspec, netdev, internal, gre, vxlan, geneve ] + - + name: vport-stats + type: struct + members: + - + name: rx-packets + type: u64 + - + name: tx-packets + type: u64 + - + name: rx-bytes + type: u64 + - + name: tx-bytes + type: u64 + - + name: rx-errors + type: u64 + - + name: tx-errors + type: u64 + - + name: rx-dropped + type: u64 + - + name: tx-dropped + type: u64 + +attribute-sets: + - + name: vport-options + attributes: + - + name: dst-port + type: u32 + - + name: extension + type: u32 + - + name: upcall-stats + attributes: + - + name: success + type: u64 + value: 0 + - + name: fail + type: u64 + - + name: vport + attributes: + - + name: port-no + type: u32 + - + name: type + type: u32 + enum: vport-type + - + name: name + type: string + - + name: options + type: nest + nested-attributes: vport-options + - + name: upcall-pid + type: binary + sub-type: u32 + - + name: stats + type: binary + struct: vport-stats + - + name: pad + type: unused + - + name: ifindex + type: u32 + - + name: netnsid + type: u32 + - + name: upcall-stats + type: nest + nested-attributes: upcall-stats + +operations: + list: + - + name: vport-get + doc: Get / dump OVS vport configuration and state + value: 3 + attribute-set: vport + fixed-header: ovs-header + do: &vport-get-op + request: + attributes: + - dp-ifindex + - name + reply: &dev-all + attributes: + - dp-ifindex + - port-no + - type + - name + - upcall-pid + - stats + - ifindex + - netnsid + - upcall-stats + dump: *vport-get-op + +mcast-groups: + list: + - + name: ovs_vport diff --git a/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst b/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst index 1a4fc6607582..1661d13174d5 100644 --- a/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst +++ b/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst @@ -229,8 +229,7 @@ frames for a while. This has a potential to avoid the costly round of enabling interrupts, handling an incoming IRQ in ISR, re-enabling the softirq and switching context back to softirq. -More detailed documentation of NAPI may be found on the pages of Linux -Foundation `<https://wiki.linuxfoundation.org/networking/napi>`_. +See :ref:`Documentation/networking/napi.rst <napi>` for more information. Integrating the core to Xilinx Zynq ----------------------------------- diff --git a/Documentation/networking/device_drivers/ethernet/amd/pds_core.rst b/Documentation/networking/device_drivers/ethernet/amd/pds_core.rst new file mode 100644 index 000000000000..9e8a16c44102 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/amd/pds_core.rst @@ -0,0 +1,139 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +======================================================== +Linux Driver for the AMD/Pensando(R) DSC adapter family +======================================================== + +Copyright(c) 2023 Advanced Micro Devices, Inc + +Identifying the Adapter +======================= + +To find if one or more AMD/Pensando PCI Core devices are installed on the +host, check for the PCI devices:: + + # lspci -d 1dd8:100c + b5:00.0 Processing accelerators: Pensando Systems Device 100c + b6:00.0 Processing accelerators: Pensando Systems Device 100c + +If such devices are listed as above, then the pds_core.ko driver should find +and configure them for use. There should be log entries in the kernel +messages such as these:: + + $ dmesg | grep pds_core + pds_core 0000:b5:00.0: 252.048 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x16 link) + pds_core 0000:b5:00.0: FW: 1.60.0-73 + pds_core 0000:b6:00.0: 252.048 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x16 link) + pds_core 0000:b6:00.0: FW: 1.60.0-73 + +Driver and firmware version information can be gathered with devlink:: + + $ devlink dev info pci/0000:b5:00.0 + pci/0000:b5:00.0: + driver pds_core + serial_number FLM18420073 + versions: + fixed: + asic.id 0x0 + asic.rev 0x0 + running: + fw 1.51.0-73 + stored: + fw.goldfw 1.15.9-C-22 + fw.mainfwa 1.60.0-73 + fw.mainfwb 1.60.0-57 + +Info versions +============= + +The ``pds_core`` driver reports the following versions + +.. list-table:: devlink info versions implemented + :widths: 5 5 90 + + * - Name + - Type + - Description + * - ``fw`` + - running + - Version of firmware running on the device + * - ``fw.goldfw`` + - stored + - Version of firmware stored in the goldfw slot + * - ``fw.mainfwa`` + - stored + - Version of firmware stored in the mainfwa slot + * - ``fw.mainfwb`` + - stored + - Version of firmware stored in the mainfwb slot + * - ``asic.id`` + - fixed + - The ASIC type for this device + * - ``asic.rev`` + - fixed + - The revision of the ASIC for this device + +Parameters +========== + +The ``pds_core`` driver implements the following generic +parameters for controlling the functionality to be made available +as auxiliary_bus devices. + +.. list-table:: Generic parameters implemented + :widths: 5 5 8 82 + + * - Name + - Mode + - Type + - Description + * - ``enable_vnet`` + - runtime + - Boolean + - Enables vDPA functionality through an auxiliary_bus device + +Firmware Management +=================== + +The ``flash`` command can update a the DSC firmware. The downloaded firmware +will be saved into either of firmware bank 1 or bank 2, whichever is not +currently in use, and that bank will used for the next boot:: + + # devlink dev flash pci/0000:b5:00.0 \ + file pensando/dsc_fw_1.63.0-22.tar + +Health Reporters +================ + +The driver supports a devlink health reporter for FW status:: + + # devlink health show pci/0000:2b:00.0 reporter fw + pci/0000:2b:00.0: + reporter fw + state healthy error 0 recover 0 + # devlink health diagnose pci/0000:2b:00.0 reporter fw + Status: healthy State: 1 Generation: 0 Recoveries: 0 + +Enabling the driver +=================== + +The driver is enabled via the standard kernel configuration system, +using the make command:: + + make oldconfig/menuconfig/etc. + +The driver is located in the menu structure at: + + -> Device Drivers + -> Network device support (NETDEVICES [=y]) + -> Ethernet driver support + -> AMD devices + -> AMD/Pensando Ethernet PDS_CORE Support + +Support +======= + +For general Linux networking support, please use the netdev mailing +list, which is monitored by AMD/Pensando personnel:: + + netdev@vger.kernel.org diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst index 392969ac88ad..417ca514a4d0 100644 --- a/Documentation/networking/device_drivers/ethernet/index.rst +++ b/Documentation/networking/device_drivers/ethernet/index.rst @@ -14,6 +14,7 @@ Contents: 3com/vortex amazon/ena altera/altera_tse + amd/pds_core aquantia/atlantic chelsio/cxgb cirrus/cs89x0 @@ -31,7 +32,6 @@ Contents: intel/fm10k intel/igb intel/igbvf - intel/ixgb intel/ixgbe intel/ixgbevf intel/i40e diff --git a/Documentation/networking/device_drivers/ethernet/intel/e100.rst b/Documentation/networking/device_drivers/ethernet/intel/e100.rst index 3d4a9ba21946..5dee1b53e977 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/e100.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/e100.rst @@ -151,8 +151,7 @@ NAPI NAPI (Rx polling mode) is supported in the e100 driver. -See https://wiki.linuxfoundation.org/networking/napi for more -information on NAPI. +See :ref:`Documentation/networking/napi.rst <napi>` for more information. Multiple Interfaces on Same Ethernet Broadcast Network ------------------------------------------------------ @@ -181,8 +180,6 @@ Support For general information, go to the Intel support website at: https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: -http://sourceforge.net/projects/e1000 If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/intel/e1000.rst b/Documentation/networking/device_drivers/ethernet/intel/e1000.rst index 4aaae0f7d6ba..52a7fb9ce8d9 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/e1000.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/e1000.rst @@ -451,13 +451,8 @@ Support ======= For general information, go to the Intel support website at: - - http://support.intel.com - -or the Intel Wired Networking project hosted by Sourceforge at: - - http://sourceforge.net/projects/e1000 +http://support.intel.com If an issue is identified with the released source code on the supported kernel with a supported adapter, email the specific information related -to the issue to e1000-devel@lists.sf.net +to the issue to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst b/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst index f49cd370e7bf..d8f810afdd49 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst @@ -371,13 +371,8 @@ NOTE: Wake on LAN is only supported on port A for the following devices: Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst b/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst index 9258ef6f515c..396a2c8c3db1 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst @@ -130,13 +130,8 @@ the Intel Ethernet Controller XL710. Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst index ac35bd472bdc..4fbaa1a2d674 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst @@ -399,8 +399,8 @@ operate only in full duplex and only at their native speed. NAPI ---- NAPI (Rx polling mode) is supported in the i40e driver. -For more information on NAPI, see -https://wiki.linuxfoundation.org/networking/napi + +See :ref:`Documentation/networking/napi.rst <napi>` for more information. Flow Control ------------ @@ -759,13 +759,8 @@ enabled when setting up DCB on your switch. Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst index 151af0a8da9c..eb926c3bd4cd 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst @@ -319,13 +319,8 @@ This is caused by the way the Linux kernel reports this stressed condition. Support ======= For general information, go to the Intel support website at: - https://support.intel.com -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on the supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst index 5efea4dd1251..69695e5511f4 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/ice.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst @@ -817,10 +817,10 @@ NOTE: NAPI ---- + This driver supports NAPI (Rx polling mode). -For more information on NAPI, see -https://wiki.linuxfoundation.org/networking/napi +See :ref:`Documentation/networking/napi.rst <napi>` for more information. MACVLAN ------- @@ -1026,12 +1026,9 @@ Support For general information, go to the Intel support website at: https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. Trademarks diff --git a/Documentation/networking/device_drivers/ethernet/intel/igb.rst b/Documentation/networking/device_drivers/ethernet/intel/igb.rst index d46289e182cf..fbd590b6a0d6 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/igb.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/igb.rst @@ -201,13 +201,8 @@ NOTE: This feature is exclusive to i210 models. Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst b/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst index 40fa210c5e14..11a9017f3069 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst @@ -53,13 +53,8 @@ https://www.kernel.org/pub/software/network/ethtool/ Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/intel/ixgb.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgb.rst deleted file mode 100644 index c6a233e68ad6..000000000000 --- a/Documentation/networking/device_drivers/ethernet/intel/ixgb.rst +++ /dev/null @@ -1,468 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0+ - -===================================================================== -Linux Base Driver for 10 Gigabit Intel(R) Ethernet Network Connection -===================================================================== - -October 1, 2018 - - -Contents -======== - -- In This Release -- Identifying Your Adapter -- Command Line Parameters -- Improving Performance -- Additional Configurations -- Known Issues/Troubleshooting -- Support - - - -In This Release -=============== - -This file describes the ixgb Linux Base Driver for the 10 Gigabit Intel(R) -Network Connection. This driver includes support for Itanium(R)2-based -systems. - -For questions related to hardware requirements, refer to the documentation -supplied with your 10 Gigabit adapter. All hardware requirements listed apply -to use with Linux. - -The following features are available in this kernel: - - Native VLANs - - Channel Bonding (teaming) - - SNMP - -Channel Bonding documentation can be found in the Linux kernel source: -/Documentation/networking/bonding.rst - -The driver information previously displayed in the /proc filesystem is not -supported in this release. Alternatively, you can use ethtool (version 1.6 -or later), lspci, and iproute2 to obtain the same information. - -Instructions on updating ethtool can be found in the section "Additional -Configurations" later in this document. - - -Identifying Your Adapter -======================== - -The following Intel network adapters are compatible with the drivers in this -release: - -+------------+------------------------------+----------------------------------+ -| Controller | Adapter Name | Physical Layer | -+============+==============================+==================================+ -| 82597EX | Intel(R) PRO/10GbE LR/SR/CX4 | - 10G Base-LR (fiber) | -| | Server Adapters | - 10G Base-SR (fiber) | -| | | - 10G Base-CX4 (copper) | -+------------+------------------------------+----------------------------------+ - -For more information on how to identify your adapter, go to the Adapter & -Driver ID Guide at: - - https://support.intel.com - - -Command Line Parameters -======================= - -If the driver is built as a module, the following optional parameters are -used by entering them on the command line with the modprobe command using -this syntax:: - - modprobe ixgb [<option>=<VAL1>,<VAL2>,...] - -For example, with two 10GbE PCI adapters, entering:: - - modprobe ixgb TxDescriptors=80,128 - -loads the ixgb driver with 80 TX resources for the first adapter and 128 TX -resources for the second adapter. - -The default value for each parameter is generally the recommended setting, -unless otherwise noted. - -Copybreak ---------- -:Valid Range: 0-XXXX -:Default Value: 256 - - This is the maximum size of packet that is copied to a new buffer on - receive. - -Debug ------ -:Valid Range: 0-16 (0=none,...,16=all) -:Default Value: 0 - - This parameter adjusts the level of debug messages displayed in the - system logs. - -FlowControl ------------ -:Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx) -:Default Value: 1 if no EEPROM, otherwise read from EEPROM - - This parameter controls the automatic generation(Tx) and response(Rx) to - Ethernet PAUSE frames. There are hardware bugs associated with enabling - Tx flow control so beware. - -RxDescriptors -------------- -:Valid Range: 64-4096 -:Default Value: 1024 - - This value is the number of receive descriptors allocated by the driver. - Increasing this value allows the driver to buffer more incoming packets. - Each descriptor is 16 bytes. A receive buffer is also allocated for - each descriptor and can be either 2048, 4056, 8192, or 16384 bytes, - depending on the MTU setting. When the MTU size is 1500 or less, the - receive buffer size is 2048 bytes. When the MTU is greater than 1500 the - receive buffer size will be either 4056, 8192, or 16384 bytes. The - maximum MTU size is 16114. - -TxDescriptors -------------- -:Valid Range: 64-4096 -:Default Value: 256 - - This value is the number of transmit descriptors allocated by the driver. - Increasing this value allows the driver to queue more transmits. Each - descriptor is 16 bytes. - -RxIntDelay ----------- -:Valid Range: 0-65535 (0=off) -:Default Value: 72 - - This value delays the generation of receive interrupts in units of - 0.8192 microseconds. Receive interrupt reduction can improve CPU - efficiency if properly tuned for specific network traffic. Increasing - this value adds extra latency to frame reception and can end up - decreasing the throughput of TCP traffic. If the system is reporting - dropped receives, this value may be set too high, causing the driver to - run out of available receive descriptors. - -TxIntDelay ----------- -:Valid Range: 0-65535 (0=off) -:Default Value: 32 - - This value delays the generation of transmit interrupts in units of - 0.8192 microseconds. Transmit interrupt reduction can improve CPU - efficiency if properly tuned for specific network traffic. Increasing - this value adds extra latency to frame transmission and can end up - decreasing the throughput of TCP traffic. If this value is set too high, - it will cause the driver to run out of available transmit descriptors. - -XsumRX ------- -:Valid Range: 0-1 -:Default Value: 1 - - A value of '1' indicates that the driver should enable IP checksum - offload for received packets (both UDP and TCP) to the adapter hardware. - -RxFCHighThresh --------------- -:Valid Range: 1,536-262,136 (0x600 - 0x3FFF8, 8 byte granularity) -:Default Value: 196,608 (0x30000) - - Receive Flow control high threshold (when we send a pause frame) - -RxFCLowThresh -------------- -:Valid Range: 64-262,136 (0x40 - 0x3FFF8, 8 byte granularity) -:Default Value: 163,840 (0x28000) - - Receive Flow control low threshold (when we send a resume frame) - -FCReqTimeout ------------- -:Valid Range: 1-65535 -:Default Value: 65535 - - Flow control request timeout (how long to pause the link partner's tx) - -IntDelayEnable --------------- -:Value Range: 0,1 -:Default Value: 1 - - Interrupt Delay, 0 disables transmit interrupt delay and 1 enables it. - - -Improving Performance -===================== - -With the 10 Gigabit server adapters, the default Linux configuration will -very likely limit the total available throughput artificially. There is a set -of configuration changes that, when applied together, will increase the ability -of Linux to transmit and receive data. The following enhancements were -originally acquired from settings published at https://www.spec.org/web99/ for -various submitted results using Linux. - -NOTE: - These changes are only suggestions, and serve as a starting point for - tuning your network performance. - -The changes are made in three major ways, listed in order of greatest effect: - -- Use ip link to modify the mtu (maximum transmission unit) and the txqueuelen - parameter. -- Use sysctl to modify /proc parameters (essentially kernel tuning) -- Use setpci to modify the MMRBC field in PCI-X configuration space to increase - transmit burst lengths on the bus. - -NOTE: - setpci modifies the adapter's configuration registers to allow it to read - up to 4k bytes at a time (for transmits). However, for some systems the - behavior after modifying this register may be undefined (possibly errors of - some kind). A power-cycle, hard reset or explicitly setting the e6 register - back to 22 (setpci -d 8086:1a48 e6.b=22) may be required to get back to a - stable configuration. - -- COPY these lines and paste them into ixgb_perf.sh: - -:: - - #!/bin/bash - echo "configuring network performance , edit this file to change the interface - or device ID of 10GbE card" - # set mmrbc to 4k reads, modify only Intel 10GbE device IDs - # replace 1a48 with appropriate 10GbE device's ID installed on the system, - # if needed. - setpci -d 8086:1a48 e6.b=2e - # set the MTU (max transmission unit) - it requires your switch and clients - # to change as well. - # set the txqueuelen - # your ixgb adapter should be loaded as eth1 for this to work, change if needed - ip li set dev eth1 mtu 9000 txqueuelen 1000 up - # call the sysctl utility to modify /proc/sys entries - sysctl -p ./sysctl_ixgb.conf - -- COPY these lines and paste them into sysctl_ixgb.conf: - -:: - - # some of the defaults may be different for your kernel - # call this file with sysctl -p <this file> - # these are just suggested values that worked well to increase throughput in - # several network benchmark tests, your mileage may vary - - ### IPV4 specific settings - # turn TCP timestamp support off, default 1, reduces CPU use - net.ipv4.tcp_timestamps = 0 - # turn SACK support off, default on - # on systems with a VERY fast bus -> memory interface this is the big gainer - net.ipv4.tcp_sack = 0 - # set min/default/max TCP read buffer, default 4096 87380 174760 - net.ipv4.tcp_rmem = 10000000 10000000 10000000 - # set min/pressure/max TCP write buffer, default 4096 16384 131072 - net.ipv4.tcp_wmem = 10000000 10000000 10000000 - # set min/pressure/max TCP buffer space, default 31744 32256 32768 - net.ipv4.tcp_mem = 10000000 10000000 10000000 - - ### CORE settings (mostly for socket and UDP effect) - # set maximum receive socket buffer size, default 131071 - net.core.rmem_max = 524287 - # set maximum send socket buffer size, default 131071 - net.core.wmem_max = 524287 - # set default receive socket buffer size, default 65535 - net.core.rmem_default = 524287 - # set default send socket buffer size, default 65535 - net.core.wmem_default = 524287 - # set maximum amount of option memory buffers, default 10240 - net.core.optmem_max = 524287 - # set number of unprocessed input packets before kernel starts dropping them; default 300 - net.core.netdev_max_backlog = 300000 - -Edit the ixgb_perf.sh script if necessary to change eth1 to whatever interface -your ixgb driver is using and/or replace '1a48' with appropriate 10GbE device's -ID installed on the system. - -NOTE: - Unless these scripts are added to the boot process, these changes will - only last only until the next system reboot. - - -Resolving Slow UDP Traffic --------------------------- -If your server does not seem to be able to receive UDP traffic as fast as it -can receive TCP traffic, it could be because Linux, by default, does not set -the network stack buffers as large as they need to be to support high UDP -transfer rates. One way to alleviate this problem is to allow more memory to -be used by the IP stack to store incoming data. - -For instance, use the commands:: - - sysctl -w net.core.rmem_max=262143 - -and:: - - sysctl -w net.core.rmem_default=262143 - -to increase the read buffer memory max and default to 262143 (256k - 1) from -defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables -will increase the amount of memory used by the network stack for receives, and -can be increased significantly more if necessary for your application. - - -Additional Configurations -========================= - -Configuring the Driver on Different Distributions -------------------------------------------------- -Configuring a network driver to load properly when the system is started is -distribution dependent. Typically, the configuration process involves adding -an alias line to /etc/modprobe.conf as well as editing other system startup -scripts and/or configuration files. Many popular Linux distributions ship -with tools to make these changes for you. To learn the proper way to -configure a network device for your system, refer to your distribution -documentation. If during this process you are asked for the driver or module -name, the name for the Linux Base Driver for the Intel 10GbE Family of -Adapters is ixgb. - -Viewing Link Messages ---------------------- -Link messages will not be displayed to the console if the distribution is -restricting system messages. In order to see network driver link messages on -your console, set dmesg to eight by entering the following:: - - dmesg -n 8 - -NOTE: This setting is not saved across reboots. - -Jumbo Frames ------------- -The driver supports Jumbo Frames for all adapters. Jumbo Frames support is -enabled by changing the MTU to a value larger than the default of 1500. -The maximum value for the MTU is 16114. Use the ip command to -increase the MTU size. For example:: - - ip li set dev ethx mtu 9000 - -The maximum MTU setting for Jumbo Frames is 16114. This value coincides -with the maximum Jumbo Frames size of 16128. - -Ethtool -------- -The driver utilizes the ethtool interface for driver configuration and -diagnostics, as well as displaying statistical information. The ethtool -version 1.6 or later is required for this functionality. - -The latest release of ethtool can be found from -https://www.kernel.org/pub/software/network/ethtool/ - -NOTE: - The ethtool version 1.6 only supports a limited set of ethtool options. - Support for a more complete ethtool feature set can be enabled by - upgrading to the latest version. - -NAPI ----- -NAPI (Rx polling mode) is supported in the ixgb driver. - -See https://wiki.linuxfoundation.org/networking/napi for more information on -NAPI. - - -Known Issues/Troubleshooting -============================ - -NOTE: - After installing the driver, if your Intel Network Connection is not - working, verify in the "In This Release" section of the readme that you have - installed the correct driver. - -Cable Interoperability Issue with Fujitsu XENPAK Module in SmartBits Chassis ----------------------------------------------------------------------------- -Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 -Server adapter is connected to a Fujitsu XENPAK CX4 module in a SmartBits -chassis using 15 m/24AWG cable assemblies manufactured by Fujitsu or Leoni. -The CRC errors may be received either by the Intel(R) PRO/10GbE CX4 -Server adapter or the SmartBits. If this situation occurs using a different -cable assembly may resolve the issue. - -Cable Interoperability Issues with HP Procurve 3400cl Switch Port ------------------------------------------------------------------ -Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 Server -adapter is connected to an HP Procurve 3400cl switch port using short cables -(1 m or shorter). If this situation occurs, using a longer cable may resolve -the issue. - -Excessive CRC errors may be observed using Fujitsu 24AWG cable assemblies that -Are 10 m or longer or where using a Leoni 15 m/24AWG cable assembly. The CRC -errors may be received either by the CX4 Server adapter or at the switch. If -this situation occurs, using a different cable assembly may resolve the issue. - -Jumbo Frames System Requirement -------------------------------- -Memory allocation failures have been observed on Linux systems with 64 MB -of RAM or less that are running Jumbo Frames. If you are using Jumbo -Frames, your system may require more than the advertised minimum -requirement of 64 MB of system memory. - -Performance Degradation with Jumbo Frames ------------------------------------------ -Degradation in throughput performance may be observed in some Jumbo frames -environments. If this is observed, increasing the application's socket buffer -size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help. -See the specific application manual and /usr/src/linux*/Documentation/ -networking/ip-sysctl.txt for more details. - -Allocating Rx Buffers when Using Jumbo Frames ---------------------------------------------- -Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if -the available memory is heavily fragmented. This issue may be seen with PCI-X -adapters or with packet split disabled. This can be reduced or eliminated -by changing the amount of available memory for receive buffer allocation, by -increasing /proc/sys/vm/min_free_kbytes. - -Multiple Interfaces on Same Ethernet Broadcast Network ------------------------------------------------------- -Due to the default ARP behavior on Linux, it is not possible to have -one system on two IP networks in the same Ethernet broadcast domain -(non-partitioned switch) behave as expected. All Ethernet interfaces -will respond to IP traffic for any IP address assigned to the system. -This results in unbalanced receive traffic. - -If you have multiple interfaces in a server, do either of the following: - - - Turn on ARP filtering by entering:: - - echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter - - - Install the interfaces in separate broadcast domains - either in - different switches or in a switch partitioned to VLANs. - -UDP Stress Test Dropped Packet Issue --------------------------------------- -Under small packets UDP stress test with 10GbE driver, the Linux system -may drop UDP packets due to the fullness of socket buffers. You may want -to change the driver's Flow Control variables to the minimum value for -controlling packet reception. - -Tx Hangs Possible Under Stress ------------------------------- -Under stress conditions, if TX hangs occur, turning off TSO -"ethtool -K eth0 tso off" may resolve the problem. - - -Support -======= -For general information, go to the Intel support website at: - -https://www.intel.com/support/ - -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - -If an issue is identified with the released source code on a supported kernel -with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net diff --git a/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst index 0a233b17c664..1e5f16993f69 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst @@ -545,13 +545,8 @@ on the Intel Ethernet Controller XL710. Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst index 76bbde736f21..08dc0d368a48 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst @@ -55,13 +55,8 @@ VLANs: There is a limit of a total of 64 shared VLANs to 1 or more VFs. Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst index 4cd8e869762b..6b2d1fe74ecf 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst @@ -346,32 +346,6 @@ the software port. - The number of receive packets with CQE compression on ring i [#accel]_. - Acceleration - * - `rx[i]_cache_reuse` - - The number of events of successful reuse of a page from a driver's - internal page cache. - - Acceleration - - * - `rx[i]_cache_full` - - The number of events of full internal page cache where driver can't put a - page back to the cache for recycling (page will be freed). - - Acceleration - - * - `rx[i]_cache_empty` - - The number of events where cache was empty - no page to give. Driver - shall allocate new page. - - Acceleration - - * - `rx[i]_cache_busy` - - The number of events where cache head was busy and cannot be recycled. - Driver allocated new page. - - Acceleration - - * - `rx[i]_cache_waive` - - The number of cache evacuation. This can occur due to page move to - another NUMA node or page was pfmemalloc-ed and should be freed as soon - as possible. - - Acceleration - * - `rx[i]_arfs_err` - Number of flow rules that failed to be added to the flow table. - Error diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst index 9b5c40ba7f0d..3a7a714cc08f 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst @@ -122,6 +122,41 @@ users try to enable them. $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev +hairpin_num_queues: Number of hairpin queues +-------------------------------------------- +We refer to a TC NIC rule that involves forwarding as "hairpin". + +Hairpin queues are mlx5 hardware specific implementation for hardware +forwarding of such packets. + +- Show the number of hairpin queues:: + + $ devlink dev param show pci/0000:06:00.0 name hairpin_num_queues + pci/0000:06:00.0: + name hairpin_num_queues type driver-specific + values: + cmode driverinit value 2 + +- Change the number of hairpin queues:: + + $ devlink dev param set pci/0000:06:00.0 name hairpin_num_queues value 4 cmode driverinit + +hairpin_queue_size: Size of the hairpin queues +---------------------------------------------- +Control the size of the hairpin queues. + +- Show the size of the hairpin queues:: + + $ devlink dev param show pci/0000:06:00.0 name hairpin_queue_size + pci/0000:06:00.0: + name hairpin_queue_size type driver-specific + values: + cmode driverinit value 1024 + +- Change the size (in packets) of the hairpin queues:: + + $ devlink dev param set pci/0000:06:00.0 name hairpin_queue_size value 512 cmode driverinit + Health reporters ================ @@ -222,3 +257,36 @@ User commands examples: $ devlink health dump show pci/0000:82:00.1 reporter fw_fatal NOTE: This command can run only on PF. + +vnic reporter +------------- +The vnic reporter implements only the `diagnose` callback. +It is responsible for querying the vnic diagnostic counters from fw and displaying +them in realtime. + +Description of the vnic counters: +total_q_under_processor_handle: number of queues in an error state due to +an async error or errored command. +send_queue_priority_update_flow: number of QP/SQ priority/SL update +events. +cq_overrun: number of times CQ entered an error state due to an +overflow. +async_eq_overrun: number of times an EQ mapped to async events was +overrun. +comp_eq_overrun: number of times an EQ mapped to completion events was +overrun. +quota_exceeded_command: number of commands issued and failed due to quota +exceeded. +invalid_command: number of commands issued and failed dues to any reason +other than quota exceeded. +nic_receive_steering_discard: number of packets that completed RX flow +steering but were discarded due to a mismatch in flow table. + +User commands examples: +- Diagnose PF/VF vnic counters + $ devlink health diagnose pci/0000:82:00.1 reporter vnic +- Diagnose representor vnic counters (performed by supplying devlink port of the + representor, which can be obtained via devlink port command) + $ devlink health diagnose pci/0000:82:00.1/65537 reporter vnic + +NOTE: This command can run over all interfaces such as PF/VF and representor ports. diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index 10f282c2117c..2f60e34ab926 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -7,6 +7,21 @@ ice devlink support This document describes the devlink features implemented by the ``ice`` device driver. +Parameters +========== + +.. list-table:: Generic parameters implemented + + * - Name + - Mode + - Notes + * - ``enable_roce`` + - runtime + - mutually exclusive with ``enable_iwarp`` + * - ``enable_iwarp`` + - runtime + - mutually exclusive with ``enable_roce`` + Info versions ============= diff --git a/Documentation/networking/devlink/mlx5.rst b/Documentation/networking/devlink/mlx5.rst index 3321117cf605..202798d6501e 100644 --- a/Documentation/networking/devlink/mlx5.rst +++ b/Documentation/networking/devlink/mlx5.rst @@ -72,6 +72,18 @@ parameters. Default: disabled + * - ``hairpin_num_queues`` + - u32 + - driverinit + - We refer to a TC NIC rule that involves forwarding as "hairpin". + Hairpin queues are mlx5 hardware specific implementation for hardware + forwarding of such packets. + + Control the number of hairpin queues. + * - ``hairpin_queue_size`` + - u32 + - driverinit + - Control the size (in packets) of the hairpin queues. The ``mlx5`` driver supports reloading via ``DEVLINK_CMD_RELOAD`` diff --git a/Documentation/networking/driver.rst b/Documentation/networking/driver.rst index 64f7236ff10b..4f5dfa9c022e 100644 --- a/Documentation/networking/driver.rst +++ b/Documentation/networking/driver.rst @@ -4,94 +4,124 @@ Softnet Driver Issues ===================== -Transmit path guidelines: +Probing guidelines +================== -1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under - any normal circumstances. It is considered a hard error unless - there is no way your device can tell ahead of time when its - transmit function will become busy. +Address validation +------------------ - Instead it must maintain the queue properly. For example, - for a driver implementing scatter-gather this means:: +Any hardware layer address you obtain for your device should +be verified. For example, for ethernet check it with +linux/etherdevice.h:is_valid_ether_addr() + +Close/stop guidelines +===================== + +Quiescence +---------- + +After the ndo_stop routine has been called, the hardware must +not receive or transmit any data. All in flight packets must +be aborted. If necessary, poll or wait for completion of +any reset commands. + +Auto-close +---------- + +The ndo_stop routine will be called by unregister_netdevice +if device is still UP. + +Transmit path guidelines +======================== + +Stop queues in advance +---------------------- + +The ndo_start_xmit method must not return NETDEV_TX_BUSY under +any normal circumstances. It is considered a hard error unless +there is no way your device can tell ahead of time when its +transmit function will become busy. + +Instead it must maintain the queue properly. For example, +for a driver implementing scatter-gather this means: + +.. code-block:: c + + static u32 drv_tx_avail(struct drv_ring *dr) + { + u32 used = READ_ONCE(dr->prod) - READ_ONCE(dr->cons); + + return dr->tx_ring_size - (used & bp->tx_ring_mask); + } static netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct drv *dp = netdev_priv(dev); + struct netdev_queue *txq; + struct drv_ring *dr; + int idx; - lock_tx(dp); - ... - /* This is a hard error log it. */ - if (TX_BUFFS_AVAIL(dp) <= (skb_shinfo(skb)->nr_frags + 1)) { + idx = skb_get_queue_mapping(skb); + dr = dp->tx_rings[idx]; + txq = netdev_get_tx_queue(dev, idx); + + //... + /* This should be a very rare race - log it. */ + if (drv_tx_avail(dr) <= skb_shinfo(skb)->nr_frags + 1) { netif_stop_queue(dev); - unlock_tx(dp); - printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n", - dev->name); + netdev_warn(dev, "Tx Ring full when queue awake!\n"); return NETDEV_TX_BUSY; } - ... queue packet to card ... - ... update tx consumer index ... - - if (TX_BUFFS_AVAIL(dp) <= (MAX_SKB_FRAGS + 1)) - netif_stop_queue(dev); - - ... - unlock_tx(dp); - ... - return NETDEV_TX_OK; - } - - And then at the end of your TX reclamation event handling:: + //... queue packet to card ... - if (netif_queue_stopped(dp->dev) && - TX_BUFFS_AVAIL(dp) > (MAX_SKB_FRAGS + 1)) - netif_wake_queue(dp->dev); + netdev_tx_sent_queue(txq, skb->len); - For a non-scatter-gather supporting card, the three tests simply become:: + //... update tx producer index using WRITE_ONCE() ... - /* This is a hard error log it. */ - if (TX_BUFFS_AVAIL(dp) <= 0) + if (!netif_txq_maybe_stop(txq, drv_tx_avail(dr), + MAX_SKB_FRAGS + 1, 2 * MAX_SKB_FRAGS)) + dr->stats.stopped++; - and:: + //... + return NETDEV_TX_OK; + } - if (TX_BUFFS_AVAIL(dp) == 0) +And then at the end of your TX reclamation event handling: - and:: +.. code-block:: c - if (netif_queue_stopped(dp->dev) && - TX_BUFFS_AVAIL(dp) > 0) - netif_wake_queue(dp->dev); + //... update tx consumer index using WRITE_ONCE() ... -2) An ndo_start_xmit method must not modify the shared parts of a - cloned SKB. + netif_txq_completed_wake(txq, cmpl_pkts, cmpl_bytes, + drv_tx_avail(dr), 2 * MAX_SKB_FRAGS); -3) Do not forget that once you return NETDEV_TX_OK from your - ndo_start_xmit method, it is your driver's responsibility to free - up the SKB and in some finite amount of time. +Lockless queue stop / wake helper macros +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - For example, this means that it is not allowed for your TX - mitigation scheme to let TX packets "hang out" in the TX - ring unreclaimed forever if no new TX packets are sent. - This error can deadlock sockets waiting for send buffer room - to be freed up. +.. kernel-doc:: include/net/netdev_queues.h + :doc: Lockless queue stopping / waking helpers. - If you return NETDEV_TX_BUSY from the ndo_start_xmit method, you - must not keep any reference to that SKB and you must not attempt - to free it up. +No exclusive ownership +---------------------- -Probing guidelines: +An ndo_start_xmit method must not modify the shared parts of a +cloned SKB. -1) Any hardware layer address you obtain for your device should - be verified. For example, for ethernet check it with - linux/etherdevice.h:is_valid_ether_addr() +Timely completions +------------------ -Close/stop guidelines: +Do not forget that once you return NETDEV_TX_OK from your +ndo_start_xmit method, it is your driver's responsibility to free +up the SKB and in some finite amount of time. -1) After the ndo_stop routine has been called, the hardware must - not receive or transmit any data. All in flight packets must - be aborted. If necessary, poll or wait for completion of - any reset commands. +For example, this means that it is not allowed for your TX +mitigation scheme to let TX packets "hang out" in the TX +ring unreclaimed forever if no new TX packets are sent. +This error can deadlock sockets waiting for send buffer room +to be freed up. -2) The ndo_stop routine will be called by unregister_netdevice - if device is still UP. +If you return NETDEV_TX_BUSY from the ndo_start_xmit method, you +must not keep any reference to that SKB and you must not attempt +to free it up. diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index e1bc6186d7ea..2540c70952ff 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -860,22 +860,24 @@ Request contents: Kernel response contents: - ==================================== ====== =========================== - ``ETHTOOL_A_RINGS_HEADER`` nested reply header - ``ETHTOOL_A_RINGS_RX_MAX`` u32 max size of RX ring - ``ETHTOOL_A_RINGS_RX_MINI_MAX`` u32 max size of RX mini ring - ``ETHTOOL_A_RINGS_RX_JUMBO_MAX`` u32 max size of RX jumbo ring - ``ETHTOOL_A_RINGS_TX_MAX`` u32 max size of TX ring - ``ETHTOOL_A_RINGS_RX`` u32 size of RX ring - ``ETHTOOL_A_RINGS_RX_MINI`` u32 size of RX mini ring - ``ETHTOOL_A_RINGS_RX_JUMBO`` u32 size of RX jumbo ring - ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring - ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring - ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` u8 TCP header / data split - ``ETHTOOL_A_RINGS_CQE_SIZE`` u32 Size of TX/RX CQE - ``ETHTOOL_A_RINGS_TX_PUSH`` u8 flag of TX Push mode - ``ETHTOOL_A_RINGS_RX_PUSH`` u8 flag of RX Push mode - ==================================== ====== =========================== + ======================================= ====== =========================== + ``ETHTOOL_A_RINGS_HEADER`` nested reply header + ``ETHTOOL_A_RINGS_RX_MAX`` u32 max size of RX ring + ``ETHTOOL_A_RINGS_RX_MINI_MAX`` u32 max size of RX mini ring + ``ETHTOOL_A_RINGS_RX_JUMBO_MAX`` u32 max size of RX jumbo ring + ``ETHTOOL_A_RINGS_TX_MAX`` u32 max size of TX ring + ``ETHTOOL_A_RINGS_RX`` u32 size of RX ring + ``ETHTOOL_A_RINGS_RX_MINI`` u32 size of RX mini ring + ``ETHTOOL_A_RINGS_RX_JUMBO`` u32 size of RX jumbo ring + ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring + ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring + ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` u8 TCP header / data split + ``ETHTOOL_A_RINGS_CQE_SIZE`` u32 Size of TX/RX CQE + ``ETHTOOL_A_RINGS_TX_PUSH`` u8 flag of TX Push mode + ``ETHTOOL_A_RINGS_RX_PUSH`` u8 flag of RX Push mode + ``ETHTOOL_A_RINGS_TX_PUSH_BUF_LEN`` u32 size of TX push buffer + ``ETHTOOL_A_RINGS_TX_PUSH_BUF_LEN_MAX`` u32 max size of TX push buffer + ======================================= ====== =========================== ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` indicates whether the device is usable with page-flipping TCP zero-copy receive (``getsockopt(TCP_ZEROCOPY_RECEIVE)``). @@ -891,6 +893,18 @@ through MMIO writes, thus reducing the latency. However, enabling this feature may increase the CPU cost. Drivers may enforce additional per-packet eligibility checks (e.g. on packet size). +``ETHTOOL_A_RINGS_TX_PUSH_BUF_LEN`` specifies the maximum number of bytes of a +transmitted packet a driver can push directly to the underlying device +('push' mode). Pushing some of the payload bytes to the device has the +advantages of reducing latency for small packets by avoiding DMA mapping (same +as ``ETHTOOL_A_RINGS_TX_PUSH`` parameter) as well as allowing the underlying +device to process packet headers ahead of fetching its payload. +This can help the device to make fast actions based on the packet's headers. +This is similar to the "tx-copybreak" parameter, which copies the packet to a +preallocated DMA memory area instead of mapping new memory. However, +tx-push-buff parameter copies the packet directly to the device to allow the +device to take faster actions on the packet. + RINGS_SET ========= @@ -908,6 +922,7 @@ Request contents: ``ETHTOOL_A_RINGS_CQE_SIZE`` u32 Size of TX/RX CQE ``ETHTOOL_A_RINGS_TX_PUSH`` u8 flag of TX Push mode ``ETHTOOL_A_RINGS_RX_PUSH`` u8 flag of RX Push mode + ``ETHTOOL_A_RINGS_TX_PUSH_BUF_LEN`` u32 size of TX push buffer ==================================== ====== =========================== Kernel checks that requested ring sizes do not exceed limits reported by @@ -1084,6 +1099,10 @@ such that the corresponding bit in ``ethtool_ops::supported_coalesce_params`` is not set), regardless of their values. Driver may impose additional constraints on coalescing parameters and their values. +Compared to requests issued via the ``ioctl()`` netlink version of this request +will try harder to make sure that values specified by the user have been applied +and may call the driver twice. + PAUSE_GET ========= diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 4ddcae33c336..a164ff074356 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -36,6 +36,7 @@ Contents: scaling tls tls-offload + tls-handshake nfc 6lowpan 6pack @@ -73,6 +74,7 @@ Contents: mpls-sysctl mptcp-sysctl multiqueue + napi netconsole netdev-features netdevices diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 87dd1c5283e6..6ec06a33688a 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -340,6 +340,8 @@ tcp_app_win - INTEGER Reserve max(window/2^tcp_app_win, mss) of window for application buffer. Value 0 is special, it means that nothing is reserved. + Possible values are [0, 31], inclusive. + Default: 31 tcp_autocorking - BOOLEAN @@ -2719,6 +2721,13 @@ echo_ignore_anycast - BOOLEAN Default: 0 +error_anycast_as_unicast - BOOLEAN + If set to 1, then the kernel will respond with ICMP Errors + resulting from requests sent to it over the IPv6 protocol destined + to anycast address essentially treating anycast as unicast. + + Default: 0 + xfrm6_gc_thresh - INTEGER (Obsolete since linux-4.14) The threshold at which we will start garbage collecting for IPv6 diff --git a/Documentation/networking/napi.rst b/Documentation/networking/napi.rst new file mode 100644 index 000000000000..a7a047742e93 --- /dev/null +++ b/Documentation/networking/napi.rst @@ -0,0 +1,254 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +.. _napi: + +==== +NAPI +==== + +NAPI is the event handling mechanism used by the Linux networking stack. +The name NAPI no longer stands for anything in particular [#]_. + +In basic operation the device notifies the host about new events +via an interrupt. +The host then schedules a NAPI instance to process the events. +The device may also be polled for events via NAPI without receiving +interrupts first (:ref:`busy polling<poll>`). + +NAPI processing usually happens in the software interrupt context, +but there is an option to use :ref:`separate kernel threads<threaded>` +for NAPI processing. + +All in all NAPI abstracts away from the drivers the context and configuration +of event (packet Rx and Tx) processing. + +Driver API +========== + +The two most important elements of NAPI are the struct napi_struct +and the associated poll method. struct napi_struct holds the state +of the NAPI instance while the method is the driver-specific event +handler. The method will typically free Tx packets that have been +transmitted and process newly received packets. + +.. _drv_ctrl: + +Control API +----------- + +netif_napi_add() and netif_napi_del() add/remove a NAPI instance +from the system. The instances are attached to the netdevice passed +as argument (and will be deleted automatically when netdevice is +unregistered). Instances are added in a disabled state. + +napi_enable() and napi_disable() manage the disabled state. +A disabled NAPI can't be scheduled and its poll method is guaranteed +to not be invoked. napi_disable() waits for ownership of the NAPI +instance to be released. + +The control APIs are not idempotent. Control API calls are safe against +concurrent use of datapath APIs but an incorrect sequence of control API +calls may result in crashes, deadlocks, or race conditions. For example, +calling napi_disable() multiple times in a row will deadlock. + +Datapath API +------------ + +napi_schedule() is the basic method of scheduling a NAPI poll. +Drivers should call this function in their interrupt handler +(see :ref:`drv_sched` for more info). A successful call to napi_schedule() +will take ownership of the NAPI instance. + +Later, after NAPI is scheduled, the driver's poll method will be +called to process the events/packets. The method takes a ``budget`` +argument - drivers can process completions for any number of Tx +packets but should only process up to ``budget`` number of +Rx packets. Rx processing is usually much more expensive. + +In other words, it is recommended to ignore the budget argument when +performing TX buffer reclamation to ensure that the reclamation is not +arbitrarily bounded; however, it is required to honor the budget argument +for RX processing. + +.. warning:: + + The ``budget`` argument may be 0 if core tries to only process Tx completions + and no Rx packets. + +The poll method returns the amount of work done. If the driver still +has outstanding work to do (e.g. ``budget`` was exhausted) +the poll method should return exactly ``budget``. In that case, +the NAPI instance will be serviced/polled again (without the +need to be scheduled). + +If event processing has been completed (all outstanding packets +processed) the poll method should call napi_complete_done() +before returning. napi_complete_done() releases the ownership +of the instance. + +.. warning:: + + The case of finishing all events and using exactly ``budget`` + must be handled carefully. There is no way to report this + (rare) condition to the stack, so the driver must either + not call napi_complete_done() and wait to be called again, + or return ``budget - 1``. + + If the ``budget`` is 0 napi_complete_done() should never be called. + +Call sequence +------------- + +Drivers should not make assumptions about the exact sequencing +of calls. The poll method may be called without the driver scheduling +the instance (unless the instance is disabled). Similarly, +it's not guaranteed that the poll method will be called, even +if napi_schedule() succeeded (e.g. if the instance gets disabled). + +As mentioned in the :ref:`drv_ctrl` section - napi_disable() and subsequent +calls to the poll method only wait for the ownership of the instance +to be released, not for the poll method to exit. This means that +drivers should avoid accessing any data structures after calling +napi_complete_done(). + +.. _drv_sched: + +Scheduling and IRQ masking +-------------------------- + +Drivers should keep the interrupts masked after scheduling +the NAPI instance - until NAPI polling finishes any further +interrupts are unnecessary. + +Drivers which have to mask the interrupts explicitly (as opposed +to IRQ being auto-masked by the device) should use the napi_schedule_prep() +and __napi_schedule() calls: + +.. code-block:: c + + if (napi_schedule_prep(&v->napi)) { + mydrv_mask_rxtx_irq(v->idx); + /* schedule after masking to avoid races */ + __napi_schedule(&v->napi); + } + +IRQ should only be unmasked after a successful call to napi_complete_done(): + +.. code-block:: c + + if (budget && napi_complete_done(&v->napi, work_done)) { + mydrv_unmask_rxtx_irq(v->idx); + return min(work_done, budget - 1); + } + +napi_schedule_irqoff() is a variant of napi_schedule() which takes advantage +of guarantees given by being invoked in IRQ context (no need to +mask interrupts). Note that PREEMPT_RT forces all interrupts +to be threaded so the interrupt may need to be marked ``IRQF_NO_THREAD`` +to avoid issues on real-time kernel configurations. + +Instance to queue mapping +------------------------- + +Modern devices have multiple NAPI instances (struct napi_struct) per +interface. There is no strong requirement on how the instances are +mapped to queues and interrupts. NAPI is primarily a polling/processing +abstraction without specific user-facing semantics. That said, most networking +devices end up using NAPI in fairly similar ways. + +NAPI instances most often correspond 1:1:1 to interrupts and queue pairs +(queue pair is a set of a single Rx and single Tx queue). + +In less common cases a NAPI instance may be used for multiple queues +or Rx and Tx queues can be serviced by separate NAPI instances on a single +core. Regardless of the queue assignment, however, there is usually still +a 1:1 mapping between NAPI instances and interrupts. + +It's worth noting that the ethtool API uses a "channel" terminology where +each channel can be either ``rx``, ``tx`` or ``combined``. It's not clear +what constitutes a channel; the recommended interpretation is to understand +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. + +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. + +Software IRQ coalescing +----------------------- + +NAPI does not perform any explicit event coalescing by default. +In most scenarios batching happens due to IRQ coalescing which is done +by the device. There are cases where software coalescing is helpful. + +NAPI can be configured to arm a repoll timer instead of unmasking +the hardware interrupts as soon as all packets are processed. +The ``gro_flush_timeout`` sysfs configuration of the netdevice +is reused to control the delay of the timer, while +``napi_defer_hard_irqs`` controls the number of consecutive empty polls +before NAPI gives up and goes back to using hardware IRQs. + +.. _poll: + +Busy polling +------------ + +Busy polling allows a user process to check for incoming packets before +the device interrupt fires. As is the case with any busy polling it trades +off CPU cycles for lower latency (production uses of NAPI busy polling +are not well known). + +Busy polling is enabled by either setting ``SO_BUSY_POLL`` on +selected sockets or using the global ``net.core.busy_poll`` and +``net.core.busy_read`` sysctls. An io_uring API for NAPI busy polling +also exists. + +IRQ mitigation +--------------- + +While busy polling is supposed to be used by low latency applications, +a similar mechanism can be used for IRQ mitigation. + +Very high request-per-second applications (especially routing/forwarding +applications and especially applications using AF_XDP sockets) may not +want to be interrupted until they finish processing a request or a batch +of packets. + +Such applications can pledge to the kernel that they will perform a busy +polling operation periodically, and the driver should keep the device IRQs +permanently masked. This mode is enabled by using the ``SO_PREFER_BUSY_POLL`` +socket option. To avoid system misbehavior the pledge is revoked +if ``gro_flush_timeout`` passes without any busy poll call. + +The NAPI budget for busy polling is lower than the default (which makes +sense given the low latency intention of normal busy polling). This is +not the case with IRQ mitigation, however, so the budget can be adjusted +with the ``SO_BUSY_POLL_BUDGET`` socket option. + +.. _threaded: + +Threaded NAPI +------------- + +Threaded NAPI is an operating mode that uses dedicated kernel +threads rather than software IRQ context for NAPI processing. +The configuration is per netdevice and will affect all +NAPI instances of that device. Each NAPI instance will spawn a separate +thread (called ``napi/${ifc-name}-${napi-id}``). + +It is recommended to pin each kernel thread to a single CPU, the same +CPU as the CPU which services the interrupt. Note that the mapping +between IRQs and NAPI instances may not be trivial (and is driver +dependent). The NAPI instance IDs will be assigned in the opposite +order than the process IDs of the kernel threads. + +Threaded NAPI is controlled by writing 0/1 to the ``threaded`` file in +netdev's sysfs directory. + +.. rubric:: Footnotes + +.. [#] NAPI was originally referred to as New API in 2.4 Linux. diff --git a/Documentation/networking/page_pool.rst b/Documentation/networking/page_pool.rst index 30f1344e7cca..873efd97f822 100644 --- a/Documentation/networking/page_pool.rst +++ b/Documentation/networking/page_pool.rst @@ -165,6 +165,7 @@ Registration pp_params.pool_size = DESC_NUM; pp_params.nid = NUMA_NO_NODE; pp_params.dev = priv->dev; + pp_params.napi = napi; /* only if locking is tied to NAPI */ pp_params.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE; page_pool = page_pool_create(&pp_params); diff --git a/Documentation/networking/rxrpc.rst b/Documentation/networking/rxrpc.rst index ec1323d92c96..e807e18ba32a 100644 --- a/Documentation/networking/rxrpc.rst +++ b/Documentation/networking/rxrpc.rst @@ -848,14 +848,21 @@ The kernel interface functions are as follows: returned. The caller now holds a reference on this and it must be properly ended. - (#) End a client call:: + (#) Shut down a client call:: - void rxrpc_kernel_end_call(struct socket *sock, + void rxrpc_kernel_shutdown_call(struct socket *sock, + struct rxrpc_call *call); + + This is used to shut down a previously begun call. The user_call_ID is + expunged from AF_RXRPC's knowledge and will not be seen again in + association with the specified call. + + (#) Release the ref on a client call:: + + void rxrpc_kernel_put_call(struct socket *sock, struct rxrpc_call *call); - This is used to end a previously begun call. The user_call_ID is expunged - from AF_RXRPC's knowledge and will not be seen again in association with - the specified call. + This is used to release the caller's ref on an rxrpc call. (#) Send data through a call:: diff --git a/Documentation/networking/tls-handshake.rst b/Documentation/networking/tls-handshake.rst new file mode 100644 index 000000000000..a2817a88e905 --- /dev/null +++ b/Documentation/networking/tls-handshake.rst @@ -0,0 +1,217 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================= +In-Kernel TLS Handshake +======================= + +Overview +======== + +Transport Layer Security (TLS) is a Upper Layer Protocol (ULP) that runs +over TCP. TLS provides end-to-end data integrity and confidentiality in +addition to peer authentication. + +The kernel's kTLS implementation handles the TLS record subprotocol, but +does not handle the TLS handshake subprotocol which is used to establish +a TLS session. Kernel consumers can use the API described here to +request TLS session establishment. + +There are several possible ways to provide a handshake service in the +kernel. The API described here is designed to hide the details of those +implementations so that in-kernel TLS consumers do not need to be +aware of how the handshake gets done. + + +User handshake agent +==================== + +As of this writing, there is no TLS handshake implementation in the +Linux kernel. To provide a handshake service, a handshake agent +(typically in user space) is started in each network namespace where a +kernel consumer might require a TLS handshake. Handshake agents listen +for events sent from the kernel that indicate a handshake request is +waiting. + +An open socket is passed to a handshake agent via a netlink operation, +which creates a socket descriptor in the agent's file descriptor table. +If the handshake completes successfully, the handshake agent promotes +the socket to use the TLS ULP and sets the session information using the +SOL_TLS socket options. The handshake agent returns the socket to the +kernel via a second netlink operation. + + +Kernel Handshake API +==================== + +A kernel TLS consumer initiates a client-side TLS handshake on an open +socket by invoking one of the tls_client_hello() functions. First, it +fills in a structure that contains the parameters of the request: + +.. code-block:: c + + struct tls_handshake_args { + struct socket *ta_sock; + tls_done_func_t ta_done; + void *ta_data; + unsigned int ta_timeout_ms; + key_serial_t ta_keyring; + key_serial_t ta_my_cert; + key_serial_t ta_my_privkey; + unsigned int ta_num_peerids; + key_serial_t ta_my_peerids[5]; + }; + +The @ta_sock field references an open and connected socket. The consumer +must hold a reference on the socket to prevent it from being destroyed +while the handshake is in progress. The consumer must also have +instantiated a struct file in sock->file. + + +@ta_done contains a callback function that is invoked when the handshake +has completed. Further explanation of this function is in the "Handshake +Completion" sesction below. + +The consumer can fill in the @ta_timeout_ms field to force the servicing +handshake agent to exit after a number of milliseconds. This enables the +socket to be fully closed once both the kernel and the handshake agent +have closed their endpoints. + +Authentication material such as x.509 certificates, private certificate +keys, and pre-shared keys are provided to the handshake agent in keys +that are instantiated by the consumer before making the handshake +request. The consumer can provide a private keyring that is linked into +the handshake agent's process keyring in the @ta_keyring field to prevent +access of those keys by other subsystems. + +To request an x.509-authenticated TLS session, the consumer fills in +the @ta_my_cert and @ta_my_privkey fields with the serial numbers of +keys containing an x.509 certificate and the private key for that +certificate. Then, it invokes this function: + +.. code-block:: c + + ret = tls_client_hello_x509(args, gfp_flags); + +The function returns zero when the handshake request is under way. A +zero return guarantees the callback function @ta_done will be invoked +for this socket. The function returns a negative errno if the handshake +could not be started. A negative errno guarantees the callback function +@ta_done will not be invoked on this socket. + + +To initiate a client-side TLS handshake with a pre-shared key, use: + +.. code-block:: c + + ret = tls_client_hello_psk(args, gfp_flags); + +However, in this case, the consumer fills in the @ta_my_peerids array +with serial numbers of keys containing the peer identities it wishes +to offer, and the @ta_num_peerids field with the number of array +entries it has filled in. The other fields are filled in as above. + + +To initiate an anonymous client-side TLS handshake use: + +.. code-block:: c + + ret = tls_client_hello_anon(args, gfp_flags); + +The handshake agent presents no peer identity information to the remote +during this type of handshake. Only server authentication (ie the client +verifies the server's identity) is performed during the handshake. Thus +the established session uses encryption only. + + +Consumers that are in-kernel servers use: + +.. code-block:: c + + ret = tls_server_hello_x509(args, gfp_flags); + +or + +.. code-block:: c + + ret = tls_server_hello_psk(args, gfp_flags); + +The argument structure is filled in as above. + + +If the consumer needs to cancel the handshake request, say, due to a ^C +or other exigent event, the consumer can invoke: + +.. code-block:: c + + bool tls_handshake_cancel(sock); + +This function returns true if the handshake request associated with +@sock has been canceled. The consumer's handshake completion callback +will not be invoked. If this function returns false, then the consumer's +completion callback has already been invoked. + + +Handshake Completion +==================== + +When the handshake agent has completed processing, it notifies the +kernel that the socket may be used by the consumer again. At this point, +the consumer's handshake completion callback, provided in the @ta_done +field in the tls_handshake_args structure, is invoked. + +The synopsis of this function is: + +.. code-block:: c + + typedef void (*tls_done_func_t)(void *data, int status, + key_serial_t peerid); + +The consumer provides a cookie in the @ta_data field of the +tls_handshake_args structure that is returned in the @data parameter of +this callback. The consumer uses the cookie to match the callback to the +thread waiting for the handshake to complete. + +The success status of the handshake is returned via the @status +parameter: + ++------------+----------------------------------------------+ +| status | meaning | ++============+==============================================+ +| 0 | TLS session established successfully | ++------------+----------------------------------------------+ +| -EACCESS | Remote peer rejected the handshake or | +| | authentication failed | ++------------+----------------------------------------------+ +| -ENOMEM | Temporary resource allocation failure | ++------------+----------------------------------------------+ +| -EINVAL | Consumer provided an invalid argument | ++------------+----------------------------------------------+ +| -ENOKEY | Missing authentication material | ++------------+----------------------------------------------+ +| -EIO | An unexpected fault occurred | ++------------+----------------------------------------------+ + +The @peerid parameter contains the serial number of a key containing the +remote peer's identity or the value TLS_NO_PEERID if the session is not +authenticated. + +A best practice is to close and destroy the socket immediately if the +handshake failed. + + +Other considerations +-------------------- + +While a handshake is under way, the kernel consumer must alter the +socket's sk_data_ready callback function to ignore all incoming data. +Once the handshake completion callback function has been invoked, normal +receive operation can be resumed. + +Once a TLS session is established, the consumer must provide a buffer +for and then examine the control message (CMSG) that is part of every +subsequent sock_recvmsg(). Each control message indicates whether the +received message data is TLS record data or session metadata. + +See tls.rst for details on how a kTLS consumer recognizes incoming +(decrypted) application data, alerts, and handshake packets once the +socket has been promoted to use the TLS ULP. diff --git a/Documentation/networking/xdp-rx-metadata.rst b/Documentation/networking/xdp-rx-metadata.rst index aac63fc2d08b..25ce72af81c2 100644 --- a/Documentation/networking/xdp-rx-metadata.rst +++ b/Documentation/networking/xdp-rx-metadata.rst @@ -23,10 +23,13 @@ metadata is supported, this set will grow: An XDP program can use these kfuncs to read the metadata into stack variables for its own consumption. Or, to pass the metadata on to other consumers, an XDP program can store it into the metadata area carried -ahead of the packet. +ahead of the packet. Not all packets will necessary have the requested +metadata available in which case the driver returns ``-ENODATA``. Not all kfuncs have to be implemented by the device driver; when not -implemented, the default ones that return ``-EOPNOTSUPP`` will be used. +implemented, the default ones that return ``-EOPNOTSUPP`` will be used +to indicate the device driver have not implemented this kfunc. + Within an XDP frame, the metadata layout (accessed via ``xdp_buff``) is as follows:: diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst index 7a670a075ab6..de4edd42d5c0 100644 --- a/Documentation/process/5.Posting.rst +++ b/Documentation/process/5.Posting.rst @@ -207,8 +207,8 @@ the patch:: Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID") Another tag is used for linking web pages with additional backgrounds or -details, for example a report about a bug fixed by the patch or a document -with a specification implemented by the patch:: +details, for example an earlier discussion which leads to the patch or a +document with a specification implemented by the patch:: Link: https://example.com/somewhere.html optional-other-stuff @@ -217,7 +217,17 @@ latest public review posting of the patch; often this is automatically done by tools like b4 or a git hook like the one described in 'Documentation/maintainer/configure-git.rst'. -A third kind of tag is used to document who was involved in the development of +If the URL points to a public bug report being fixed by the patch, use the +"Closes:" tag instead:: + + Closes: https://example.com/issues/1234 optional-other-stuff + +Some bug trackers have the ability to close issues automatically when a +commit with such a tag is applied. Some bots monitoring mailing lists can +also track such tags and take certain actions. Private bug trackers and +invalid URLs are forbidden. + +Another kind of tag is used to document who was involved in the development of the patch. Each of these uses this format:: tag: Full Name <email address> optional-other-stuff @@ -251,8 +261,10 @@ The tags in common use are: - Reported-by: names a user who reported a problem which is fixed by this patch; this tag is used to give credit to the (often underappreciated) people who test our code and let us know when things do not work - correctly. Note, this tag should be followed by a Link: tag pointing to the - report, unless the report is not available on the web. + correctly. Note, this 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. - Cc: the named person received a copy of the patch and had the opportunity to comment on it. diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index 007e49ef6cec..6db37a46d305 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -1267,5 +1267,5 @@ gcc internals and indent, all available from https://www.gnu.org/manual/ WG14 is the international standardization working group for the programming language C, URL: http://www.open-std.org/JTC1/SC22/WG14/ -Kernel :ref:`process/coding-style.rst <codingstyle>`, by greg@kroah.com at OLS 2002: +Kernel CodingStyle, by greg@kroah.com at OLS 2002: http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ diff --git a/Documentation/process/contribution-maturity-model.rst b/Documentation/process/contribution-maturity-model.rst new file mode 100644 index 000000000000..b87ab34de22c --- /dev/null +++ b/Documentation/process/contribution-maturity-model.rst @@ -0,0 +1,109 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================== +Linux Kernel Contribution Maturity Model +======================================== + + +Background +========== + +As a part of the 2021 Linux Kernel Maintainers’ Summit, there was a +`discussion <https://lwn.net/Articles/870581/>`_ about the challenges in +recruiting kernel maintainers as well as maintainer succession. Some of +the conclusions from that discussion included that companies which are a +part of the Linux Kernel community need to allow engineers to be +maintainers as part of their job, so they can grow into becoming +respected leaders and eventually, kernel maintainers. To support a +strong talent pipeline, developers should be allowed and encouraged to +take on upstream contributions such as reviewing other people’s patches, +refactoring kernel infrastructure, and writing documentation. + +To that end, the Linux Foundation Technical Advisory Board (TAB) +proposes this Linux Kernel Contribution Maturity Model. These common +expectations for upstream community engagement aim to increase the +influence of individual developers, increase the collaboration of +organizations, and improve the overall health of the Linux Kernel +ecosystem. + +The TAB urges organizations to continuously evaluate their Open Source +maturity model and commit to improvements to align with this model. To +be effective, this evaluation should incorporate feedback from across +the organization, including management and developers at all seniority +levels. In the spirit of Open Source, we encourage organizations to +publish their evaluations and plans to improve their engagement with the +upstream community. + +Level 0 +======= + +* Software Engineers are not allowed to contribute patches to the Linux + kernel. + + +Level 1 +======= + +* Software Engineers are allowed to contribute patches to the Linux + kernel, either as part of their job responsibilities or on their own + time. + +Level 2 +======= + +* Software Engineers are expected to contribute to the Linux Kernel as + part of their job responsibilities. +* Software Engineers will be supported to attend Linux-related + conferences as a part of their job. +* A Software Engineer’s upstream code contributions will be considered + in promotion and performance reviews. + +Level 3 +======= + +* Software Engineers are expected to review patches (including patches + authored by engineers from other companies) as part of their job + responsibilities +* Contributing presentations or papers to Linux-related or academic + conferences (such those organized by the Linux Foundation, Usenix, + ACM, etc.), are considered part of an engineer’s work. +* A Software Engineer’s community contributions will be considered in + promotion and performance reviews. +* Organizations will regularly report metrics of their open source + contributions and track these metrics over time. These metrics may be + published only internally within the organization, or at the + organization’s discretion, some or all may be published externally. + Metrics that are strongly suggested include: + + * The number of upstream kernel contributions by team or organization + (e.g., all people reporting up to a manager, director, or VP). + * The percentage of kernel developers who have made upstream + contributions relative to the total kernel developers in the + organization. + * The time interval between kernels used in the organization’s servers + and/or products, and the publication date of the upstream kernel + upon which the internal kernel is based. + * The number of out-of-tree commits present in internal kernels. + +Level 4 +======= + +* Software Engineers are encouraged to spend a portion of their work + time focused on Upstream Work, which is defined as reviewing patches, + serving on program committees, improving core project infrastructure + such as writing or maintaining tests, upstream tech debt reduction, + writing documentation, etc. +* Software Engineers are supported in helping to organize Linux-related + conferences. +* Organizations will consider community member feedback in official + performance reviews. + +Level 5 +======= + +* Upstream kernel development is considered a formal job position, with + at least a third of the engineer’s time spent doing Upstream Work. +* Organizations will actively seek out community member feedback as a + factor in official performance reviews. +* Organizations will regularly report internally on the ratio of + Upstream Work to work focused on directly pursuing business goals. diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index cb6abcb2b6d0..deb8235e20ff 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -138,7 +138,7 @@ required reading: philosophy and is very important for people moving to Linux from development on other Operating Systems. - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` If you feel you have found a security problem in the Linux kernel, please follow the steps in this document to help notify the kernel developers, and help solve the issue. diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index d4b6217472b0..b501cd977053 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -35,6 +35,14 @@ Below are the essential guides that every developer should read. kernel-enforcement-statement kernel-driver-statement +For security issues, see: + +.. toctree:: + :maxdepth: 1 + + security-bugs + embargoed-hardware-issues + Other guides to the community that are of interest to most developers are: .. toctree:: @@ -47,9 +55,9 @@ Other guides to the community that are of interest to most developers are: submit-checklist kernel-docs deprecated - embargoed-hardware-issues maintainers researcher-guidelines + contribution-maturity-model These are some overall technical guides that have been put here for now for lack of a better place. diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst index 1c6e2ab92f4e..46f927aae6eb 100644 --- a/Documentation/process/kernel-docs.rst +++ b/Documentation/process/kernel-docs.rst @@ -75,13 +75,39 @@ On-line docs Published books --------------- + * Title: **Linux Kernel Debugging: Leverage proven tools and advanced techniques to effectively debug Linux kernels and kernel modules** + + :Author: Kaiwan N Billimoria + :Publisher: Packt Publishing Ltd + :Date: August, 2022 + :Pages: 638 + :ISBN: 978-1801075039 + :Notes: Debugging book + * Title: **Linux Kernel Programming: A Comprehensive Guide to Kernel Internals, Writing Kernel Modules, and Kernel Synchronization** - :Author: Kaiwan N. Billimoria - :Publisher: Packt Publishing Ltd - :Date: 2021 - :Pages: 754 - :ISBN: 978-1789953435 + :Author: Kaiwan N Billimoria + :Publisher: Packt Publishing Ltd + :Date: March, 2021 + :Pages: 754 + :ISBN: 978-1789953435 + + * Title: **Linux Kernel Programming Part 2 - Char Device Drivers and Kernel Synchronization: Create user-kernel interfaces, work with peripheral I/O, and handle hardware interrupts** + + :Author: Kaiwan N Billimoria + :Publisher: Packt Publishing Ltd + :Date: March, 2021 + :Pages: 452 + :ISBN: 978-1801079518 + + * Title: **Linux System Programming: Talking Directly to the Kernel and C Library** + + :Author: Robert Love + :Publisher: O'Reilly Media + :Date: June, 2013 + :Pages: 456 + :ISBN: 978-1449339531 + :Notes: Foundational book * Title: **Linux Kernel Development, 3rd Edition** diff --git a/Documentation/process/magic-number.rst b/Documentation/process/magic-number.rst index 64b5948fc1d4..7029c3c084ee 100644 --- a/Documentation/process/magic-number.rst +++ b/Documentation/process/magic-number.rst @@ -72,7 +72,6 @@ PG_MAGIC 'P' pg_{read,write}_hdr ``include/linux/ APM_BIOS_MAGIC 0x4101 apm_user ``arch/x86/kernel/apm_32.c`` FASYNC_MAGIC 0x4601 fasync_struct ``include/linux/fs.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` -MGSLPC_MAGIC 0x5402 mgslpc_info ``drivers/char/pcmcia/synclink_cs.c`` BAYCOM_MAGIC 0x19730510 baycom_state ``drivers/net/baycom_epp.c`` HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state ``include/linux/hdlcdrv.h`` KV_MAGIC 0x5f4b565f kernel_vars_s ``arch/mips/include/asm/sn/klkernvars.h`` diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index 4a75686d35ab..f73ac9e175a8 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -109,6 +109,8 @@ Finally, the vX.Y gets released, and the whole cycle starts over. netdev patch review ------------------- +.. _patch_status: + Patch status ~~~~~~~~~~~~ @@ -143,6 +145,33 @@ Asking the maintainer for status updates on your patch is a good way to ensure your patch is ignored or pushed to the bottom of the priority list. +Changes requested +~~~~~~~~~~~~~~~~~ + +Patches :ref:`marked<patch_status>` as ``Changes Requested`` need +to be revised. The new version should come with a change log, +preferably including links to previous postings, for example:: + + [PATCH net-next v3] net: make cows go moo + + Even users who don't drink milk appreciate hearing the cows go "moo". + + The amount of mooing will depend on packet rate so should match + the diurnal cycle quite well. + + Signed-of-by: Joe Defarmer <joe@barn.org> + --- + v3: + - add a note about time-of-day mooing fluctuation to the commit message + v2: https://lore.kernel.org/netdev/123themessageid@barn.org/ + - fix missing argument in kernel doc for netif_is_bovine() + - fix memory leak in netdev_register_cow() + v1: https://lore.kernel.org/netdev/456getstheclicks@barn.org/ + +The commit message should be revised to answer any questions reviewers +had to ask in previous discussions. Occasionally the update of +the commit message will be the only change in the new version. + Partial resends ~~~~~~~~~~~~~~~ @@ -155,11 +184,18 @@ Handling misapplied patches Occasionally a patch series gets applied before receiving critical feedback, or the wrong version of a series gets applied. -There is no revert possible, once it is pushed out, it stays like that. + +Making the patch disappear once it is pushed out is not possible, the commit +history in netdev trees is immutable. Please send incremental versions on top of what has been merged in order to fix the patches the way they would look like if your latest patch series was to be merged. +In cases where full revert is needed the revert has to be submitted +as a patch to the list with a commit message explaining the technical +problems with the reverted commit. Reverts should be used as a last resort, +when original change is completely wrong; incremental fixes are preferred. + Stable tree ~~~~~~~~~~~ diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst index 572a3289c9cb..178c95fd17dc 100644 --- a/Documentation/process/maintainer-tip.rst +++ b/Documentation/process/maintainer-tip.rst @@ -128,8 +128,8 @@ uppercase letter and should be written in imperative tone. Changelog ^^^^^^^^^ -The general rules about changelogs in the process documentation, see -:ref:`Documentation/process/ <submittingpatches>`, apply. +The general rules about changelogs in the :ref:`Submitting patches guide +<describe_changes>`, apply. The tip tree maintainers set value on following these rules, especially on the request to write changelogs in imperative mood and not impersonating diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst index 5fc9160ca1fa..bc56dee6d0bc 100644 --- a/Documentation/process/programming-language.rst +++ b/Documentation/process/programming-language.rst @@ -12,10 +12,6 @@ under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11. This dialect contains many extensions to the language [gnu-extensions]_, and many of them are used within the kernel as a matter of course. -There is some support for compiling the kernel with ``icc`` [icc]_ for several -of the architectures, although at the time of writing it is not completed, -requiring third-party patches. - Attributes ---------- @@ -35,12 +31,28 @@ in order to feature detect which ones can be used and/or to shorten the code. Please refer to ``include/linux/compiler_attributes.h`` for more information. +Rust +---- + +The kernel has experimental support for the Rust programming language +[rust-language]_ under ``CONFIG_RUST``. It is compiled with ``rustc`` [rustc]_ +under ``--edition=2021`` [rust-editions]_. Editions are a way to introduce +small changes to the language that are not backwards compatible. + +On top of that, some unstable features [rust-unstable-features]_ are used in +the kernel. Unstable features may change in the future, thus it is an important +goal to reach a point where only stable features are used. + +Please refer to Documentation/rust/index.rst for more information. + .. [c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards .. [gcc] https://gcc.gnu.org .. [clang] https://clang.llvm.org -.. [icc] https://software.intel.com/en-us/c-compilers .. [gcc-c-dialect-options] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html .. [gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html .. [gcc-attribute-syntax] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html .. [n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf - +.. [rust-language] https://www.rust-lang.org +.. [rustc] https://doc.rust-lang.org/rustc/ +.. [rust-editions] https://doc.rust-lang.org/edition-guide/editions/ +.. [rust-unstable-features] https://github.com/Rust-for-Linux/linux/issues/2 diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst index afc944e0e898..9fcfed3c350b 100644 --- a/Documentation/process/researcher-guidelines.rst +++ b/Documentation/process/researcher-guidelines.rst @@ -68,7 +68,7 @@ Before contributing, carefully read the appropriate documentation: * Documentation/process/development-process.rst * Documentation/process/submitting-patches.rst * Documentation/admin-guide/reporting-issues.rst -* Documentation/admin-guide/security-bugs.rst +* Documentation/process/security-bugs.rst Then send a patch (including a commit log with all the details listed below) and follow up on any feedback from other developers. diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/process/security-bugs.rst index 82e29837d589..82e29837d589 100644 --- a/Documentation/admin-guide/security-bugs.rst +++ b/Documentation/process/security-bugs.rst diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 2fd8aa593a28..51df1197d5ab 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree Security patches should not be handled (solely) by the -stable review process but should follow the procedures in - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`. + :ref:`Documentation/process/security-bugs.rst <securitybugs>`. For all other submissions, choose one of the following procedures ----------------------------------------------------------------- diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index eac7167dce83..486875fd73c0 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -113,11 +113,9 @@ there is no collision with your six-character ID now, that condition may change five years from now. If related discussions or any other background information behind the change -can be found on the web, add 'Link:' tags pointing to it. In case your patch -fixes a bug, for example, add a tag with a URL referencing the report in the -mailing list archives or a bug tracker; if the patch is a result of some -earlier mailing list discussion or something documented on the web, point to -it. +can be found on the web, add 'Link:' tags pointing to it. If the patch is a +result of some earlier mailing list discussions or something documented on the +web, point to it. When linking to mailing list archives, preferably use the lore.kernel.org message archiver service. To create the link URL, use the contents of the @@ -134,6 +132,16 @@ resources. In addition to giving a URL to a mailing list archive or bug, summarize the relevant points of the discussion that led to the patch as submitted. +In case your patch fixes a bug, use the 'Closes:' tag with a URL referencing +the report in the mailing list archives or a public bug tracker. For example:: + + Closes: https://example.com/issues/1234 + +Some bug trackers have the ability to close issues automatically when a +commit with such a tag is applied. Some bots monitoring mailing lists can +also track such tags and take certain actions. Private bug trackers and +invalid URLs are forbidden. + If your patch fixes a bug in a specific commit, e.g. you found an issue using ``git bisect``, please use the 'Fixes:' tag with the first 12 characters of the SHA-1 ID, and the one line summary. Do not split the tag across multiple @@ -223,20 +231,17 @@ patch. Select the recipients for your patch ------------------------------------ -You should always copy the appropriate subsystem maintainer(s) on any patch -to code that they maintain; look through the MAINTAINERS file and the -source code revision history to see who those maintainers are. The -script scripts/get_maintainer.pl can be very useful at this step (pass paths to -your patches as arguments to scripts/get_maintainer.pl). If you cannot find a +You should always copy the appropriate subsystem maintainer(s) and list(s) on +any patch to code that they maintain; look through the MAINTAINERS file and the +source code revision history to see who those maintainers are. The script +scripts/get_maintainer.pl can be very useful at this step (pass paths to your +patches as arguments to scripts/get_maintainer.pl). If you cannot find a maintainer for the subsystem you are working on, Andrew Morton (akpm@linux-foundation.org) serves as a maintainer of last resort. -You should also normally choose at least one mailing list to receive a copy -of your patch set. linux-kernel@vger.kernel.org should be used by default -for all patches, but the volume on that list has caused a number of -developers to tune it out. Look in the MAINTAINERS file for a -subsystem-specific list; your patch will probably get more attention there. -Please do not spam unrelated lists, though. +linux-kernel@vger.kernel.org should be used by default for all patches, but the +volume on that list has caused a number of developers to tune it out. Please +do not spam unrelated lists and unrelated people, though. Many kernel-related lists are hosted on vger.kernel.org; you can find a list of them at http://vger.kernel.org/vger-lists.html. There are @@ -254,7 +259,7 @@ If you have a patch that fixes an exploitable security bug, send that patch to security@kernel.org. For severe bugs, a short embargo may be considered to allow distributors to get the patch out to users; in such cases, obviously, the patch should not be sent to any public lists. See also -Documentation/admin-guide/security-bugs.rst. +Documentation/process/security-bugs.rst. Patches that fix a severe bug in a released kernel should be directed toward the stable maintainers by putting a line like this:: @@ -320,7 +325,7 @@ for their time. Code review is a tiring and time-consuming process, and reviewers sometimes get grumpy. Even in that case, though, respond politely and address the problems they have pointed out. When sending a next version, add a ``patch changelog`` to the cover letter or to individual patches -explaining difference aganst previous submission (see +explaining difference against previous submission (see :ref:`the_canonical_patch_format`). See Documentation/process/email-clients.rst for recommendations on email @@ -498,9 +503,11 @@ Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes: The Reported-by tag gives credit to people who find bugs and report them and it 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 Link: tag pointing to the report, unless the report is not -available on the web. Please note that if the bug was reported in private, then -ask for permission first before using the Reported-by tag. +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. A Tested-by: tag indicates that the patch has been successfully tested (in some environment) by the person named. This tag informs maintainers that diff --git a/Documentation/riscv/hwprobe.rst b/Documentation/riscv/hwprobe.rst new file mode 100644 index 000000000000..9f0dd62dcb5d --- /dev/null +++ b/Documentation/riscv/hwprobe.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +RISC-V Hardware Probing Interface +--------------------------------- + +The RISC-V hardware probing interface is based around a single syscall, which +is defined in <asm/hwprobe.h>:: + + struct riscv_hwprobe { + __s64 key; + __u64 value; + }; + + long sys_riscv_hwprobe(struct riscv_hwprobe *pairs, size_t pair_count, + size_t cpu_count, cpu_set_t *cpus, + unsigned int flags); + +The arguments are split into three groups: an array of key-value pairs, a CPU +set, and some flags. The key-value pairs are supplied with a count. Userspace +must prepopulate the key field for each element, and the kernel will fill in the +value if the key is recognized. If a key is unknown to the kernel, its key field +will be cleared to -1, and its value set to 0. The CPU set is defined by +CPU_SET(3). For value-like keys (eg. vendor/arch/impl), the returned value will +be only be valid if all CPUs in the given set have the same value. Otherwise -1 +will be returned. For boolean-like keys, the value returned will be a logical +AND of the values for the specified CPUs. Usermode can supply NULL for cpus and +0 for cpu_count as a shortcut for all online CPUs. There are currently no flags, +this value must be zero for future compatibility. + +On success 0 is returned, on failure a negative error code is returned. + +The following keys are defined: + +* :c:macro:`RISCV_HWPROBE_KEY_MVENDORID`: Contains the value of ``mvendorid``, + as defined by the RISC-V privileged architecture specification. + +* :c:macro:`RISCV_HWPROBE_KEY_MARCHID`: Contains the value of ``marchid``, as + defined by the RISC-V privileged architecture specification. + +* :c:macro:`RISCV_HWPROBE_KEY_MIMPLID`: Contains the value of ``mimplid``, as + defined by the RISC-V privileged architecture specification. + +* :c:macro:`RISCV_HWPROBE_KEY_BASE_BEHAVIOR`: A bitmask containing the base + user-visible behavior that this kernel supports. The following base user ABIs + are defined: + + * :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: Support for rv32ima or + rv64ima, as defined by version 2.2 of the user ISA and version 1.10 of the + privileged ISA, with the following known exceptions (more exceptions may be + added, but only if it can be demonstrated that the user ABI is not broken): + + * The :fence.i: instruction cannot be directly executed by userspace + programs (it may still be executed in userspace via a + kernel-controlled mechanism such as the vDSO). + +* :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_0`: A bitmask containing the extensions + that are compatible with the :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: + base system behavior. + + * :c:macro:`RISCV_HWPROBE_IMA_FD`: The F and D extensions are supported, as + defined by commit cd20cee ("FMIN/FMAX now implement + minimumNumber/maximumNumber, not minNum/maxNum") of the RISC-V ISA manual. + + * :c:macro:`RISCV_HWPROBE_IMA_C`: The C extension is supported, as defined + by version 2.2 of the RISC-V ISA manual. + +* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance + information about the selected set of processors. + + * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNKNOWN`: The performance of misaligned + accesses is unknown. + + * :c:macro:`RISCV_HWPROBE_MISALIGNED_EMULATED`: Misaligned accesses are + emulated via software, either in or below the kernel. These accesses are + always extremely slow. + + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are supported + in hardware, but are slower than the cooresponding aligned accesses + sequences. + + * :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are supported + in hardware and are faster than the cooresponding aligned accesses + sequences. + + * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are + not supported at all and will generate a misaligned address fault. diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst index 2e5b18fbb145..175a91db0200 100644 --- a/Documentation/riscv/index.rst +++ b/Documentation/riscv/index.rst @@ -7,6 +7,7 @@ RISC-V architecture boot-image-header vm-layout + hwprobe patch-acceptance uabi diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst index 3be44e74ec5d..5462c84f4723 100644 --- a/Documentation/riscv/vm-layout.rst +++ b/Documentation/riscv/vm-layout.rst @@ -47,7 +47,7 @@ RISC-V Linux Kernel SV39 | Kernel-space virtual memory, shared between all processes: ____________________________________________________________|___________________________________________________________ | | | | - ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap + ffffffc6fea00000 | -228 GB | ffffffc6feffffff | 6 MB | fixmap ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space @@ -83,7 +83,7 @@ RISC-V Linux Kernel SV48 | Kernel-space virtual memory, shared between all processes: ____________________________________________________________|___________________________________________________________ | | | | - ffff8d7ffee00000 | -114.5 TB | ffff8d7ffeffffff | 2 MB | fixmap + ffff8d7ffea00000 | -114.5 TB | ffff8d7ffeffffff | 6 MB | fixmap ffff8d7fff000000 | -114.5 TB | ffff8d7fffffffff | 16 MB | PCI io ffff8d8000000000 | -114.5 TB | ffff8f7fffffffff | 2 TB | vmemmap ffff8f8000000000 | -112.5 TB | ffffaf7fffffffff | 32 TB | vmalloc/ioremap space @@ -119,7 +119,7 @@ RISC-V Linux Kernel SV57 | Kernel-space virtual memory, shared between all processes: ____________________________________________________________|___________________________________________________________ | | | | - ff1bfffffee00000 | -57 PB | ff1bfffffeffffff | 2 MB | fixmap + ff1bfffffea00000 | -57 PB | ff1bfffffeffffff | 6 MB | fixmap ff1bffffff000000 | -57 PB | ff1bffffffffffff | 16 MB | PCI io ff1c000000000000 | -57 PB | ff1fffffffffffff | 1 PB | vmemmap ff20000000000000 | -56 PB | ff5fffffffffffff | 16 PB | vmalloc/ioremap space diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst index ed7f4f5b3cf1..b91e9ef4d0c2 100644 --- a/Documentation/rust/arch-support.rst +++ b/Documentation/rust/arch-support.rst @@ -15,7 +15,7 @@ support corresponds to ``S`` values in the ``MAINTAINERS`` file. ============ ================ ============================================== Architecture Level of support Constraints ============ ================ ============================================== -``x86`` Maintained ``x86_64`` only. ``um`` Maintained ``x86_64`` only. +``x86`` Maintained ``x86_64`` only. ============ ================ ============================================== diff --git a/Documentation/scheduler/sched-arch.rst b/Documentation/scheduler/sched-arch.rst index 0eaec669790a..505cd27f9a92 100644 --- a/Documentation/scheduler/sched-arch.rst +++ b/Documentation/scheduler/sched-arch.rst @@ -70,7 +70,5 @@ Possible arch problems I found (and either tried to fix or didn't): ia64 - is safe_halt call racy vs interrupts? (does it sleep?) (See #4a) -sh64 - Is sleeping racy vs interrupts? (See #4a) - sparc - IRQs on at this point(?), change local_irq_save to _disable. - TODO: needs secondary CPUs to disable preempt (See #1) diff --git a/Documentation/scheduler/sched-capacity.rst b/Documentation/scheduler/sched-capacity.rst index 8e2b8538bc2b..e2c1cf743158 100644 --- a/Documentation/scheduler/sched-capacity.rst +++ b/Documentation/scheduler/sched-capacity.rst @@ -258,7 +258,7 @@ Linux cannot currently figure out CPU capacity on its own, this information thus needs to be handed to it. Architectures must define arch_scale_cpu_capacity() for that purpose. -The arm and arm64 architectures directly map this to the arch_topology driver +The arm, arm64, and RISC-V architectures directly map this to the arch_topology driver CPU scaling data, which is derived from the capacity-dmips-mhz CPU binding; see Documentation/devicetree/bindings/cpu/cpu-capacity.txt. diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst index a8c5bd15a440..6fa3a6279501 100644 --- a/Documentation/scsi/scsi_mid_low_api.rst +++ b/Documentation/scsi/scsi_mid_low_api.rst @@ -436,7 +436,7 @@ Details:: * * Defined in: drivers/scsi/hosts.c . **/ - struct Scsi_Host * scsi_host_alloc(struct scsi_host_template * sht, + struct Scsi_Host * scsi_host_alloc(const struct scsi_host_template * sht, int privsize) diff --git a/Documentation/security/lsm-development.rst b/Documentation/security/lsm-development.rst index ac53e5065f79..5895e529da7f 100644 --- a/Documentation/security/lsm-development.rst +++ b/Documentation/security/lsm-development.rst @@ -11,7 +11,7 @@ that end users and distros can make a more informed decision about which LSMs suit their requirements. For extensive documentation on the available LSM hook interfaces, please -see ``include/linux/lsm_hooks.h`` and associated structures: +see ``security/security.c`` and associated structures: -.. kernel-doc:: include/linux/lsm_hooks.h - :internal: +.. kernel-doc:: security/security.c + :export: diff --git a/Documentation/security/lsm.rst b/Documentation/security/lsm.rst index 6a2a2e973080..c20c7c72e2d6 100644 --- a/Documentation/security/lsm.rst +++ b/Documentation/security/lsm.rst @@ -98,7 +98,7 @@ associate these values with real security attributes. LSM hooks are maintained in lists. A list is maintained for each hook, and the hooks are called in the order specified by CONFIG_LSM. Detailed documentation for each hook is -included in the `include/linux/lsm_hooks.h` header file. +included in the `security/security.c` source file. The LSM framework provides for a close approximation of general security module stacking. It defines diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index 5f31fa5e2435..af71c68f1e4e 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -723,9 +723,10 @@ Module for EMU10K1/EMU10k2 based PCI sound cards. * Sound Blaster Live! * Sound Blaster PCI 512 -* Emu APS (partially supported) * Sound Blaster Audigy - +* E-MU APS (partially supported) +* E-MU DAS + extin bitmap of available external inputs for FX8010 (see below) extout diff --git a/Documentation/sound/cards/audigy-mixer.rst b/Documentation/sound/cards/audigy-mixer.rst index c506f8d16f2e..aa176451d5b5 100644 --- a/Documentation/sound/cards/audigy-mixer.rst +++ b/Documentation/sound/cards/audigy-mixer.rst @@ -19,9 +19,9 @@ Digital mixer controls These controls are built using the DSP instructions. They offer extended functionality. Only the default built-in code in the ALSA driver is described here. Note that the controls work as attenuators: the maximum value is the -neutral position leaving the signal unchanged. Note that if the same destination -is mentioned in multiple controls, the signal is accumulated and can be wrapped -(set to maximal or minimal value without checking of overflow). +neutral position leaving the signal unchanged. Note that if the same destination +is mentioned in multiple controls, the signal is accumulated and can be clipped +(set to maximal or minimal value without checking for overflow). Explanation of used abbreviations: @@ -32,17 +32,17 @@ ADC analog to digital converter I2S one-way three wire serial bus for digital sound by Philips Semiconductors - (this standard is used for connecting standalone DAC and ADC converters) + (this standard is used for connecting standalone D/A and A/D converters) LFE - low frequency effects (subwoofer signal) + low frequency effects (used as subwoofer signal) AC97 - a chip containing an analog mixer, DAC and ADC converters + a chip containing an analog mixer, D/A and A/D converters IEC958 S/PDIF FX-bus the EMU10K2 chip has an effect bus containing 64 accumulators. - Each of the synthesizer voices can feed its output to these accumulators - and the DSP microcontroller can operate with the resulting sum. + Each of the synthesizer voices can feed its output to these accumulators + and the DSP microcontroller can operate with the resulting sum. name='PCM Front Playback Volume',index=0 ---------------------------------------- @@ -218,8 +218,8 @@ LFE outputs. name='IEC958 Optical Raw Playback Switch',index=0 ------------------------------------------------- If this switch is on, then the samples for the IEC958 (S/PDIF) digital -output are taken only from the raw FX8010 PCM, otherwise standard front -PCM samples are taken. +output are taken only from the raw iec958 ALSA PCM device (which uses +accumulators 20 and 21 for left and right PCM by default). PCM stream related controls @@ -237,8 +237,8 @@ as follows: name='EMU10K1 PCM Send Routing',index 0-31 ------------------------------------------ -This control specifies the destination - FX-bus accumulators. There 24 -values with this mapping: +This control specifies the destination - FX-bus accumulators. There are 24 +values in this mapping: * 0 - mono, A destination (FX-bus 0-63), default 0 * 1 - mono, B destination (FX-bus 0-63), default 1 @@ -306,6 +306,9 @@ MANUALS/PATENTS ftp://opensource.creative.com/pub/doc ------------------------------------- +Note that the site is defunct, but the documents are available +from various other locations. + LM4545.pdf AC97 Codec diff --git a/Documentation/sound/cards/sb-live-mixer.rst b/Documentation/sound/cards/sb-live-mixer.rst index 357fcd619d39..819886634400 100644 --- a/Documentation/sound/cards/sb-live-mixer.rst +++ b/Documentation/sound/cards/sb-live-mixer.rst @@ -15,7 +15,7 @@ The ALSA driver programs this portion of chip by default code IEC958 (S/PDIF) raw PCM ======================= -This PCM device (it's the 4th PCM device (index 3!) and first subdevice +This PCM device (it's the 3rd PCM device (index 2!) and first subdevice (index 0) for a given card) allows to forward 48kHz, stereo, 16-bit little endian streams without any modifications to the digital output (coaxial or optical). The universal interface allows the creation of up @@ -33,9 +33,9 @@ Digital mixer controls These controls are built using the DSP instructions. They offer extended functionality. Only the default built-in code in the ALSA driver is described here. Note that the controls work as attenuators: the maximum value is the -neutral position leaving the signal unchanged. Note that if the same destination -is mentioned in multiple controls, the signal is accumulated and can be wrapped -(set to maximal or minimal value without checking of overflow). +neutral position leaving the signal unchanged. Note that if the same destination +is mentioned in multiple controls, the signal is accumulated and can be clipped +(set to maximal or minimal value without checking for overflow). Explanation of used abbreviations: @@ -46,11 +46,11 @@ ADC analog to digital converter I2S one-way three wire serial bus for digital sound by Philips Semiconductors - (this standard is used for connecting standalone DAC and ADC converters) + (this standard is used for connecting standalone D/A and A/D converters) LFE - low frequency effects (subwoofer signal) + low frequency effects (used as subwoofer signal) AC97 - a chip containing an analog mixer, DAC and ADC converters + a chip containing an analog mixer, D/A and A/D converters IEC958 S/PDIF FX-bus @@ -313,6 +313,9 @@ MANUALS/PATENTS ftp://opensource.creative.com/pub/doc ------------------------------------- +Note that the site is defunct, but the documents are available +from various other locations. + LM4545.pdf AC97 Codec m2049.pdf diff --git a/Documentation/sound/hd-audio/index.rst b/Documentation/sound/hd-audio/index.rst index 6e12de9fc34e..baefe4a5d165 100644 --- a/Documentation/sound/hd-audio/index.rst +++ b/Documentation/sound/hd-audio/index.rst @@ -9,3 +9,4 @@ HD-Audio controls dp-mst realtek-pc-beep + intel-multi-link diff --git a/Documentation/sound/hd-audio/intel-multi-link.rst b/Documentation/sound/hd-audio/intel-multi-link.rst new file mode 100644 index 000000000000..bf0bb78833e7 --- /dev/null +++ b/Documentation/sound/hd-audio/intel-multi-link.rst @@ -0,0 +1,312 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) +.. include:: <isonum.txt> + +================================================ +HDAudio multi-link extensions on Intel platforms +================================================ + +:Copyright: |copy| 2023 Intel Corporation + +This file documents the 'multi-link structure' introduced in 2015 with +the Skylake processor and recently extended in newer Intel platforms + +HDaudio existing link mapping (2015 addition in SkyLake) +======================================================== + +External HDAudio codecs are handled with link #0, while iDISP codec +for HDMI/DisplayPort is handled with link #1. + +The only change to the 2015 definitions is the declaration of the +LCAP.ALT=0x0 - since the ALT bit was previously reserved, this is a +backwards-compatible change. + +LCTL.SPA and LCTL.CPA are automatically set when exiting reset. They +are only used in existing drivers when the SCF value needs to be +corrected. + +Basic structure for HDaudio codecs +---------------------------------- + +:: + + +-----------+ + | ML cap #0 | + +-----------+ + | ML cap #1 |---+ + +-----------+ | + | + +--> 0x0 +---------------+ LCAP + | ALT=0 | + +---------------+ + | S192 | + +---------------+ + | S96 | + +---------------+ + | S48 | + +---------------+ + | S24 | + +---------------+ + | S12 | + +---------------+ + | S6 | + +---------------+ + + 0x4 +---------------+ LCTL + | INTSTS | + +---------------+ + | CPA | + +---------------+ + | SPA | + +---------------+ + | SCF | + +---------------+ + + 0x8 +---------------+ LOSIDV + | L1OSIVD15 | + +---------------+ + | L1OSIDV.. | + +---------------+ + | L1OSIDV1 | + +---------------+ + + 0xC +---------------+ LSDIID + | SDIID14 | + +---------------+ + | SDIID... | + +---------------+ + | SDIID0 | + +---------------+ + +SoundWire HDaudio extended link mapping +======================================= + +A SoundWire extended link is identified when LCAP.ALT=1 and +LEPTR.ID=0. + +DMA control uses the existing LOSIDV register. + +Changes include additional descriptions for enumeration that were not +present in earlier generations. + +- multi-link synchronization: capabilities in LCAP.LSS and control in LSYNC +- number of sublinks (manager IP) in LCAP.LSCOUNT +- power management moved from SHIM to LCTL.SPA bits +- hand-over to the DSP for access to multi-link registers, SHIM/IP with LCTL.OFLEN +- mapping of SoundWire codecs to SDI ID bits +- move of SHIM and Cadence registers to different offsets, with no + change in functionality. The LEPTR.PTR value is an offset from the + ML address, with a default value of 0x30000. + +Extended structure for SoundWire (assuming 4 Manager IP) +-------------------------------------------------------- + +:: + + +-----------+ + | ML cap #0 | + +-----------+ + | ML cap #1 | + +-----------+ + | ML cap #2 |---+ + +-----------+ | + | + +--> 0x0 +---------------+ LCAP + | ALT=1 | + +---------------+ + | INTC | + +---------------+ + | OFLS | + +---------------+ + | LSS | + +---------------+ + | SLCOUNT=4 |-----------+ + +---------------+ | + | + 0x4 +---------------+ LCTL | + | INTSTS | | + +---------------+ | + | CPA (x bits) | | + +---------------+ | + | SPA (x bits) | | + +---------------+ for each sublink x + | INTEN | | + +---------------+ | + | OFLEN | | + +---------------+ | + | + 0x8 +---------------+ LOSIDV | + | L1OSIVD15 | | + +---------------+ | + | L1OSIDV.. | | + +---------------+ | + | L1OSIDV1 | +---+----------------------------------------------------------+ + +---------------+ | | + v | + 0xC + 0x2 * x +---------------+ LSDIIDx +---> 0x30000 +-----------------+ 0x00030000 | + | SDIID14 | | | SoundWire SHIM | | + +---------------+ | | generic | | + | SDIID... | | +-----------------+ 0x00030100 | + +---------------+ | | SoundWire IP | | + | SDIID0 | | +-----------------+ 0x00036000 | + +---------------+ | | SoundWire SHIM | | + | | vendor-specific | | + 0x1C +---------------+ LSYNC | +-----------------+ | + | CMDSYNC | | v + +---------------+ | +-----------------+ 0x00030000 + 0x8000 * x + | SYNCGO | | | SoundWire SHIM | + +---------------+ | | generic | + | SYNCPU | | +-----------------+ 0x00030100 + 0x8000 * x + +---------------+ | | SoundWire IP | + | SYNPRD | | +-----------------+ 0x00036000 + 0x8000 * x + +---------------+ | | SoundWire SHIM | + | | vendor-specific | + 0x20 +---------------+ LEPTR | +-----------------+ + | ID = 0 | | + +---------------+ | + | VER | | + +---------------+ | + | PTR |------------+ + +---------------+ + + +DMIC HDaudio extended link mapping +================================== + +A DMIC extended link is identified when LCAP.ALT=1 and +LEPTR.ID=0xC1 are set. + +DMA control uses the existing LOSIDV register + +Changes include additional descriptions for enumeration that were not +present in earlier generations. + +- multi-link synchronization: capabilities in LCAP.LSS and control in LSYNC +- power management with LCTL.SPA bits +- hand-over to the DSP for access to multi-link registers, SHIM/IP with LCTL.OFLEN + +- move of DMIC registers to different offsets, with no change in + functionality. The LEPTR.PTR value is an offset from the ML + address, with a default value of 0x10000. + +Extended structure for DMIC +--------------------------- + +:: + + +-----------+ + | ML cap #0 | + +-----------+ + | ML cap #1 | + +-----------+ + | ML cap #2 |---+ + +-----------+ | + | + +--> 0x0 +---------------+ LCAP + | ALT=1 | + +---------------+ + | INTC | + +---------------+ + | OFLS | + +---------------+ + | SLCOUNT=1 | + +---------------+ + + 0x4 +---------------+ LCTL + | INTSTS | + +---------------+ + | CPA | + +---------------+ + | SPA | + +---------------+ + | INTEN | + +---------------+ + | OFLEN | + +---------------+ +---> 0x10000 +-----------------+ 0x00010000 + | | DMIC SHIM | + 0x8 +---------------+ LOSIDV | | generic | + | L1OSIVD15 | | +-----------------+ 0x00010100 + +---------------+ | | DMIC IP | + | L1OSIDV.. | | +-----------------+ 0x00016000 + +---------------+ | | DMIC SHIM | + | L1OSIDV1 | | | vendor-specific | + +---------------+ | +-----------------+ + | + 0x20 +---------------+ LEPTR | + | ID = 0xC1 | | + +---------------+ | + | VER | | + +---------------+ | + | PTR |-----------+ + +---------------+ + + +SSP HDaudio extended link mapping +================================= + +A DMIC extended link is identified when LCAP.ALT=1 and +LEPTR.ID=0xC0 are set. + +DMA control uses the existing LOSIDV register + +Changes include additional descriptions for enumeration and control that were not +present in earlier generations: +- number of sublinks (SSP IP instances) in LCAP.LSCOUNT +- power management moved from SHIM to LCTL.SPA bits +- hand-over to the DSP for access to multi-link registers, SHIM/IP +with LCTL.OFLEN +- move of SHIM and SSP IP registers to different offsets, with no +change in functionality. The LEPTR.PTR value is an offset from the ML +address, with a default value of 0x28000. + +Extended structure for SSP (assuming 3 instances of the IP) +----------------------------------------------------------- + +:: + + +-----------+ + | ML cap #0 | + +-----------+ + | ML cap #1 | + +-----------+ + | ML cap #2 |---+ + +-----------+ | + | + +--> 0x0 +---------------+ LCAP + | ALT=1 | + +---------------+ + | INTC | + +---------------+ + | OFLS | + +---------------+ + | SLCOUNT=3 |-------------------------for each sublink x -------------------------+ + +---------------+ | + | + 0x4 +---------------+ LCTL | + | INTSTS | | + +---------------+ | + | CPA (x bits) | | + +---------------+ | + | SPA (x bits) | | + +---------------+ | + | INTEN | | + +---------------+ | + | OFLEN | | + +---------------+ +---> 0x28000 +-----------------+ 0x00028000 | + | | SSP SHIM | | + 0x8 +---------------+ LOSIDV | | generic | | + | L1OSIVD15 | | +-----------------+ 0x00028100 | + +---------------+ | | SSP IP | | + | L1OSIDV.. | | +-----------------+ 0x00028C00 | + +---------------+ | | SSP SHIM | | + | L1OSIDV1 | | | vendor-specific | | + +---------------+ | +-----------------+ | + | v + 0x20 +---------------+ LEPTR | +-----------------+ 0x00028000 + 0x1000 * x + | ID = 0xC0 | | | SSP SHIM | + +---------------+ | | generic | + | VER | | +-----------------+ 0x00028100 + 0x1000 * x + +---------------+ | | SSP IP | + | PTR |-----------+ +-----------------+ 0x00028C00 + 0x1000 * x + +---------------+ | SSP SHIM | + | vendor-specific | + +-----------------+ diff --git a/Documentation/sound/hd-audio/models.rst b/Documentation/sound/hd-audio/models.rst index 9b52f50a6854..120430450014 100644 --- a/Documentation/sound/hd-audio/models.rst +++ b/Documentation/sound/hd-audio/models.rst @@ -704,7 +704,7 @@ ref no-jd BIOS setup but without jack-detection intel - Intel DG45* mobos + Intel D*45* mobos dell-m6-amic Dell desktops/laptops with analog mics dell-m6-dmic diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 5c9523b7d55c..c0f97b5e4249 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -19,18 +19,13 @@ explain the general topic of linux kernel coding and doesn't cover low-level driver implementation details. It only describes the standard way to write a PCI sound driver on ALSA. -This document is still a draft version. Any feedback and corrections, -please!! - File Tree Structure =================== General ------- -The file tree structure of ALSA driver is depicted below. - -:: +The file tree structure of ALSA driver is depicted below:: sound /core @@ -68,8 +63,8 @@ kernel config. core/oss ~~~~~~~~ -The codes for PCM and mixer OSS emulation modules are stored in this -directory. The rawmidi OSS emulation is included in the ALSA rawmidi +The code for OSS PCM and mixer emulation modules is stored in this +directory. The OSS rawmidi emulation is included in the ALSA rawmidi code since it's quite small. The sequencer code is stored in ``core/seq/oss`` directory (see `below <core/seq/oss_>`__). @@ -78,19 +73,19 @@ core/seq This directory and its sub-directories are for the ALSA sequencer. This directory contains the sequencer core and primary sequencer modules such -like snd-seq-midi, snd-seq-virmidi, etc. They are compiled only when +as snd-seq-midi, snd-seq-virmidi, etc. They are compiled only when ``CONFIG_SND_SEQUENCER`` is set in the kernel config. core/seq/oss ~~~~~~~~~~~~ -This contains the OSS sequencer emulation codes. +This contains the OSS sequencer emulation code. include directory ----------------- This is the place for the public header files of ALSA drivers, which are -to be exported to user-space, or included by several files at different +to be exported to user-space, or included by several files in different directories. Basically, the private header files should not be placed in this directory, but you may still find files there, due to historical reasons :) @@ -100,7 +95,7 @@ drivers directory This directory contains code shared among different drivers on different architectures. They are hence supposed not to be architecture-specific. -For example, the dummy pcm driver and the serial MIDI driver are found +For example, the dummy PCM driver and the serial MIDI driver are found in this directory. In the sub-directories, there is code for components which are independent from bus and cpu architectures. @@ -156,8 +151,8 @@ these architectures. usb directory ------------- -This directory contains the USB-audio driver. In the latest version, the -USB MIDI driver is integrated in the usb-audio driver. +This directory contains the USB-audio driver. +The USB MIDI driver is integrated in the usb-audio driver. pcmcia directory ---------------- @@ -175,9 +170,9 @@ layer including ASoC core, codec and machine drivers. oss directory ------------- -Here contains OSS/Lite codes. -All codes have been deprecated except for dmasound on m68k as of -writing this. +This contains OSS/Lite code. +At the time of writing, all code has been removed except for dmasound +on m68k. Basic Flow for PCI Drivers @@ -341,7 +336,7 @@ to details explained in the following section. error: snd_card_free(card); - return err; + return err; } /* destructor -- see the "Destructor" sub-section */ @@ -381,7 +376,7 @@ where ``enable[dev]`` is the module option. Each time the ``probe`` callback is called, check the availability of the device. If not available, simply increment the device index and -returns. dev will be incremented also later (`step 7 +return. dev will be incremented also later (`step 7 <7) Set the PCI driver data and return zero._>`__). 2) Create a card instance @@ -402,9 +397,7 @@ Components`_. 3) Create a main component ~~~~~~~~~~~~~~~~~~~~~~~~~~ -In this part, the PCI resources are allocated. - -:: +In this part, the PCI resources are allocated:: struct mychip *chip; .... @@ -417,13 +410,11 @@ Management`_. When something goes wrong, the probe function needs to deal with the error. In this example, we have a single error handling path placed -at the end of the function. - -:: +at the end of the function:: error: snd_card_free(card); - return err; + return err; Since each component can be properly freed, the single :c:func:`snd_card_free()` call should suffice in most cases. @@ -483,13 +474,11 @@ remove callback and power-management callbacks, too. Destructor ---------- -The destructor, remove callback, simply releases the card instance. Then -the ALSA middle layer will release all the attached components +The destructor, the remove callback, simply releases the card instance. +Then the ALSA middle layer will release all the attached components automatically. -It would be typically just calling :c:func:`snd_card_free()`: - -:: +It would be typically just calling :c:func:`snd_card_free()`:: static void snd_mychip_remove(struct pci_dev *pci) { @@ -504,9 +493,7 @@ Header Files ------------ For the above example, at least the following include files are -necessary. - -:: +necessary:: #include <linux/init.h> #include <linux/pci.h> @@ -544,9 +531,7 @@ list on the card record is used to manage the correct release of resources at destruction. As mentioned above, to create a card instance, call -:c:func:`snd_card_new()`. - -:: +:c:func:`snd_card_new()`:: struct snd_card *card; int err; @@ -572,10 +557,8 @@ struct snd_device object. A component can be a PCM instance, a control interface, a raw MIDI interface, etc. Each such instance has one component entry. -A component can be created via :c:func:`snd_device_new()` -function. - -:: +A component can be created via the :c:func:`snd_device_new()` +function:: snd_device_new(card, SNDRV_DEV_XXX, chip, &ops); @@ -591,7 +574,7 @@ allocated manually beforehand, and its pointer is passed as the argument. This pointer (``chip`` in the above example) is used as the identifier for the instance. -Each pre-defined ALSA component such as ac97 and pcm calls +Each pre-defined ALSA component such as AC97 and PCM calls :c:func:`snd_device_new()` inside its constructor. The destructor for each component is defined in the callback pointers. Hence, you don't need to take care of calling a destructor for such a component. @@ -605,9 +588,7 @@ Chip-Specific Data ------------------ Chip-specific information, e.g. the I/O port address, its resource -pointer, or the irq number, is stored in the chip-specific record. - -:: +pointer, or the irq number, is stored in the chip-specific record:: struct mychip { .... @@ -620,9 +601,7 @@ In general, there are two ways of allocating the chip record. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As mentioned above, you can pass the extra-data-length to the 5th -argument of :c:func:`snd_card_new()`, i.e. - -:: +argument of :c:func:`snd_card_new()`, e.g.:: err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, sizeof(struct mychip), &card); @@ -642,9 +621,7 @@ released together with the card instance. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ After allocating a card instance via :c:func:`snd_card_new()` -(with ``0`` on the 4th arg), call :c:func:`kzalloc()`. - -:: +(with ``0`` on the 4th arg), call :c:func:`kzalloc()`:: struct snd_card *card; struct mychip *chip; @@ -663,16 +640,12 @@ The chip record should have the field to hold the card pointer at least, }; -Then, set the card pointer in the returned chip instance. - -:: +Then, set the card pointer in the returned chip instance:: chip->card = card; Next, initialize the fields, and register this chip record as a -low-level device with a specified ``ops``, - -:: +low-level device with a specified ``ops``:: static const struct snd_device_ops ops = { .dev_free = snd_mychip_dev_free, @@ -681,9 +654,7 @@ low-level device with a specified ``ops``, snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops); :c:func:`snd_mychip_dev_free()` is the device-destructor -function, which will call the real destructor. - -:: +function, which will call the real destructor:: static int snd_mychip_dev_free(struct snd_device *device) { @@ -692,10 +663,10 @@ function, which will call the real destructor. where :c:func:`snd_mychip_free()` is the real destructor. -The demerit of this method is the obviously more amount of codes. -The merit is, however, you can trigger the own callback at registering -and disconnecting the card via setting in snd_device_ops. -About the registering and disconnecting the card, see the subsections +The demerit of this method is the obviously larger amount of code. +The merit is, however, that you can trigger your own callback at +registering and disconnecting the card via a setting in snd_device_ops. +About registering and disconnecting the card, see the subsections below. @@ -724,9 +695,7 @@ Full Code Example ----------------- In this section, we'll complete the chip-specific constructor, -destructor and PCI entries. Example code is shown first, below. - -:: +destructor and PCI entries. Example code is shown first, below:: struct mychip { struct snd_card *card; @@ -866,9 +835,7 @@ resources. Also, you need to set the proper PCI DMA mask to limit the accessed I/O range. In some cases, you might need to call :c:func:`pci_set_master()` function, too. -Suppose the 28bit mask, and the code to be added would be like: - -:: +Suppose a 28bit mask, the code to be added would look like:: err = pci_enable_device(pci); if (err < 0) @@ -890,9 +857,7 @@ function (see below). Now assume that the PCI device has an I/O port with 8 bytes and an interrupt. Then struct mychip will have the -following fields: - -:: +following fields:: struct mychip { struct snd_card *card; @@ -905,14 +870,12 @@ following fields: For an I/O port (and also a memory region), you need to have the resource pointer for the standard resource management. For an irq, you have to keep only the irq number (integer). But you need to initialize -this number as -1 before actual allocation, since irq 0 is valid. The +this number to -1 before actual allocation, since irq 0 is valid. The port address and its resource pointer can be initialized as null by :c:func:`kzalloc()` automatically, so you don't have to take care of resetting them. -The allocation of an I/O port is done like this: - -:: +The allocation of an I/O port is done like this:: err = pci_request_regions(pci, "My Chip"); if (err < 0) { @@ -928,9 +891,7 @@ The returned value, ``chip->res_port``, is allocated via must be released via :c:func:`kfree()`, but there is a problem with this. This issue will be explained later. -The allocation of an interrupt source is done like this: - -:: +The allocation of an interrupt source is done like this:: if (request_irq(pci->irq, snd_mychip_interrupt, IRQF_SHARED, KBUILD_MODNAME, chip)) { @@ -954,9 +915,7 @@ used for that, but you can use what you like, too. I won't give details about the interrupt handler at this point, but at least its appearance can be explained now. The interrupt handler looks -usually like the following: - -:: +usually as follows:: static irqreturn_t snd_mychip_interrupt(int irq, void *dev_id) { @@ -966,13 +925,12 @@ usually like the following: } After requesting the IRQ, you can passed it to ``card->sync_irq`` -field: -:: +field:: card->irq = chip->irq; -This allows PCM core automatically performing -:c:func:`synchronize_irq()` at the necessary timing like ``hw_free``. +This allows the PCM core to automatically call +:c:func:`synchronize_irq()` at the right time, like before ``hw_free``. See the later section `sync_stop callback`_ for details. Now let's write the corresponding destructor for the resources above. @@ -981,9 +939,7 @@ activated) and release the resources. So far, we have no hardware part, so the disabling code is not written here. To release the resources, the “check-and-release†method is a safer way. -For the interrupt, do like this: - -:: +For the interrupt, do like this:: if (chip->irq >= 0) free_irq(chip->irq, chip); @@ -997,9 +953,7 @@ When you requested I/O ports or memory regions via :c:func:`pci_request_regions()` like in this example, release the resource(s) using the corresponding function, :c:func:`pci_release_region()` or -:c:func:`pci_release_regions()`. - -:: +:c:func:`pci_release_regions()`:: pci_release_regions(chip->pci); @@ -1007,39 +961,32 @@ When you requested manually via :c:func:`request_region()` or :c:func:`request_mem_region()`, you can release it via :c:func:`release_resource()`. Suppose that you keep the resource pointer returned from :c:func:`request_region()` in -chip->res_port, the release procedure looks like: - -:: +chip->res_port, the release procedure looks like:: release_and_free_resource(chip->res_port); Don't forget to call :c:func:`pci_disable_device()` before the end. -And finally, release the chip-specific record. - -:: +And finally, release the chip-specific record:: kfree(chip); -We didn't implement the hardware disabling part in the above. If you +We didn't implement the hardware disabling part above. If you need to do this, please note that the destructor may be called even before the initialization of the chip is completed. It would be better to have a flag to skip hardware disabling if the hardware was not initialized yet. When the chip-data is assigned to the card using -:c:func:`snd_device_new()` with ``SNDRV_DEV_LOWLELVEL`` , its -destructor is called at the last. That is, it is assured that all other +:c:func:`snd_device_new()` with ``SNDRV_DEV_LOWLELVEL``, its +destructor is called last. That is, it is assured that all other components like PCMs and controls have already been released. You don't have to stop PCMs, etc. explicitly, but just call low-level hardware stopping. The management of a memory-mapped region is almost as same as the -management of an I/O port. You'll need three fields like the -following: - -:: +management of an I/O port. You'll need two fields as follows:: struct mychip { .... @@ -1047,9 +994,7 @@ following: void __iomem *iobase_virt; }; -and the allocation would be like below: - -:: +and the allocation would look like below:: err = pci_request_regions(pci, "My Chip"); if (err < 0) { @@ -1060,9 +1005,7 @@ and the allocation would be like below: chip->iobase_virt = ioremap(chip->iobase_phys, pci_resource_len(pci, 0)); -and the corresponding destructor would be: - -:: +and the corresponding destructor would be:: static int snd_mychip_free(struct mychip *chip) { @@ -1075,9 +1018,7 @@ and the corresponding destructor would be: } Of course, a modern way with :c:func:`pci_iomap()` will make things a -bit easier, too. - -:: +bit easier, too:: err = pci_request_regions(pci, "My Chip"); if (err < 0) { @@ -1097,9 +1038,7 @@ struct pci_device_id table for this chipset. It's a table of PCI vendor/device ID number, and some masks. -For example, - -:: +For example:: static struct pci_device_id snd_mychip_ids[] = { { PCI_VENDOR_ID_FOO, PCI_DEVICE_ID_BAR, @@ -1120,9 +1059,7 @@ The last entry of this list is the terminator. You must specify this all-zero entry. Then, prepare the struct pci_driver -record: - -:: +record:: static struct pci_driver driver = { .name = KBUILD_MODNAME, @@ -1133,11 +1070,9 @@ record: The ``probe`` and ``remove`` functions have already been defined in the previous sections. The ``name`` field is the name string of this -device. Note that you must not use a slash “/†in this string. - -And at last, the module entries: +device. Note that you must not use slashes (“/â€) in this string. -:: +And at last, the module entries:: static int __init alsa_card_mychip_init(void) { @@ -1167,22 +1102,22 @@ The PCM middle layer of ALSA is quite powerful and it is only necessary for each driver to implement the low-level functions to access its hardware. -For accessing to the PCM layer, you need to include ``<sound/pcm.h>`` +To access the PCM layer, you need to include ``<sound/pcm.h>`` first. In addition, ``<sound/pcm_params.h>`` might be needed if you -access to some functions related with hw_param. +access some functions related with hw_param. -Each card device can have up to four pcm instances. A pcm instance -corresponds to a pcm device file. The limitation of number of instances -comes only from the available bit size of the Linux's device numbers. -Once when 64bit device number is used, we'll have more pcm instances +Each card device can have up to four PCM instances. A PCM instance +corresponds to a PCM device file. The limitation of number of instances +comes only from the available bit size of Linux' device numbers. +Once 64bit device numbers are used, we'll have more PCM instances available. -A pcm instance consists of pcm playback and capture streams, and each -pcm stream consists of one or more pcm substreams. Some soundcards +A PCM instance consists of PCM playback and capture streams, and each +PCM stream consists of one or more PCM substreams. Some soundcards support multiple playback functions. For example, emu10k1 has a PCM playback of 32 stereo substreams. In this case, at each open, a free substream is (usually) automatically chosen and opened. Meanwhile, when -only one substream exists and it was already opened, the successful open +only one substream exists and it was already opened, a subsequent open will either block or error with ``EAGAIN`` according to the file open mode. But you don't have to care about such details in your driver. The PCM middle layer will take care of such work. @@ -1191,9 +1126,7 @@ Full Code Example ----------------- The example code below does not include any hardware access routines but -shows only the skeleton, how to build up the PCM interfaces. - -:: +shows only the skeleton, how to build up the PCM interfaces:: #include <sound/pcm.h> .... @@ -1399,10 +1332,8 @@ shows only the skeleton, how to build up the PCM interfaces. PCM Constructor --------------- -A pcm instance is allocated by the :c:func:`snd_pcm_new()` -function. It would be better to create a constructor for pcm, namely, - -:: +A PCM instance is allocated by the :c:func:`snd_pcm_new()` +function. It would be better to create a constructor for the PCM, namely:: static int snd_mychip_new_pcm(struct mychip *chip) { @@ -1415,16 +1346,16 @@ function. It would be better to create a constructor for pcm, namely, pcm->private_data = chip; strcpy(pcm->name, "My Chip"); chip->pcm = pcm; - .... + ... return 0; } -The :c:func:`snd_pcm_new()` function takes four arguments. The -first argument is the card pointer to which this pcm is assigned, and +The :c:func:`snd_pcm_new()` function takes six arguments. The +first argument is the card pointer to which this PCM is assigned, and the second is the ID string. The third argument (``index``, 0 in the above) is the index of this new -pcm. It begins from zero. If you create more than one pcm instances, +PCM. It begins from zero. If you create more than one PCM instances, specify the different numbers in this argument. For example, ``index = 1`` for the second PCM device. @@ -1437,26 +1368,20 @@ If a chip supports multiple playbacks or captures, you can specify more numbers, but they must be handled properly in open/close, etc. callbacks. When you need to know which substream you are referring to, then it can be obtained from struct snd_pcm_substream data passed to each -callback as follows: - -:: +callback as follows:: struct snd_pcm_substream *substream; int index = substream->number; -After the pcm is created, you need to set operators for each pcm stream. - -:: +After the PCM is created, you need to set operators for each PCM stream:: snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &snd_mychip_playback_ops); snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &snd_mychip_capture_ops); -The operators are defined typically like this: - -:: +The operators are defined typically like this:: static struct snd_pcm_ops snd_mychip_playback_ops = { .open = snd_mychip_pcm_open, @@ -1472,25 +1397,21 @@ All the callbacks are described in the Operators_ subsection. After setting the operators, you probably will want to pre-allocate the buffer and set up the managed allocation mode. -For that, simply call the following: - -:: +For that, simply call the following:: snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_DEV, &chip->pci->dev, 64*1024, 64*1024); -It will allocate a buffer up to 64kB as default. Buffer management +It will allocate a buffer up to 64kB by default. Buffer management details will be described in the later section `Buffer and Memory Management`_. -Additionally, you can set some extra information for this pcm in +Additionally, you can set some extra information for this PCM in ``pcm->info_flags``. The available values are defined as ``SNDRV_PCM_INFO_XXX`` in ``<sound/asound.h>``, which is used for the hardware definition (described later). When your soundchip supports only -half-duplex, specify like this: - -:: +half-duplex, specify it like this:: pcm->info_flags = SNDRV_PCM_INFO_HALF_DUPLEX; @@ -1498,15 +1419,13 @@ half-duplex, specify like this: ... And the Destructor? ----------------------- -The destructor for a pcm instance is not always necessary. Since the pcm +The destructor for a PCM instance is not always necessary. Since the PCM device will be released by the middle layer code automatically, you don't have to call the destructor explicitly. The destructor would be necessary if you created special records internally and needed to release them. In such a case, set the -destructor function to ``pcm->private_free``: - -:: +destructor function to ``pcm->private_free``:: static void mychip_pcm_free(struct snd_pcm *pcm) { @@ -1537,13 +1456,11 @@ Runtime Pointer - The Chest of PCM Information When the PCM substream is opened, a PCM runtime instance is allocated and assigned to the substream. This pointer is accessible via ``substream->runtime``. This runtime pointer holds most information you -need to control the PCM: the copy of hw_params and sw_params +need to control the PCM: a copy of hw_params and sw_params configurations, the buffer pointers, mmap records, spinlocks, etc. The definition of runtime instance is found in ``<sound/pcm.h>``. Here -are the contents of this file: - -:: +is the relevant part of this file:: struct _snd_pcm_runtime { /* -- Status -- */ @@ -1577,14 +1494,19 @@ are the contents of this file: unsigned int period_step; unsigned int sleep_min; /* min ticks to sleep */ snd_pcm_uframes_t start_threshold; - snd_pcm_uframes_t stop_threshold; - snd_pcm_uframes_t silence_threshold; /* Silence filling happens when - noise is nearest than this */ - snd_pcm_uframes_t silence_size; /* Silence filling size */ + /* + * The following two thresholds alleviate playback buffer underruns; when + * hw_avail drops below the threshold, the respective action is triggered: + */ + snd_pcm_uframes_t stop_threshold; /* - stop playback */ + snd_pcm_uframes_t silence_threshold; /* - pre-fill buffer with silence */ + snd_pcm_uframes_t silence_size; /* max size of silence pre-fill; when >= boundary, + * fill played area with silence immediately */ snd_pcm_uframes_t boundary; /* pointers wrap point */ - snd_pcm_uframes_t silenced_start; - snd_pcm_uframes_t silenced_size; + /* internal data of auto-silencer */ + snd_pcm_uframes_t silence_start; /* starting pointer to silence area */ + snd_pcm_uframes_t silence_filled; /* size filled with silence */ snd_pcm_sync_id_t sync; /* hardware synchronization ID */ @@ -1638,14 +1560,12 @@ Hardware Description The hardware descriptor (struct snd_pcm_hardware) contains the definitions of the fundamental hardware configuration. Above all, you'll need to define this -in the `PCM open callback`_. Note that the runtime instance holds the copy of -the descriptor, not the pointer to the existing descriptor. That is, +in the `PCM open callback`_. Note that the runtime instance holds a copy of +the descriptor, not a pointer to the existing descriptor. That is, in the open callback, you can modify the copied descriptor (``runtime->hw``) as you need. For example, if the maximum number of channels is 1 only on some chip models, you can still use the same -hardware descriptor and change the channels_max later: - -:: +hardware descriptor and change the channels_max later:: struct snd_pcm_runtime *runtime = substream->runtime; ... @@ -1653,9 +1573,7 @@ hardware descriptor and change the channels_max later: if (chip->model == VERY_OLD_ONE) runtime->hw.channels_max = 1; -Typically, you'll have a hardware descriptor as below: - -:: +Typically, you'll have a hardware descriptor as below:: static struct snd_pcm_hardware snd_mychip_playback_hw = { .info = (SNDRV_PCM_INFO_MMAP | @@ -1676,51 +1594,51 @@ Typically, you'll have a hardware descriptor as below: }; - The ``info`` field contains the type and capabilities of this - pcm. The bit flags are defined in ``<sound/asound.h>`` as + PCM. The bit flags are defined in ``<sound/asound.h>`` as ``SNDRV_PCM_INFO_XXX``. Here, at least, you have to specify whether - the mmap is supported and which interleaved format is + mmap is supported and which interleaving formats are supported. When the hardware supports mmap, add the ``SNDRV_PCM_INFO_MMAP`` flag here. When the hardware supports the - interleaved or the non-interleaved formats, + interleaved or the non-interleaved formats, the ``SNDRV_PCM_INFO_INTERLEAVED`` or ``SNDRV_PCM_INFO_NONINTERLEAVED`` flag must be set, respectively. If both are supported, you can set both, too. In the above example, ``MMAP_VALID`` and ``BLOCK_TRANSFER`` are specified for the OSS mmap mode. Usually both are set. Of course, - ``MMAP_VALID`` is set only if the mmap is really supported. + ``MMAP_VALID`` is set only if mmap is really supported. The other possible flags are ``SNDRV_PCM_INFO_PAUSE`` and - ``SNDRV_PCM_INFO_RESUME``. The ``PAUSE`` bit means that the pcm + ``SNDRV_PCM_INFO_RESUME``. The ``PAUSE`` bit means that the PCM supports the “pause†operation, while the ``RESUME`` bit means that - the pcm supports the full “suspend/resume†operation. If the + the PCM supports the full “suspend/resume†operation. If the ``PAUSE`` flag is set, the ``trigger`` callback below must handle the corresponding (pause push/release) commands. The suspend/resume trigger commands can be defined even without the ``RESUME`` - flag. See `Power Management`_ section for details. + flag. See the `Power Management`_ section for details. When the PCM substreams can be synchronized (typically, - synchronized start/stop of a playback and a capture streams), you + synchronized start/stop of a playback and a capture stream), you can give ``SNDRV_PCM_INFO_SYNC_START``, too. In this case, you'll need to check the linked-list of PCM substreams in the trigger - callback. This will be described in the later section. + callback. This will be described in a later section. -- ``formats`` field contains the bit-flags of supported formats +- The ``formats`` field contains the bit-flags of supported formats (``SNDRV_PCM_FMTBIT_XXX``). If the hardware supports more than one format, give all or'ed bits. In the example above, the signed 16bit little-endian format is specified. -- ``rates`` field contains the bit-flags of supported rates +- The ``rates`` field contains the bit-flags of supported rates (``SNDRV_PCM_RATE_XXX``). When the chip supports continuous rates, - pass ``CONTINUOUS`` bit additionally. The pre-defined rate bits are - provided only for typical rates. If your chip supports + pass the ``CONTINUOUS`` bit additionally. The pre-defined rate bits + are provided only for typical rates. If your chip supports unconventional rates, you need to add the ``KNOT`` bit and set up the hardware constraint manually (explained later). - ``rate_min`` and ``rate_max`` define the minimum and maximum sample rate. This should correspond somehow to ``rates`` bits. -- ``channels_min`` and ``channels_max`` define, as you might already +- ``channels_min`` and ``channels_max`` define, as you might have already expected, the minimum and maximum number of channels. - ``buffer_bytes_max`` defines the maximum buffer size in @@ -1732,15 +1650,16 @@ Typically, you'll have a hardware descriptor as below: number of periods in the buffer. The “period†is a term that corresponds to a fragment in the OSS - world. The period defines the size at which a PCM interrupt is - generated. This size strongly depends on the hardware. Generally, - the smaller period size will give you more interrupts, that is, - more controls. In the case of capture, this size defines the input - latency. On the other hand, the whole buffer size defines the - output latency for the playback direction. + world. The period defines the point at which a PCM interrupt is + generated. This point strongly depends on the hardware. Generally, + a smaller period size will give you more interrupts, which results + in being able to fill/drain the buffer more timely. In the case of + capture, this size defines the input latency. On the other hand, + the whole buffer size defines the output latency for the playback + direction. - There is also a field ``fifo_size``. This specifies the size of the - hardware FIFO, but currently it is neither used in the driver nor + hardware FIFO, but currently it is neither used by the drivers nor in the alsa-lib. So, you can ignore this field. PCM Configurations @@ -1759,34 +1678,32 @@ One thing to be noted is that the configured buffer and period sizes are stored in “frames†in the runtime. In the ALSA world, ``1 frame = channels \* samples-size``. For conversion between frames and bytes, you can use the :c:func:`frames_to_bytes()` and -:c:func:`bytes_to_frames()` helper functions. - -:: +:c:func:`bytes_to_frames()` helper functions:: period_bytes = frames_to_bytes(runtime, runtime->period_size); Also, many software parameters (sw_params) are stored in frames, too. -Please check the type of the field. ``snd_pcm_uframes_t`` is for the -frames as unsigned integer while ``snd_pcm_sframes_t`` is for the +Please check the type of the field. ``snd_pcm_uframes_t`` is for +frames as unsigned integer while ``snd_pcm_sframes_t`` is for frames as signed integer. DMA Buffer Information ~~~~~~~~~~~~~~~~~~~~~~ -The DMA buffer is defined by the following four fields, ``dma_area``, -``dma_addr``, ``dma_bytes`` and ``dma_private``. The ``dma_area`` +The DMA buffer is defined by the following four fields: ``dma_area``, +``dma_addr``, ``dma_bytes`` and ``dma_private``. ``dma_area`` holds the buffer pointer (the logical address). You can call :c:func:`memcpy()` from/to this pointer. Meanwhile, ``dma_addr`` holds the physical address of the buffer. This field is specified only when -the buffer is a linear buffer. ``dma_bytes`` holds the size of buffer -in bytes. ``dma_private`` is used for the ALSA DMA allocator. +the buffer is a linear buffer. ``dma_bytes`` holds the size of the +buffer in bytes. ``dma_private`` is used for the ALSA DMA allocator. If you use either the managed buffer allocation mode or the standard API function :c:func:`snd_pcm_lib_malloc_pages()` for allocating the buffer, these fields are set by the ALSA middle layer, and you should *not* change them by yourself. You can read them but not write them. On the other hand, if you want to allocate the buffer by yourself, you'll -need to manage it in hw_params callback. At least, ``dma_bytes`` is +need to manage it in the hw_params callback. At least, ``dma_bytes`` is mandatory. ``dma_area`` is necessary when the buffer is mmapped. If your driver doesn't support mmap, this field is not necessary. ``dma_addr`` is also optional. You can use dma_private as @@ -1796,13 +1713,13 @@ Running Status ~~~~~~~~~~~~~~ The running status can be referred via ``runtime->status``. This is -the pointer to the struct snd_pcm_mmap_status record. +a pointer to a struct snd_pcm_mmap_status record. For example, you can get the current DMA hardware pointer via ``runtime->status->hw_ptr``. The DMA application pointer can be referred via ``runtime->control``, -which points to the struct snd_pcm_mmap_control record. -However, accessing directly to this value is not recommended. +which points to a struct snd_pcm_mmap_control record. +However, accessing this value directly is not recommended. Private Data ~~~~~~~~~~~~ @@ -1811,11 +1728,10 @@ You can allocate a record for the substream and store it in ``runtime->private_data``. Usually, this is done in the `PCM open callback`_. Don't mix this with ``pcm->private_data``. The ``pcm->private_data`` usually points to the chip instance assigned -statically at the creation of PCM, while the ``runtime->private_data`` -points to a dynamic data structure created at the PCM open -callback. - -:: +statically at creation time of the PCM device, while +``runtime->private_data`` +points to a dynamic data structure created in the PCM open +callback:: static int snd_xxx_open(struct snd_pcm_substream *substream) { @@ -1832,20 +1748,18 @@ The allocated object must be released in the `close callback`_. Operators --------- -OK, now let me give details about each pcm callback (``ops``). In +OK, now let me give details about each PCM callback (``ops``). In general, every callback must return 0 if successful, or a negative error number such as ``-EINVAL``. To choose an appropriate error number, it is advised to check what value other parts of the kernel return when the same kind of request fails. -The callback function takes at least the argument with +Each callback function takes at least one argument containing a struct snd_pcm_substream pointer. To retrieve the chip record from the given substream instance, you can use the following -macro. - -:: +macro:: - int xxx() { + int xxx(...) { struct mychip *chip = snd_pcm_substream_chip(substream); .... } @@ -1864,12 +1778,10 @@ PCM open callback static int snd_xxx_open(struct snd_pcm_substream *substream); -This is called when a pcm substream is opened. +This is called when a PCM substream is opened. At least, here you have to initialize the ``runtime->hw`` -record. Typically, this is done by like this: - -:: +record. Typically, this is done like this:: static int snd_xxx_open(struct snd_pcm_substream *substream) { @@ -1883,7 +1795,7 @@ record. Typically, this is done by like this: where ``snd_mychip_playback_hw`` is the pre-defined hardware description. -You can allocate a private data in this callback, as described in +You can allocate private data in this callback, as described in the `Private Data`_ section. If the hardware configuration needs more constraints, set the hardware @@ -1897,12 +1809,10 @@ close callback static int snd_xxx_close(struct snd_pcm_substream *substream); -Obviously, this is called when a pcm substream is closed. - -Any private instance for a pcm substream allocated in the ``open`` -callback will be released here. +Obviously, this is called when a PCM substream is closed. -:: +Any private instance for a PCM substream allocated in the ``open`` +callback will be released here:: static int snd_xxx_close(struct snd_pcm_substream *substream) { @@ -1914,9 +1824,9 @@ callback will be released here. ioctl callback ~~~~~~~~~~~~~~ -This is used for any special call to pcm ioctls. But usually you can -leave it as NULL, then PCM core calls the generic ioctl callback -function :c:func:`snd_pcm_lib_ioctl()`. If you need to deal with the +This is used for any special call to PCM ioctls. But usually you can +leave it NULL, then the PCM core calls the generic ioctl callback +function :c:func:`snd_pcm_lib_ioctl()`. If you need to deal with a unique setup of channel info or reset procedure, you can pass your own callback function here. @@ -1928,22 +1838,20 @@ hw_params callback static int snd_xxx_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *hw_params); -This is called when the hardware parameter (``hw_params``) is set up +This is called when the hardware parameters (``hw_params``) are set up by the application, that is, once when the buffer size, the period -size, the format, etc. are defined for the pcm substream. +size, the format, etc. are defined for the PCM substream. Many hardware setups should be done in this callback, including the allocation of buffers. -Parameters to be initialized are retrieved by +Parameters to be initialized are retrieved by the :c:func:`params_xxx()` macros. -When you set up the managed buffer allocation mode for the substream, +When you choose managed buffer allocation mode for the substream, a buffer is already allocated before this callback gets called. Alternatively, you can call a helper function below for -allocating the buffer, too. - -:: +allocating the buffer:: snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params)); @@ -1951,8 +1859,8 @@ allocating the buffer, too. DMA buffers have been pre-allocated. See the section `Buffer Types`_ for more details. -Note that this and ``prepare`` callbacks may be called multiple times -per initialization. For example, the OSS emulation may call these +Note that this one and the ``prepare`` callback may be called multiple +times per initialization. For example, the OSS emulation may call these callbacks at each change via its ioctl. Thus, you need to be careful not to allocate the same buffers many @@ -1960,10 +1868,10 @@ times, which will lead to memory leaks! Calling the helper function above many times is OK. It will release the previous buffer automatically when it was already allocated. -Another note is that this callback is non-atomic (schedulable) as +Another note is that this callback is non-atomic (schedulable) by default, i.e. when no ``nonatomic`` flag set. This is important, because the ``trigger`` callback is atomic (non-schedulable). That is, -mutexes or any schedule-related functions are not available in +mutexes or any schedule-related functions are not available in the ``trigger`` callback. Please see the subsection Atomicity_ for details. @@ -1979,16 +1887,14 @@ This is called to release the resources allocated via This function is always called before the close callback is called. Also, the callback may be called multiple times, too. Keep track -whether the resource was already released. +whether each resource was already released. -When you have set up the managed buffer allocation mode for the PCM +When you have chosen managed buffer allocation mode for the PCM substream, the allocated PCM buffer will be automatically released after this callback gets called. Otherwise you'll have to release the buffer manually. Typically, when the buffer was allocated from the pre-allocated pool, you can use the standard API function -:c:func:`snd_pcm_lib_malloc_pages()` like: - -:: +:c:func:`snd_pcm_lib_malloc_pages()` like:: snd_pcm_lib_free_pages(substream); @@ -1999,13 +1905,13 @@ prepare callback static int snd_xxx_prepare(struct snd_pcm_substream *substream); -This callback is called when the pcm is “preparedâ€. You can set the +This callback is called when the PCM is “preparedâ€. You can set the format type, sample rate, etc. here. The difference from ``hw_params`` is that the ``prepare`` callback will be called each time :c:func:`snd_pcm_prepare()` is called, i.e. when recovering after underruns, etc. -Note that this callback is now non-atomic. You can use +Note that this callback is non-atomic. You can use schedule-related functions safely in this callback. In this and the following callbacks, you can refer to the values via @@ -2026,13 +1932,11 @@ trigger callback static int snd_xxx_trigger(struct snd_pcm_substream *substream, int cmd); -This is called when the pcm is started, stopped or paused. - -Which action is specified in the second argument, -``SNDRV_PCM_TRIGGER_XXX`` in ``<sound/pcm.h>``. At least, the ``START`` -and ``STOP`` commands must be defined in this callback. +This is called when the PCM is started, stopped or paused. -:: +The action is specified in the second argument, ``SNDRV_PCM_TRIGGER_XXX`` +defined in ``<sound/pcm.h>``. At least, the ``START`` +and ``STOP`` commands must be defined in this callback:: switch (cmd) { case SNDRV_PCM_TRIGGER_START: @@ -2045,23 +1949,23 @@ and ``STOP`` commands must be defined in this callback. return -EINVAL; } -When the pcm supports the pause operation (given in the info field of +When the PCM supports the pause operation (given in the info field of the hardware table), the ``PAUSE_PUSH`` and ``PAUSE_RELEASE`` commands -must be handled here, too. The former is the command to pause the pcm, -and the latter to restart the pcm again. +must be handled here, too. The former is the command to pause the PCM, +and the latter to restart the PCM again. -When the pcm supports the suspend/resume operation, regardless of full +When the PCM supports the suspend/resume operation, regardless of full or partial suspend/resume support, the ``SUSPEND`` and ``RESUME`` commands must be handled, too. These commands are issued when the power-management status is changed. Obviously, the ``SUSPEND`` and -``RESUME`` commands suspend and resume the pcm substream, and usually, +``RESUME`` commands suspend and resume the PCM substream, and usually, they are identical to the ``STOP`` and ``START`` commands, respectively. See the `Power Management`_ section for details. -As mentioned, this callback is atomic as default unless ``nonatomic`` +As mentioned, this callback is atomic by default unless the ``nonatomic`` flag set, and you cannot call functions which may sleep. The ``trigger`` callback should be as minimal as possible, just really -triggering the DMA. The other stuff should be initialized +triggering the DMA. The other stuff should be initialized in ``hw_params`` and ``prepare`` callbacks properly beforehand. sync_stop callback @@ -2072,22 +1976,22 @@ sync_stop callback static int snd_xxx_sync_stop(struct snd_pcm_substream *substream); This callback is optional, and NULL can be passed. It's called after -the PCM core stops the stream and changes the stream state +the PCM core stops the stream, before it changes the stream state via ``prepare``, ``hw_params`` or ``hw_free``. Since the IRQ handler might be still pending, we need to wait until the pending task finishes before moving to the next step; otherwise it -might lead to a crash due to resource conflicts or access to the freed +might lead to a crash due to resource conflicts or access to freed resources. A typical behavior is to call a synchronization function like :c:func:`synchronize_irq()` here. -For majority of drivers that need only a call of +For the majority of drivers that need only a call of :c:func:`synchronize_irq()`, there is a simpler setup, too. -While keeping NULL to ``sync_stop`` PCM callback, the driver can set -``card->sync_irq`` field to store the valid interrupt number after -requesting an IRQ, instead. Then PCM core will look call +While keeping the ``sync_stop`` PCM callback NULL, the driver can set +the ``card->sync_irq`` field to the returned interrupt number after +requesting an IRQ, instead. Then PCM core will call :c:func:`synchronize_irq()` with the given IRQ appropriately. -If the IRQ handler is released at the card destructor, you don't need +If the IRQ handler is released by the card destructor, you don't need to clear ``card->sync_irq``, as the card itself is being released. So, usually you'll need to add just a single line for assigning ``card->sync_irq`` in the driver code unless the driver re-acquires @@ -2103,30 +2007,30 @@ pointer callback static snd_pcm_uframes_t snd_xxx_pointer(struct snd_pcm_substream *substream) This callback is called when the PCM middle layer inquires the current -hardware position on the buffer. The position must be returned in +hardware position in the buffer. The position must be returned in frames, ranging from 0 to ``buffer_size - 1``. -This is called usually from the buffer-update routine in the pcm +This is usually called from the buffer-update routine in the PCM middle layer, which is invoked when :c:func:`snd_pcm_period_elapsed()` -is called in the interrupt routine. Then the pcm middle layer updates +is called by the interrupt routine. Then the PCM middle layer updates the position and calculates the available space, and wakes up the sleeping poll threads, etc. -This callback is also atomic as default. +This callback is also atomic by default. copy_user, copy_kernel and fill_silence ops ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ These callbacks are not mandatory, and can be omitted in most cases. These callbacks are used when the hardware buffer cannot be in the -normal memory space. Some chips have their own buffer on the hardware +normal memory space. Some chips have their own buffer in the hardware which is not mappable. In such a case, you have to transfer the data manually from the memory buffer to the hardware buffer. Or, if the buffer is non-contiguous on both physical and virtual memory spaces, these callbacks must be defined, too. If these two callbacks are defined, copy and set-silence operations -are done by them. The detailed will be described in the later section +are done by them. The details will be described in the later section `Buffer and Memory Management`_. ack callback @@ -2137,7 +2041,11 @@ This callback is also not mandatory. This callback is called when the emu10k1-fx and cs46xx need to track the current ``appl_ptr`` for the internal buffer, and this callback is useful only for such a purpose. -This callback is atomic as default. +The callback function may return 0 or a negative error. When the +return value is ``-EPIPE``, PCM core treats that as a buffer XRUN, +and changes the state to ``SNDRV_PCM_STATE_XRUN`` automatically. + +This callback is atomic by default. page callback ~~~~~~~~~~~~~ @@ -2145,16 +2053,15 @@ page callback This callback is optional too. The mmap calls this callback to get the page fault address. -Since the recent changes, you need no special callback any longer for -the standard SG-buffer or vmalloc-buffer. Hence this callback should -be rarely used. +You need no special callback for the standard SG-buffer or vmalloc- +buffer. Hence this callback should be rarely used. -mmap calllback -~~~~~~~~~~~~~~ +mmap callback +~~~~~~~~~~~~~ This is another optional callback for controlling mmap behavior. -Once when defined, PCM core calls this callback when a page is -memory-mapped instead of dealing via the standard helper. +When defined, the PCM core calls this callback when a page is +memory-mapped, instead of using the standard helper. If you need special handling (due to some architecture or device-specific issues), implement everything here as you like. @@ -2162,13 +2069,14 @@ device-specific issues), implement everything here as you like. PCM Interrupt Handler --------------------- -The rest of pcm stuff is the PCM interrupt handler. The role of PCM +The remainder of the PCM stuff is the PCM interrupt handler. The role +of the PCM interrupt handler in the sound driver is to update the buffer position and to tell the PCM middle layer when the buffer position goes across -the prescribed period size. To inform this, call the +the specified period boundary. To inform about this, call the :c:func:`snd_pcm_period_elapsed()` function. -There are several types of sound chips to generate the interrupts. +There are several ways sound chips can generate interrupts. Interrupts at the period (fragment) boundary ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2184,14 +2092,12 @@ chip record to hold the current running substream pointer, and set the pointer value at ``open`` callback (and reset at ``close`` callback). If you acquire a spinlock in the interrupt handler, and the lock is used -in other pcm callbacks, too, then you have to release the lock before +in other PCM callbacks, too, then you have to release the lock before calling :c:func:`snd_pcm_period_elapsed()`, because -:c:func:`snd_pcm_period_elapsed()` calls other pcm callbacks +:c:func:`snd_pcm_period_elapsed()` calls other PCM callbacks inside. -Typical code would be like: - -:: +Typical code would look like:: static irqreturn_t snd_mychip_interrupt(int irq, void *dev_id) @@ -2211,6 +2117,12 @@ Typical code would be like: return IRQ_HANDLED; } +Also, when the device can detect a buffer underrun/overrun, the driver +can notify the XRUN status to the PCM core by calling +:c:func:`snd_pcm_stop_xrun()`. This function stops the stream and sets +the PCM state to ``SNDRV_PCM_STATE_XRUN``. Note that it must be called +outside the PCM stream lock, hence it can't be called from the atomic +callback. High frequency timer interrupts @@ -2223,9 +2135,7 @@ position and accumulate the processed sample length at each interrupt. When the accumulated size exceeds the period size, call :c:func:`snd_pcm_period_elapsed()` and reset the accumulator. -Typical code would be like the following. - -:: +Typical code would look as follows:: static irqreturn_t snd_mychip_interrupt(int irq, void *dev_id) @@ -2270,9 +2180,9 @@ Typical code would be like the following. On calling :c:func:`snd_pcm_period_elapsed()` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In both cases, even if more than one period are elapsed, you don't have +In both cases, even if more than one period has elapsed, you don't have to call :c:func:`snd_pcm_period_elapsed()` many times. Call only -once. And the pcm layer will check the current hardware pointer and +once. And the PCM layer will check the current hardware pointer and update to the latest status. Atomicity @@ -2283,15 +2193,16 @@ kernel programming are race conditions. In the Linux kernel, they are usually avoided via spin-locks, mutexes or semaphores. In general, if a race condition can happen in an interrupt handler, it has to be managed atomically, and you have to use a spinlock to protect the critical -session. If the critical section is not in interrupt handler code and if +section. If the critical section is not in interrupt handler code and if taking a relatively long time to execute is acceptable, you should use mutexes or semaphores instead. -As already seen, some pcm callbacks are atomic and some are not. For -example, the ``hw_params`` callback is non-atomic, while ``trigger`` +As already seen, some PCM callbacks are atomic and some are not. For +example, the ``hw_params`` callback is non-atomic, while the ``trigger`` callback is atomic. This means, the latter is called already in a -spinlock held by the PCM middle layer. Please take this atomicity into -account when you choose a locking scheme in the callbacks. +spinlock held by the PCM middle layer, the PCM stream lock. Please +take this atomicity into account when you choose a locking scheme in +the callbacks. In the atomic callbacks, you cannot use functions which may call :c:func:`schedule()` or go to :c:func:`sleep()`. Semaphores and @@ -2302,29 +2213,34 @@ callback, please use :c:func:`udelay()` or :c:func:`mdelay()`. All three atomic callbacks (trigger, pointer, and ack) are called with local interrupts disabled. -The recent changes in PCM core code, however, allow all PCM operations -to be non-atomic. This assumes that the all caller sides are in +However, it is possible to request all PCM operations to be non-atomic. +This assumes that all call sites are in non-atomic contexts. For example, the function :c:func:`snd_pcm_period_elapsed()` is called typically from the interrupt handler. But, if you set up the driver to use a threaded interrupt handler, this call can be in non-atomic context, too. In such -a case, you can set ``nonatomic`` filed of struct snd_pcm object +a case, you can set the ``nonatomic`` field of the struct snd_pcm object after creating it. When this flag is set, mutex and rwsem are used internally in the PCM core instead of spin and rwlocks, so that you can call all PCM functions safely in a non-atomic context. +Also, in some cases, you might need to call +:c:func:`snd_pcm_period_elapsed()` in the atomic context (e.g. the +period gets elapsed during ``ack`` or other callback). There is a +variant that can be called inside the PCM stream lock +:c:func:`snd_pcm_period_elapsed_under_stream_lock()` for that purpose, +too. + Constraints ----------- -If your chip supports unconventional sample rates, or only the limited -samples, you need to set a constraint for the condition. +Due to physical limitations, hardware is not infinitely configurable. +These limitations are expressed by setting constraints. -For example, in order to restrict the sample rates in the some supported +For example, in order to restrict the sample rates to some supported values, use :c:func:`snd_pcm_hw_constraint_list()`. You need to -call this function in the open callback. - -:: +call this function in the open callback:: static unsigned int rates[] = {4000, 10000, 22050, 44100}; @@ -2346,16 +2262,12 @@ call this function in the open callback. .... } - - There are many different constraints. Look at ``sound/pcm.h`` for a complete list. You can even define your own constraint rules. For example, let's suppose my_chip can manage a substream of 1 channel if and only if the format is ``S16_LE``, otherwise it supports any format -specified in struct snd_pcm_hardware> (or in any other -constraint_list). You can build a rule like this: - -:: +specified in struct snd_pcm_hardware (or in any other +constraint_list). You can build a rule like this:: static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params, struct snd_pcm_hw_rule *rule) @@ -2375,9 +2287,7 @@ constraint_list). You can build a rule like this: } -Then you need to call this function to add your rule: - -:: +Then you need to call this function to add your rule:: snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS, hw_rule_channels_by_format, NULL, @@ -2386,9 +2296,7 @@ Then you need to call this function to add your rule: The rule function is called when an application sets the PCM format, and it refines the number of channels accordingly. But an application may set the number of channels before setting the format. Thus you also need -to define the inverse rule: - -:: +to define the inverse rule:: static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params, struct snd_pcm_hw_rule *rule) @@ -2407,16 +2315,14 @@ to define the inverse rule: } -... and in the open callback: - -:: +... and in the open callback:: snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_FORMAT, hw_rule_format_by_channels, NULL, SNDRV_PCM_HW_PARAM_CHANNELS, -1); One typical usage of the hw constraints is to align the buffer size -with the period size. As default, ALSA PCM core doesn't enforce the +with the period size. By default, ALSA PCM core doesn't enforce the buffer size to be aligned with the period size. For example, it'd be possible to have a combination like 256 period bytes with 999 buffer bytes. @@ -2424,9 +2330,7 @@ bytes. Many device chips, however, require the buffer to be a multiple of periods. In such a case, call :c:func:`snd_pcm_hw_constraint_integer()` for -``SNDRV_PCM_HW_PARAM_PERIODS``. - -:: +``SNDRV_PCM_HW_PARAM_PERIODS``:: snd_pcm_hw_constraint_integer(substream->runtime, SNDRV_PCM_HW_PARAM_PERIODS); @@ -2434,7 +2338,7 @@ periods. In such a case, call This assures that the number of periods is integer, hence the buffer size is aligned with the period size. -The hw constraint is a very much powerful mechanism to define the +The hw constraint is a very powerful mechanism to define the preferred PCM configuration, and there are relevant helpers. I won't give more details here, rather I would like to say, “Luke, use the source.†@@ -2461,9 +2365,7 @@ Definition of Controls To create a new control, you need to define the following three callbacks: ``info``, ``get`` and ``put``. Then, define a -struct snd_kcontrol_new record, such as: - -:: +struct snd_kcontrol_new record, such as:: static struct snd_kcontrol_new my_control = { @@ -2506,7 +2408,7 @@ The ``private_value`` field contains an arbitrary long integer value for this record. When using the generic ``info``, ``get`` and ``put`` callbacks, you can pass a value through this field. If several small numbers are necessary, you can combine them in bitwise. Or, it's -possible to give a pointer (casted to unsigned long) of some record to +possible to store a pointer (casted to unsigned long) of some record in this field, too. The ``tlv`` field can be used to provide metadata about the control; @@ -2573,7 +2475,7 @@ The access flag is the bitmask which specifies the access type of the given control. The default access type is ``SNDRV_CTL_ELEM_ACCESS_READWRITE``, which means both read and write are allowed to this control. When the access flag is omitted (i.e. = 0), it -is considered as ``READWRITE`` access as default. +is considered as ``READWRITE`` access by default. When the control is read-only, pass ``SNDRV_CTL_ELEM_ACCESS_READ`` instead. In this case, you don't have to define the ``put`` callback. @@ -2586,8 +2488,11 @@ If the control value changes frequently (e.g. the VU meter), changed without `Change notification`_. Applications should poll such a control constantly. -When the control is inactive, set the ``INACTIVE`` flag, too. There are -``LOCK`` and ``OWNER`` flags to change the write permissions. +When the control may be updated, but currently has no effect on anything, +setting the ``INACTIVE`` flag may be appropriate. For example, PCM +controls should be inactive while no PCM device is open. + +There are ``LOCK`` and ``OWNER`` flags to change the write permissions. Control Callbacks ----------------- @@ -2598,9 +2503,7 @@ info callback The ``info`` callback is used to get detailed information on this control. This must store the values of the given struct snd_ctl_elem_info object. For example, -for a boolean control with a single element: - -:: +for a boolean control with a single element:: static int snd_myctl_mono_info(struct snd_kcontrol *kcontrol, @@ -2619,13 +2522,11 @@ The ``type`` field specifies the type of the control. There are ``BOOLEAN``, ``INTEGER``, ``ENUMERATED``, ``BYTES``, ``IEC958`` and ``INTEGER64``. The ``count`` field specifies the number of elements in this control. For example, a stereo volume would have count = 2. The -``value`` field is a union, and the values stored are depending on the +``value`` field is a union, and the values stored depend on the type. The boolean and integer types are identical. -The enumerated type is a bit different from others. You'll need to set -the string for the currently given item index. - -:: +The enumerated type is a bit different from the others. You'll need to +set the string for the selectec item index:: static int snd_myctl_enum_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo) @@ -2670,13 +2571,10 @@ stereo channel boolean item. get callback ~~~~~~~~~~~~ -This callback is used to read the current value of the control and to -return to user-space. - -For example, - -:: +This callback is used to read the current value of the control, so it +can be returned to user-space. +For example:: static int snd_myctl_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) @@ -2691,15 +2589,11 @@ For example, The ``value`` field depends on the type of control as well as on the info callback. For example, the sb driver uses this field to store the register offset, the bit-shift and the bit-mask. The ``private_value`` -field is set as follows: - -:: +field is set as follows:: .private_value = reg | (shift << 16) | (mask << 24) -and is retrieved in callbacks like - -:: +and is retrieved in callbacks like:: static int snd_sbmixer_get_single(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) @@ -2711,19 +2605,16 @@ and is retrieved in callbacks like } In the ``get`` callback, you have to fill all the elements if the -control has more than one elements, i.e. ``count > 1``. In the example +control has more than one element, i.e. ``count > 1``. In the example above, we filled only one element (``value.integer.value[0]``) since -it's assumed as ``count = 1``. +``count = 1`` is assumed. put callback ~~~~~~~~~~~~ -This callback is used to write a value from user-space. - -For example, - -:: +This callback is used to write a value coming from user-space. +For example:: static int snd_myctl_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) @@ -2746,12 +2637,12 @@ value is not changed, return 0 instead. If any fatal error happens, return a negative error code as usual. As in the ``get`` callback, when the control has more than one -elements, all elements must be evaluated in this callback, too. +element, all elements must be evaluated in this callback, too. Callbacks are not atomic ~~~~~~~~~~~~~~~~~~~~~~~~ -All these three callbacks are basically not atomic. +All these three callbacks are not-atomic. Control Constructor ------------------- @@ -2760,9 +2651,7 @@ When everything is ready, finally we can create a new control. To create a control, there are two functions to be called, :c:func:`snd_ctl_new1()` and :c:func:`snd_ctl_add()`. -In the simplest way, you can do like this: - -:: +In the simplest way, you can do it like this:: err = snd_ctl_add(card, snd_ctl_new1(&my_control, chip)); if (err < 0) @@ -2780,9 +2669,7 @@ Change Notification ------------------- If you need to change and update a control in the interrupt routine, you -can call :c:func:`snd_ctl_notify()`. For example, - -:: +can call :c:func:`snd_ctl_notify()`. For example:: snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_VALUE, id_pointer); @@ -2796,13 +2683,11 @@ for hardware volume interrupts. Metadata -------- -To provide information about the dB values of a mixer control, use on of +To provide information about the dB values of a mixer control, use one of the ``DECLARE_TLV_xxx`` macros from ``<sound/tlv.h>`` to define a variable containing this information, set the ``tlv.p`` field to point to this variable, and include the ``SNDRV_CTL_ELEM_ACCESS_TLV_READ`` flag -in the ``access`` field; like this: - -:: +in the ``access`` field; like this:: static DECLARE_TLV_DB_SCALE(db_scale_my_control, -4050, 150, 0); @@ -2892,9 +2777,7 @@ AC97 Constructor ---------------- To create an ac97 instance, first call :c:func:`snd_ac97_bus()` -with an ``ac97_bus_ops_t`` record with callback functions. - -:: +with an ``ac97_bus_ops_t`` record with callback functions:: struct snd_ac97_bus *bus; static struct snd_ac97_bus_ops ops = { @@ -2906,10 +2789,8 @@ with an ``ac97_bus_ops_t`` record with callback functions. The bus record is shared among all belonging ac97 instances. -And then call :c:func:`snd_ac97_mixer()` with an struct snd_ac97_template -record together with the bus pointer created above. - -:: +And then call :c:func:`snd_ac97_mixer()` with a struct snd_ac97_template +record together with the bus pointer created above:: struct snd_ac97_template ac97; int err; @@ -2934,9 +2815,7 @@ correspond to the functions for read and write accesses to the hardware low-level codes. The ``read`` callback returns the register value specified in the -argument. - -:: +argument:: static unsigned short snd_mychip_ac97_read(struct snd_ac97 *ac97, unsigned short reg) @@ -2949,9 +2828,7 @@ argument. Here, the chip can be cast from ``ac97->private_data``. Meanwhile, the ``write`` callback is used to set the register -value - -:: +value:: static void snd_mychip_ac97_write(struct snd_ac97 *ac97, unsigned short reg, unsigned short val) @@ -2984,32 +2861,24 @@ Both :c:func:`snd_ac97_write()` and the given register (``AC97_XXX``). The difference between them is that :c:func:`snd_ac97_update()` doesn't write a value if the given value has been already set, while :c:func:`snd_ac97_write()` -always rewrites the value. - -:: +always rewrites the value:: snd_ac97_write(ac97, AC97_MASTER, 0x8080); snd_ac97_update(ac97, AC97_MASTER, 0x8080); :c:func:`snd_ac97_read()` is used to read the value of the given -register. For example, - -:: +register. For example:: value = snd_ac97_read(ac97, AC97_MASTER); :c:func:`snd_ac97_update_bits()` is used to update some bits in -the given register. - -:: +the given register:: snd_ac97_update_bits(ac97, reg, mask, value); Also, there is a function to change the sample rate (of a given register such as ``AC97_PCM_FRONT_DAC_RATE``) when VRA or DRA is supported by the -codec: :c:func:`snd_ac97_set_rate()`. - -:: +codec: :c:func:`snd_ac97_set_rate()`:: snd_ac97_set_rate(ac97, AC97_PCM_FRONT_DAC_RATE, 44100); @@ -3064,9 +2933,7 @@ mpu401 stuff. For example, emu10k1 has its own mpu401 routines. MIDI Constructor ---------------- -To create a rawmidi object, call :c:func:`snd_mpu401_uart_new()`. - -:: +To create a rawmidi object, call :c:func:`snd_mpu401_uart_new()`:: struct snd_rawmidi *rmidi; snd_mpu401_uart_new(card, 0, MPU401_HW_MPU401, port, info_flags, @@ -3111,16 +2978,12 @@ corresponds to the data port. If not, you may change the ``cport`` field of struct snd_mpu401 manually afterward. However, struct snd_mpu401 pointer is not returned explicitly by :c:func:`snd_mpu401_uart_new()`. You -need to cast ``rmidi->private_data`` to struct snd_mpu401 explicitly, - -:: +need to cast ``rmidi->private_data`` to struct snd_mpu401 explicitly:: struct snd_mpu401 *mpu; mpu = rmidi->private_data; -and reset the ``cport`` as you like: - -:: +and reset the ``cport`` as you like:: mpu->cport = my_own_control_port; @@ -3144,9 +3007,7 @@ occurred. In this case, you need to pass the private_data of the returned rawmidi object from :c:func:`snd_mpu401_uart_new()` as the second -argument of :c:func:`snd_mpu401_uart_interrupt()`. - -:: +argument of :c:func:`snd_mpu401_uart_interrupt()`:: snd_mpu401_uart_interrupt(irq, rmidi->private_data, regs); @@ -3170,9 +3031,7 @@ RawMIDI Constructor ------------------- To create a rawmidi device, call the :c:func:`snd_rawmidi_new()` -function: - -:: +function:: struct snd_rawmidi *rmidi; err = snd_rawmidi_new(chip->card, "MyMIDI", 0, outs, ins, &rmidi); @@ -3202,16 +3061,12 @@ output and input at the same time. After the rawmidi device is created, you need to set the operators (callbacks) for each substream. There are helper functions to set the -operators for all the substreams of a device: - -:: +operators for all the substreams of a device:: snd_rawmidi_set_ops(rmidi, SNDRV_RAWMIDI_STREAM_OUTPUT, &snd_mymidi_output_ops); snd_rawmidi_set_ops(rmidi, SNDRV_RAWMIDI_STREAM_INPUT, &snd_mymidi_input_ops); -The operators are usually defined like this: - -:: +The operators are usually defined like this:: static struct snd_rawmidi_ops snd_mymidi_output_ops = { .open = snd_mymidi_output_open, @@ -3222,9 +3077,7 @@ The operators are usually defined like this: These callbacks are explained in the `RawMIDI Callbacks`_ section. If there are more than one substream, you should give a unique name to -each of them: - -:: +each of them:: struct snd_rawmidi_substream *substream; list_for_each_entry(substream, @@ -3242,9 +3095,7 @@ device can be accessed as ``substream->rmidi->private_data``. If there is more than one port, your callbacks can determine the port index from the struct snd_rawmidi_substream data passed to each -callback: - -:: +callback:: struct snd_rawmidi_substream *substream; int index = substream->number; @@ -3289,9 +3140,7 @@ of bytes that have been read; this will be less than the number of bytes requested when there are no more data in the buffer. After the data have been transmitted successfully, call :c:func:`snd_rawmidi_transmit_ack()` to remove the data from the -substream buffer: - -:: +substream buffer:: unsigned char data; while (snd_rawmidi_transmit_peek(substream, &data, 1) == 1) { @@ -3303,9 +3152,7 @@ substream buffer: If you know beforehand that the hardware will accept data, you can use the :c:func:`snd_rawmidi_transmit()` function which reads some -data and removes them from the buffer at once: - -:: +data and removes them from the buffer at once:: while (snd_mychip_transmit_possible()) { unsigned char data; @@ -3340,9 +3187,7 @@ The ``trigger`` callback must not sleep; the actual reading of data from the device is usually done in an interrupt handler. When data reception is enabled, your interrupt handler should call -:c:func:`snd_rawmidi_receive()` for all received data: - -:: +:c:func:`snd_rawmidi_receive()` for all received data:: void snd_mychip_midi_interrupt(...) { @@ -3388,9 +3233,7 @@ whereas in OSS compatible mode, FM registers can be accessed with the OSS direct-FM compatible API in ``/dev/dmfmX`` device. To create the OPL3 component, you have two functions to call. The first -one is a constructor for the ``opl3_t`` instance. - -:: +one is a constructor for the ``opl3_t`` instance:: struct snd_opl3 *opl3; snd_opl3_create(card, lport, rport, OPL3_HW_OPL3_XXX, @@ -3408,9 +3251,7 @@ the opl3 module will allocate the specified ports by itself. When the accessing the hardware requires special method instead of the standard I/O access, you can create opl3 instance separately with -:c:func:`snd_opl3_new()`. - -:: +:c:func:`snd_opl3_new()`:: struct snd_opl3 *opl3; snd_opl3_new(card, OPL3_HW_OPL3_XXX, &opl3); @@ -3427,9 +3268,7 @@ proper state. Note that :c:func:`snd_opl3_create()` always calls it internally. If the opl3 instance is created successfully, then create a hwdep device -for this opl3. - -:: +for this opl3:: struct snd_hwdep *opl3hwdep; snd_opl3_hwdep_new(opl3, 0, 1, &opl3hwdep); @@ -3451,9 +3290,7 @@ the micro code. In such a case, you can create a hwdep ``isa/sb/sb16_csp.c``. The creation of the ``hwdep`` instance is done via -:c:func:`snd_hwdep_new()`. - -:: +:c:func:`snd_hwdep_new()`:: struct snd_hwdep *hw; snd_hwdep_new(card, "My HWDEP", 0, &hw); @@ -3461,18 +3298,14 @@ The creation of the ``hwdep`` instance is done via where the third argument is the index number. You can then pass any pointer value to the ``private_data``. If you -assign a private data, you should define the destructor, too. The -destructor function is set in the ``private_free`` field. - -:: +assign private data, you should define a destructor, too. The +destructor function is set in the ``private_free`` field:: struct mydata *p = kmalloc(sizeof(*p), GFP_KERNEL); hw->private_data = p; hw->private_free = mydata_free; -and the implementation of the destructor would be: - -:: +and the implementation of the destructor would be:: static void mydata_free(struct snd_hwdep *hw) { @@ -3482,9 +3315,7 @@ and the implementation of the destructor would be: The arbitrary file operations can be defined for this instance. The file operators are defined in the ``ops`` table. For example, assume that -this chip needs an ioctl. - -:: +this chip needs an ioctl:: hw->ops.open = mydata_open; hw->ops.ioctl = mydata_ioctl; @@ -3534,31 +3365,30 @@ Buffer Types ALSA provides several different buffer allocation functions depending on the bus and the architecture. All these have a consistent API. The -allocation of physically-contiguous pages is done via +allocation of physically-contiguous pages is done via the :c:func:`snd_malloc_xxx_pages()` function, where xxx is the bus type. -The allocation of pages with fallback is -:c:func:`snd_malloc_xxx_pages_fallback()`. This function tries -to allocate the specified pages but if the pages are not available, it -tries to reduce the page sizes until enough space is found. +The allocation of pages with fallback is done via +:c:func:`snd_dma_alloc_pages_fallback()`. This function tries +to allocate the specified number of pages, but if not enough pages are +available, it tries to reduce the request size until enough space +is found, down to one page. -The release the pages, call :c:func:`snd_free_xxx_pages()` +To release the pages, call the :c:func:`snd_dma_free_pages()` function. Usually, ALSA drivers try to allocate and reserve a large contiguous -physical space at the time the module is loaded for the later use. This +physical space at the time the module is loaded for later use. This is called “pre-allocationâ€. As already written, you can call the -following function at pcm instance construction time (in the case of PCI -bus). - -:: +following function at PCM instance construction time (in the case of PCI +bus):: snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV, &pci->dev, size, max); -where ``size`` is the byte size to be pre-allocated and the ``max`` is -the maximum size to be changed via the ``prealloc`` proc file. The +where ``size`` is the byte size to be pre-allocated and ``max`` is +the maximum size settable via the ``prealloc`` proc file. The allocator will try to get an area as large as possible within the given size. @@ -3567,10 +3397,10 @@ dependent on the bus. For normal devices, pass the device pointer (typically identical as ``card->dev``) to the third argument with ``SNDRV_DMA_TYPE_DEV`` type. -For the continuous buffer unrelated to the +A continuous buffer unrelated to the bus can be pre-allocated with ``SNDRV_DMA_TYPE_CONTINUOUS`` type. You can pass NULL to the device pointer in that case, which is the -default mode implying to allocate with ``GFP_KERNEL`` flag. +default mode implying to allocate with the ``GFP_KERNEL`` flag. If you need a restricted (lower) address, set up the coherent DMA mask bits for the device, and pass the device pointer, like the normal device memory allocations. For this type, it's still allowed to pass @@ -3580,37 +3410,33 @@ For the scatter-gather buffers, use ``SNDRV_DMA_TYPE_DEV_SG`` with the device pointer (see the `Non-Contiguous Buffers`_ section). Once the buffer is pre-allocated, you can use the allocator in the -``hw_params`` callback: - -:: +``hw_params`` callback:: snd_pcm_lib_malloc_pages(substream, size); Note that you have to pre-allocate to use this function. -Most of drivers use, though, rather the newly introduced "managed -buffer allocation mode" instead of the manual allocation or release. +But most drivers use the "managed buffer allocation mode" instead +of manual allocation and release. This is done by calling :c:func:`snd_pcm_set_managed_buffer_all()` -instead of :c:func:`snd_pcm_lib_preallocate_pages_for_all()`. - -:: +instead of :c:func:`snd_pcm_lib_preallocate_pages_for_all()`:: snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_DEV, &pci->dev, size, max); -where passed arguments are identical in both functions. +where the passed arguments are identical for both functions. The difference in the managed mode is that PCM core will call :c:func:`snd_pcm_lib_malloc_pages()` internally already before calling the PCM ``hw_params`` callback, and call :c:func:`snd_pcm_lib_free_pages()` after the PCM ``hw_free`` callback automatically. So the driver doesn't have to call these functions explicitly in its callback any -longer. This made many driver code having NULL ``hw_params`` and +longer. This allows many drivers to have NULL ``hw_params`` and ``hw_free`` entries. External Hardware Buffers ------------------------- -Some chips have their own hardware buffers and the DMA transfer from the +Some chips have their own hardware buffers and DMA transfer from the host memory is not available. In such a case, you need to either 1) copy/set the audio data directly to the external hardware buffer, or 2) make an intermediate buffer and copy/set the data from it to the @@ -3618,8 +3444,8 @@ external hardware buffer in interrupts (or in tasklets, preferably). The first case works fine if the external hardware buffer is large enough. This method doesn't need any extra buffers and thus is more -effective. You need to define the ``copy_user`` and ``copy_kernel`` -callbacks for the data transfer, in addition to ``fill_silence`` +efficient. You need to define the ``copy_user`` and ``copy_kernel`` +callbacks for the data transfer, in addition to the ``fill_silence`` callback for playback. However, there is a drawback: it cannot be mmapped. The examples are GUS's GF1 PCM or emu8000's wavetable PCM. @@ -3633,16 +3459,14 @@ buffer instead of the host memory. In this case, mmap is available only on certain architectures like the Intel one. In non-mmap mode, the data cannot be transferred as in the normal way. Thus you need to define the ``copy_user``, ``copy_kernel`` and ``fill_silence`` callbacks as well, -as in the cases above. The examples are found in ``rme32.c`` and +as in the cases above. Examples are found in ``rme32.c`` and ``rme96.c``. The implementation of the ``copy_user``, ``copy_kernel`` and ``silence`` callbacks depends upon whether the hardware supports interleaved or non-interleaved samples. The ``copy_user`` callback is -defined like below, a bit differently depending whether the direction -is playback or capture: - -:: +defined like below, a bit differently depending on whether the direction +is playback or capture:: static int playback_copy_user(struct snd_pcm_substream *substream, int channel, unsigned long pos, @@ -3652,8 +3476,7 @@ is playback or capture: void __user *dst, unsigned long count); In the case of interleaved samples, the second argument (``channel``) is -not used. The third argument (``pos``) points the current position -offset in bytes. +not used. The third argument (``pos``) specifies the position in bytes. The meaning of the fourth argument is different between playback and capture. For playback, it holds the source data pointer, and for @@ -3664,49 +3487,42 @@ The last argument is the number of bytes to be copied. What you have to do in this callback is again different between playback and capture directions. In the playback case, you copy the given amount of data (``count``) at the specified pointer (``src``) to the specified -offset (``pos``) on the hardware buffer. When coded like memcpy-like -way, the copy would be like: - -:: +offset (``pos``) in the hardware buffer. When coded like memcpy-like +way, the copy would look like:: my_memcpy_from_user(my_buffer + pos, src, count); For the capture direction, you copy the given amount of data (``count``) -at the specified offset (``pos``) on the hardware buffer to the -specified pointer (``dst``). - -:: +at the specified offset (``pos``) in the hardware buffer to the +specified pointer (``dst``):: my_memcpy_to_user(dst, my_buffer + pos, count); -Here the functions are named as ``from_user`` and ``to_user`` because +Here the functions are named ``from_user`` and ``to_user`` because it's the user-space buffer that is passed to these callbacks. That -is, the callback is supposed to copy from/to the user-space data +is, the callback is supposed to copy data from/to the user-space directly to/from the hardware buffer. Careful readers might notice that these callbacks receive the arguments in bytes, not in frames like other callbacks. It's because -it would make coding easier like the examples above, and also it makes -easier to unify both the interleaved and non-interleaved cases, as -explained in the following. +this makes coding easier like in the examples above, and also it makes +it easier to unify both the interleaved and non-interleaved cases, as +explained below. In the case of non-interleaved samples, the implementation will be a bit -more complicated. The callback is called for each channel, passed by -the second argument, so totally it's called for N-channels times per -transfer. - -The meaning of other arguments are almost same as the interleaved -case. The callback is supposed to copy the data from/to the given -user-space buffer, but only for the given channel. For the detailed -implementations, please check ``isa/gus/gus_pcm.c`` or -"pci/rme9652/rme9652.c" as examples. +more complicated. The callback is called for each channel, passed in +the second argument, so in total it's called N times per transfer. -The above callbacks are the copy from/to the user-space buffer. There -are some cases where we want copy from/to the kernel-space buffer -instead. In such a case, ``copy_kernel`` callback is called. It'd -look like: +The meaning of the other arguments are almost the same as in the +interleaved case. The callback is supposed to copy the data from/to +the given user-space buffer, but only for the given channel. For +details, please check ``isa/gus/gus_pcm.c`` or ``pci/rme9652/rme9652.c`` +as examples. -:: +The above callbacks are the copies from/to the user-space buffer. There +are some cases where we want to copy from/to the kernel-space buffer +instead. In such a case, the ``copy_kernel`` callback is called. It'd +look like:: static int playback_copy_kernel(struct snd_pcm_substream *substream, int channel, unsigned long pos, @@ -3716,19 +3532,15 @@ look like: void *dst, unsigned long count); As found easily, the only difference is that the buffer pointer is -without ``__user`` prefix; that is, a kernel-buffer pointer is passed +without a ``__user`` prefix; that is, a kernel-buffer pointer is passed in the fourth argument. Correspondingly, the implementation would be -a version without the user-copy, such as: - -:: +a version without the user-copy, such as:: my_memcpy(my_buffer + pos, src, count); Usually for the playback, another callback ``fill_silence`` is defined. It's implemented in a similar way as the copy callbacks -above: - -:: +above:: static int silence(struct snd_pcm_substream *substream, int channel, unsigned long pos, unsigned long count); @@ -3736,54 +3548,47 @@ above: The meanings of arguments are the same as in the ``copy_user`` and ``copy_kernel`` callbacks, although there is no buffer pointer argument. In the case of interleaved samples, the channel argument has -no meaning, as well as on ``copy_*`` callbacks. +no meaning, as for the ``copy_*`` callbacks. -The role of ``fill_silence`` callback is to set the given amount -(``count``) of silence data at the specified offset (``pos``) on the +The role of the ``fill_silence`` callback is to set the given amount +(``count``) of silence data at the specified offset (``pos``) in the hardware buffer. Suppose that the data format is signed (that is, the silent-data is 0), and the implementation using a memset-like function -would be like: - -:: +would look like:: my_memset(my_buffer + pos, 0, count); In the case of non-interleaved samples, again, the implementation -becomes a bit more complicated, as it's called N-times per transfer +becomes a bit more complicated, as it's called N times per transfer for each channel. See, for example, ``isa/gus/gus_pcm.c``. Non-Contiguous Buffers ---------------------- -If your hardware supports the page table as in emu10k1 or the buffer -descriptors as in via82xx, you can use the scatter-gather (SG) DMA. ALSA +If your hardware supports a page table as in emu10k1 or buffer +descriptors as in via82xx, you can use scatter-gather (SG) DMA. ALSA provides an interface for handling SG-buffers. The API is provided in ``<sound/pcm.h>``. For creating the SG-buffer handler, call :c:func:`snd_pcm_set_managed_buffer()` or :c:func:`snd_pcm_set_managed_buffer_all()` with -``SNDRV_DMA_TYPE_DEV_SG`` in the PCM constructor like other PCI -pre-allocator. You need to pass ``&pci->dev``, where pci is -the struct pci_dev pointer of the chip as -well. - -:: +``SNDRV_DMA_TYPE_DEV_SG`` in the PCM constructor like for other PCI +pre-allocations. You need to pass ``&pci->dev``, where pci is +the struct pci_dev pointer of the chip as well:: snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_DEV_SG, &pci->dev, size, max); The ``struct snd_sg_buf`` instance is created as -``substream->dma_private`` in turn. You can cast the pointer like: - -:: +``substream->dma_private`` in turn. You can cast the pointer like:: struct snd_sg_buf *sgbuf = (struct snd_sg_buf *)substream->dma_private; -Then in :c:func:`snd_pcm_lib_malloc_pages()` call, the common SG-buffer +Then in the :c:func:`snd_pcm_lib_malloc_pages()` call, the common SG-buffer handler will allocate the non-contiguous kernel pages of the given size -and map them onto the virtually contiguous memory. The virtual pointer -is addressed in runtime->dma_area. The physical address +and map them as virtually contiguous memory. The virtual pointer +is addressed via runtime->dma_area. The physical address (``runtime->dma_addr``) is set to zero, because the buffer is physically non-contiguous. The physical address table is set up in ``sgbuf->table``. You can get the physical address at a certain offset @@ -3796,22 +3601,20 @@ Vmalloc'ed Buffers ------------------ It's possible to use a buffer allocated via :c:func:`vmalloc()`, for -example, for an intermediate buffer. In the recent version of kernel, -you can simply allocate it via standard -:c:func:`snd_pcm_lib_malloc_pages()` and co after setting up the -buffer preallocation with ``SNDRV_DMA_TYPE_VMALLOC`` type. - -:: +example, for an intermediate buffer. +You can simply allocate it via the standard +:c:func:`snd_pcm_lib_malloc_pages()` and co. after setting up the +buffer preallocation with ``SNDRV_DMA_TYPE_VMALLOC`` type:: snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_VMALLOC, NULL, 0, 0); -The NULL is passed to the device pointer argument, which indicates -that the default pages (GFP_KERNEL and GFP_HIGHMEM) will be +NULL is passed as the device pointer argument, which indicates +that default pages (GFP_KERNEL and GFP_HIGHMEM) will be allocated. -Also, note that zero is passed to both the size and the max size -arguments here. Since each vmalloc call should succeed at any time, +Also, note that zero is passed as both the size and the max size +argument here. Since each vmalloc call should succeed at any time, we don't need to pre-allocate the buffers like other continuous pages. @@ -3823,9 +3626,7 @@ useful for debugging. I recommend you set up proc files if you write a driver and want to get a running status or register dumps. The API is found in ``<sound/info.h>``. -To create a proc file, call :c:func:`snd_card_proc_new()`. - -:: +To create a proc file, call :c:func:`snd_card_proc_new()`:: struct snd_info_entry *entry; int err = snd_card_proc_new(card, "my-file", &entry); @@ -3841,28 +3642,22 @@ automatically in the card registration and release functions. When the creation is successful, the function stores a new instance in the pointer given in the third argument. It is initialized as a text proc file for read only. To use this proc file as a read-only text file -as it is, set the read callback with a private data via -:c:func:`snd_info_set_text_ops()`. - -:: +as-is, set the read callback with private data via +:c:func:`snd_info_set_text_ops()`:: snd_info_set_text_ops(entry, chip, my_proc_read); where the second argument (``chip``) is the private data to be used in -the callbacks. The third parameter specifies the read buffer size and +the callback. The third parameter specifies the read buffer size and the fourth (``my_proc_read``) is the callback function, which is -defined like - -:: +defined like:: static void my_proc_read(struct snd_info_entry *entry, struct snd_info_buffer *buffer); In the read callback, use :c:func:`snd_iprintf()` for output strings, which works just like normal :c:func:`printf()`. For -example, - -:: +example:: static void my_proc_read(struct snd_info_entry *entry, struct snd_info_buffer *buffer) @@ -3873,28 +3668,22 @@ example, snd_iprintf(buffer, "Port = %ld\n", chip->port); } -The file permissions can be changed afterwards. As default, it's set as +The file permissions can be changed afterwards. By default, they are read only for all users. If you want to add write permission for the -user (root as default), do as follows: - -:: +user (root by default), do as follows:: entry->mode = S_IFREG | S_IRUGO | S_IWUSR; -and set the write buffer size and the callback - -:: +and set the write buffer size and the callback:: entry->c.text.write = my_proc_write; -For the write callback, you can use :c:func:`snd_info_get_line()` +In the write callback, you can use :c:func:`snd_info_get_line()` to get a text line, and :c:func:`snd_info_get_str()` to retrieve a string from the line. Some examples are found in ``core/oss/mixer_oss.c``, core/oss/and ``pcm_oss.c``. -For a raw-data proc-file, set the attributes as follows: - -:: +For a raw-data proc-file, set the attributes as follows:: static const struct snd_info_entry_ops my_file_io_ops = { .read = my_file_io_read, @@ -3906,14 +3695,13 @@ For a raw-data proc-file, set the attributes as follows: entry->size = 4096; entry->mode = S_IFREG | S_IRUGO; -For the raw data, ``size`` field must be set properly. This specifies +For raw data, ``size`` field must be set properly. This specifies the maximum size of the proc file access. The read/write callbacks of raw mode are more direct than the text mode. You need to use a low-level I/O functions such as -:c:func:`copy_from_user()` and :c:func:`copy_to_user()` to transfer the data. - -:: +:c:func:`copy_from_user()` and :c:func:`copy_to_user()` to transfer the +data:: static ssize_t my_file_io_read(struct snd_info_entry *entry, void *file_private_data, @@ -3938,12 +3726,11 @@ Power Management If the chip is supposed to work with suspend/resume functions, you need to add power-management code to the driver. The additional code for power-management should be ifdef-ed with ``CONFIG_PM``, or annotated -with __maybe_unused attribute; otherwise the compiler will complain -you. +with __maybe_unused attribute; otherwise the compiler will complain. If the driver *fully* supports suspend/resume that is, the device can be properly resumed to its state when suspend was called, you can set the -``SNDRV_PCM_INFO_RESUME`` flag in the pcm info field. Usually, this is +``SNDRV_PCM_INFO_RESUME`` flag in the PCM info field. Usually, this is possible when the registers of the chip can be safely saved and restored to RAM. If this is set, the trigger callback is called with ``SNDRV_PCM_TRIGGER_RESUME`` after the resume callback completes. @@ -3953,7 +3740,7 @@ is still possible, it's still worthy to implement suspend/resume callbacks. In such a case, applications would reset the status by calling :c:func:`snd_pcm_prepare()` and restart the stream appropriately. Hence, you can define suspend/resume callbacks below but -don't set ``SNDRV_PCM_INFO_RESUME`` info flag to the PCM. +don't set the ``SNDRV_PCM_INFO_RESUME`` info flag to the PCM. Note that the trigger with SUSPEND can always be called when :c:func:`snd_pcm_suspend_all()` is called, regardless of the @@ -3963,12 +3750,9 @@ behavior of :c:func:`snd_pcm_resume()`. (Thus, in theory, callback when no ``SNDRV_PCM_INFO_RESUME`` flag is set. But, it's better to keep it for compatibility reasons.) -In the earlier version of ALSA drivers, a common power-management layer -was provided, but it has been removed. The driver needs to define the +The driver needs to define the suspend/resume hooks according to the bus the device is connected to. In -the case of PCI drivers, the callbacks look like below: - -:: +the case of PCI drivers, the callbacks look like below:: static int __maybe_unused snd_my_suspend(struct device *dev) { @@ -3981,7 +3765,7 @@ the case of PCI drivers, the callbacks look like below: return 0; } -The scheme of the real suspend job is as follows. +The scheme of the real suspend job is as follows: 1. Retrieve the card and the chip data. @@ -3995,9 +3779,7 @@ The scheme of the real suspend job is as follows. 5. Stop the hardware if necessary. -A typical code would be like: - -:: +Typical code would look like:: static int __maybe_unused mychip_suspend(struct device *dev) { @@ -4016,7 +3798,7 @@ A typical code would be like: } -The scheme of the real resume job is as follows. +The scheme of the real resume job is as follows: 1. Retrieve the card and the chip data. @@ -4024,16 +3806,14 @@ The scheme of the real resume job is as follows. 3. Restore the saved registers if necessary. -4. Resume the mixer, e.g. calling :c:func:`snd_ac97_resume()`. +4. Resume the mixer, e.g. by calling :c:func:`snd_ac97_resume()`. 5. Restart the hardware (if any). 6. Call :c:func:`snd_power_change_state()` with ``SNDRV_CTL_POWER_D0`` to notify the processes. -A typical code would be like: - -:: +Typical code would look like:: static int __maybe_unused mychip_resume(struct pci_dev *pci) { @@ -4060,9 +3840,7 @@ been already suspended via its own PM ops calling OK, we have all callbacks now. Let's set them up. In the initialization of the card, make sure that you can get the chip data from the card instance, typically via ``private_data`` field, in case you created the -chip data individually. - -:: +chip data individually:: static int snd_mychip_probe(struct pci_dev *pci, const struct pci_device_id *pci_id) @@ -4082,9 +3860,7 @@ chip data individually. } When you created the chip data with :c:func:`snd_card_new()`, it's -anyway accessible via ``private_data`` field. - -:: +anyway accessible via ``private_data`` field:: static int snd_mychip_probe(struct pci_dev *pci, const struct pci_device_id *pci_id) @@ -4101,14 +3877,12 @@ anyway accessible via ``private_data`` field. .... } -If you need a space to save the registers, allocate the buffer for it +If you need space to save the registers, allocate the buffer for it here, too, since it would be fatal if you cannot allocate a memory in the suspend phase. The allocated buffer should be released in the corresponding destructor. -And next, set suspend/resume callbacks to the pci_driver. - -:: +And next, set suspend/resume callbacks to the pci_driver:: static SIMPLE_DEV_PM_OPS(snd_my_pm_ops, mychip_suspend, mychip_resume); @@ -4128,9 +3902,7 @@ have the ``index``, ``id`` and ``enable`` options. If the module supports multiple cards (usually up to 8 = ``SNDRV_CARDS`` cards), they should be arrays. The default initial values are defined -already as constants for easier programming: - -:: +already as constants for easier programming:: static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR; @@ -4144,9 +3916,7 @@ The module parameters must be declared with the standard ``module_param()``, ``module_param_array()`` and :c:func:`MODULE_PARM_DESC()` macros. -The typical coding would be like below: - -:: +Typical code would look as below:: #define CARD_NAME "My Chip" @@ -4159,9 +3929,7 @@ The typical coding would be like below: Also, don't forget to define the module description and the license. Especially, the recent modprobe requires to define the -module license as GPL, etc., otherwise the system is shown as “taintedâ€. - -:: +module license as GPL, etc., otherwise the system is shown as “taintedâ€:: MODULE_DESCRIPTION("Sound driver for My Chip"); MODULE_LICENSE("GPL"); @@ -4224,32 +3992,36 @@ Driver with A Single Source File 1. Modify sound/pci/Makefile - Suppose you have a file xyz.c. Add the following two lines - -:: + Suppose you have a file xyz.c. Add the following two lines:: snd-xyz-objs := xyz.o obj-$(CONFIG_SND_XYZ) += snd-xyz.o 2. Create the Kconfig entry - Add the new entry of Kconfig for your xyz driver. config SND_XYZ - tristate "Foobar XYZ" depends on SND select SND_PCM help Say Y here - to include support for Foobar XYZ soundcard. To compile this driver - as a module, choose M here: the module will be called snd-xyz. the - line, select SND_PCM, specifies that the driver xyz supports PCM. In - addition to SND_PCM, the following components are supported for - select command: SND_RAWMIDI, SND_TIMER, SND_HWDEP, - SND_MPU401_UART, SND_OPL3_LIB, SND_OPL4_LIB, SND_VX_LIB, - SND_AC97_CODEC. Add the select command for each supported - component. + Add the new entry of Kconfig for your xyz driver:: + + config SND_XYZ + tristate "Foobar XYZ" + depends on SND + select SND_PCM + help + Say Y here to include support for Foobar XYZ soundcard. + To compile this driver as a module, choose M here: + the module will be called snd-xyz. + +The line ``select SND_PCM`` specifies that the driver xyz supports PCM. +In addition to SND_PCM, the following components are supported for +select command: SND_RAWMIDI, SND_TIMER, SND_HWDEP, SND_MPU401_UART, +SND_OPL3_LIB, SND_OPL4_LIB, SND_VX_LIB, SND_AC97_CODEC. +Add the select command for each supported component. - Note that some selections imply the lowlevel selections. For example, - PCM includes TIMER, MPU401_UART includes RAWMIDI, AC97_CODEC - includes PCM, and OPL3_LIB includes HWDEP. You don't need to give - the lowlevel selections again. +Note that some selections imply the lowlevel selections. For example, +PCM includes TIMER, MPU401_UART includes RAWMIDI, AC97_CODEC +includes PCM, and OPL3_LIB includes HWDEP. You don't need to give +the lowlevel selections again. - For the details of Kconfig script, refer to the kbuild documentation. +For the details of Kconfig script, refer to the kbuild documentation. Drivers with Several Source Files --------------------------------- @@ -4258,16 +4030,12 @@ Suppose that the driver snd-xyz have several source files. They are located in the new subdirectory, sound/pci/xyz. 1. Add a new directory (``sound/pci/xyz``) in ``sound/pci/Makefile`` - as below - -:: + as below:: obj-$(CONFIG_SND) += sound/pci/xyz/ -2. Under the directory ``sound/pci/xyz``, create a Makefile - -:: +2. Under the directory ``sound/pci/xyz``, create a Makefile:: snd-xyz-objs := xyz.o abc.o def.o obj-$(CONFIG_SND_XYZ) += snd-xyz.o diff --git a/Documentation/spi/spi-summary.rst b/Documentation/spi/spi-summary.rst index 3c95ae322fb1..33f05901ccf3 100644 --- a/Documentation/spi/spi-summary.rst +++ b/Documentation/spi/spi-summary.rst @@ -178,10 +178,10 @@ shows up in sysfs in several locations:: /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices - /sys/class/spi_master/spiB ... symlink (or actual device node) to - a logical node which could hold class related state for the SPI - master controller managing bus "B". All spiB.* devices share one - physical SPI bus segment, with SCLK, MOSI, and MISO. + /sys/class/spi_master/spiB ... symlink to a logical node which could hold + class related state for the SPI master controller managing bus "B". + All spiB.* devices share one physical SPI bus segment, with SCLK, + MOSI, and MISO. /sys/devices/.../CTLR/slave ... virtual file for (un)registering the slave device for an SPI slave controller. @@ -191,16 +191,13 @@ shows up in sysfs in several locations:: Reading from this file shows the name of the slave device ("(null)" if not registered). - /sys/class/spi_slave/spiB ... symlink (or actual device node) to - a logical node which could hold class related state for the SPI - slave controller on bus "B". When registered, a single spiB.* - device is present here, possible sharing the physical SPI bus - segment with other SPI slave devices. + /sys/class/spi_slave/spiB ... symlink to a logical node which could hold + class related state for the SPI slave controller on bus "B". When + registered, a single spiB.* device is present here, possible sharing + the physical SPI bus segment with other SPI slave devices. -Note that the actual location of the controller's class state depends -on whether you enabled CONFIG_SYSFS_DEPRECATED or not. At this time, -the only class-specific state is the bus number ("B" in "spiB"), so -those /sys/class entries are only useful to quickly identify busses. +At this time, the only class-specific state is the bus number ("B" in "spiB"), +so those /sys/class entries are only useful to quickly identify busses. How does board-specific init code declare SPI devices? diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst index 498343c7ab08..22baa077a3b9 100644 --- a/Documentation/staging/tee.rst +++ b/Documentation/staging/tee.rst @@ -214,6 +214,57 @@ call is done from the thread assisting the interrupt handler. This is a building block for OP-TEE OS in secure world to implement the top half and bottom half style of device drivers. +OPTEE_INSECURE_LOAD_IMAGE Kconfig option +---------------------------------------- + +The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load the +BL32 OP-TEE image from the kernel after the kernel boots, rather than loading +it from the firmware before the kernel boots. This also requires enabling the +corresponding option in Trusted Firmware for Arm. The Trusted Firmware for Arm +documentation [8] explains the security threat associated with enabling this as +well as mitigations at the firmware and platform level. + +There are additional attack vectors/mitigations for the kernel that should be +addressed when using this option. + +1. Boot chain security. + + * Attack vector: Replace the OP-TEE OS image in the rootfs to gain control of + the system. + + * Mitigation: There must be boot chain security that verifies the kernel and + rootfs, otherwise an attacker can modify the loaded OP-TEE binary by + modifying it in the rootfs. + +2. Alternate boot modes. + + * Attack vector: Using an alternate boot mode (i.e. recovery mode), the + OP-TEE driver isn't loaded, leaving the SMC hole open. + + * Mitigation: If there are alternate methods of booting the device, such as a + recovery mode, it should be ensured that the same mitigations are applied + in that mode. + +3. Attacks prior to SMC invocation. + + * Attack vector: Code that is executed prior to issuing the SMC call to load + OP-TEE can be exploited to then load an alternate OS image. + + * Mitigation: The OP-TEE driver must be loaded before any potential attack + vectors are opened up. This should include mounting of any modifiable + filesystems, opening of network ports or communicating with external + devices (e.g. USB). + +4. Blocking SMC call to load OP-TEE. + + * Attack vector: Prevent the driver from being probed, so the SMC call to + load OP-TEE isn't executed when desired, leaving it open to being executed + later and loading a modified OS. + + * Mitigation: It is recommended to build the OP-TEE driver as builtin driver + rather than as a module to prevent exploits that may cause the module to + not be loaded. + AMD-TEE driver ============== @@ -309,3 +360,5 @@ References [6] include/linux/psp-tee.h [7] drivers/tee/amdtee/amdtee_if.h + +[8] https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html diff --git a/Documentation/tools/rtla/common_timerlat_aa.rst b/Documentation/tools/rtla/common_timerlat_aa.rst index 077029e6b289..795b9fbcbc6d 100644 --- a/Documentation/tools/rtla/common_timerlat_aa.rst +++ b/Documentation/tools/rtla/common_timerlat_aa.rst @@ -5,3 +5,10 @@ **--no-aa** disable auto-analysis, reducing rtla timerlat cpu usage + +**--aa-only** *us* + + Set stop tracing conditions and run without collecting and displaying statistics. + Print the auto-analysis if the system hits the stop tracing condition. This option + is useful to reduce rtla timerlat CPU, enabling the debug without the overhead of + collecting the statistics. diff --git a/Documentation/trace/fprobe.rst b/Documentation/trace/fprobe.rst index b64bec1ce144..40dd2fbce861 100644 --- a/Documentation/trace/fprobe.rst +++ b/Documentation/trace/fprobe.rst @@ -87,14 +87,16 @@ returns as same as unregister_ftrace_function(). The fprobe entry/exit handler ============================= -The prototype of the entry/exit callback function is as follows: +The prototype of the entry/exit callback function are as follows: .. code-block:: c - void callback_func(struct fprobe *fp, unsigned long entry_ip, struct pt_regs *regs); + int entry_callback(struct fprobe *fp, unsigned long entry_ip, struct pt_regs *regs, void *entry_data); -Note that both entry and exit callbacks have same ptototype. The @entry_ip is -saved at function entry and passed to exit handler. + void exit_callback(struct fprobe *fp, unsigned long entry_ip, struct pt_regs *regs, void *entry_data); + +Note that the @entry_ip is saved at function entry and passed to exit handler. +If the entry callback function returns !0, the corresponding exit callback will be cancelled. @fp This is the address of `fprobe` data structure related to this handler. @@ -113,6 +115,12 @@ saved at function entry and passed to exit handler. to use @entry_ip. On the other hand, in the exit_handler, the instruction pointer of @regs is set to the currect return address. +@entry_data + This is a local storage to share the data between entry and exit handlers. + This storage is NULL by default. If the user specify `exit_handler` field + and `entry_data_size` field when registering the fprobe, the storage is + allocated and passed to both `entry_handler` and `exit_handler`. + Share the callbacks with kprobes ================================ diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index b927fb2b94dc..a9c8bce4bc7b 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -1027,6 +1027,7 @@ To see what is available, simply cat the file:: nohex nobin noblock + nofields trace_printk annotate nouserstacktrace @@ -1110,6 +1111,11 @@ Here are the available options: block When set, reading trace_pipe will not block when polled. + fields + Print the fields as described by their types. This is a better + option than using hex, bin or raw, as it gives a better parsing + of the content of the event. + trace_printk Can disable trace_printk() from writing into the buffer. @@ -3510,7 +3516,7 @@ directories, the rmdir will fail with EBUSY. Stack trace ----------- Since the kernel has a fixed sized stack, it is important not to -waste it in functions. A kernel developer must be conscience of +waste it in functions. A kernel developer must be conscious of what they allocate on the stack. If they add too much, the system can be in danger of a stack overflow, and corruption will occur, usually leading to a system panic. diff --git a/Documentation/trace/user_events.rst b/Documentation/trace/user_events.rst index 422802ef4025..f79987e16cf4 100644 --- a/Documentation/trace/user_events.rst +++ b/Documentation/trace/user_events.rst @@ -20,11 +20,10 @@ dynamic_events is the same as the ioctl with the u: prefix applied. Typically programs will register a set of events that they wish to expose to tools that can read trace_events (such as ftrace and perf). The registration -process gives back two ints to the program for each event. The first int is -the status bit. This describes which bit in little-endian format in the -/sys/kernel/tracing/user_events_status file represents this event. The -second int is the write index which describes the data when a write() or -writev() is called on the /sys/kernel/tracing/user_events_data file. +process tells the kernel which address and bit to reflect if any tool has +enabled the event and data should be written. The registration will give back +a write index which describes the data when a write() or writev() is called +on the /sys/kernel/tracing/user_events_data file. The structures referenced in this document are contained within the /include/uapi/linux/user_events.h file in the source tree. @@ -41,23 +40,64 @@ DIAG_IOCSREG. This command takes a packed struct user_reg as an argument:: struct user_reg { - u32 size; - u64 name_args; - u32 status_bit; - u32 write_index; - }; + /* Input: Size of the user_reg structure being used */ + __u32 size; + + /* Input: Bit in enable address to use */ + __u8 enable_bit; + + /* Input: Enable size in bytes at address */ + __u8 enable_size; + + /* Input: Flags for future use, set to 0 */ + __u16 flags; + + /* Input: Address to update when enabled */ + __u64 enable_addr; + + /* Input: Pointer to string with event name, description and flags */ + __u64 name_args; + + /* Output: Index of the event to use when writing data */ + __u32 write_index; + } __attribute__((__packed__)); + +The struct user_reg requires all the above inputs to be set appropriately. + ++ size: This must be set to sizeof(struct user_reg). -The struct user_reg requires two inputs, the first is the size of the structure -to ensure forward and backward compatibility. The second is the command string -to issue for registering. Upon success two outputs are set, the status bit -and the write index. ++ enable_bit: The bit to reflect the event status at the address specified by + enable_addr. + ++ enable_size: The size of the value specified by enable_addr. + This must be 4 (32-bit) or 8 (64-bit). 64-bit values are only allowed to be + used on 64-bit kernels, however, 32-bit can be used on all kernels. + ++ flags: The flags to use, if any. For the initial version this must be 0. + Callers should first attempt to use flags and retry without flags to ensure + support for lower versions of the kernel. If a flag is not supported -EINVAL + is returned. + ++ enable_addr: The address of the value to use to reflect event status. This + must be naturally aligned and write accessible within the user program. + ++ name_args: The name and arguments to describe the event, see command format + for details. + +Upon successful registration the following is set. + ++ write_index: The index to use for this file descriptor that represents this + event when writing out data. The index is unique to this instance of the file + descriptor that was used for the registration. See writing data for details. User based events show up under tracefs like any other event under the subsystem named "user_events". This means tools that wish to attach to the events need to use /sys/kernel/tracing/events/user_events/[name]/enable or perf record -e user_events:[name] when attaching/recording. -**NOTE:** *The write_index returned is only valid for the FD that was used* +**NOTE:** The event subsystem name by default is "user_events". Callers should +not assume it will always be "user_events". Operators reserve the right in the +future to change the subsystem name per-process to accomodate event isolation. Command Format ^^^^^^^^^^^^^^ @@ -94,7 +134,7 @@ Would be represented by the following field:: struct mytype myname 20 Deleting ------------ +-------- Deleting an event from within a user process is done via ioctl() out to the /sys/kernel/tracing/user_events_data file. The command to issue is DIAG_IOCSDEL. @@ -104,92 +144,79 @@ its name. Delete will only succeed if there are no references left to the event (in both user and kernel space). User programs should use a separate file to request deletes than the one used for registration due to this. -Status ------- -When tools attach/record user based events the status of the event is updated -in realtime. This allows user programs to only incur the cost of the write() or -writev() calls when something is actively attached to the event. - -User programs call mmap() on /sys/kernel/tracing/user_events_status to -check the status for each event that is registered. The bit to check in the -file is given back after the register ioctl() via user_reg.status_bit. The bit -is always in little-endian format. Programs can check if the bit is set either -using a byte-wise index with a mask or a long-wise index with a little-endian -mask. +Unregistering +------------- +If after registering an event it is no longer wanted to be updated then it can +be disabled via ioctl() out to the /sys/kernel/tracing/user_events_data file. +The command to issue is DIAG_IOCSUNREG. This is different than deleting, where +deleting actually removes the event from the system. Unregistering simply tells +the kernel your process is no longer interested in updates to the event. -Currently the size of user_events_status is a single page, however, custom -kernel configurations can change this size to allow more user based events. In -all cases the size of the file is a multiple of a page size. +This command takes a packed struct user_unreg as an argument:: -For example, if the register ioctl() gives back a status_bit of 3 you would -check byte 0 (3 / 8) of the returned mmap data and then AND the result with 8 -(1 << (3 % 8)) to see if anything is attached to that event. + struct user_unreg { + /* Input: Size of the user_unreg structure being used */ + __u32 size; -A byte-wise index check is performed as follows:: + /* Input: Bit to unregister */ + __u8 disable_bit; - int index, mask; - char *status_page; + /* Input: Reserved, set to 0 */ + __u8 __reserved; - index = status_bit / 8; - mask = 1 << (status_bit % 8); - - ... + /* Input: Reserved, set to 0 */ + __u16 __reserved2; - if (status_page[index] & mask) { - /* Enabled */ - } + /* Input: Address to unregister */ + __u64 disable_addr; + } __attribute__((__packed__)); -A long-wise index check is performed as follows:: +The struct user_unreg requires all the above inputs to be set appropriately. - #include <asm/bitsperlong.h> - #include <endian.h> ++ size: This must be set to sizeof(struct user_unreg). - #if __BITS_PER_LONG == 64 - #define endian_swap(x) htole64(x) - #else - #define endian_swap(x) htole32(x) - #endif ++ disable_bit: This must be set to the bit to disable (same bit that was + previously registered via enable_bit). - long index, mask, *status_page; ++ disable_addr: This must be set to the address to disable (same address that was + previously registered via enable_addr). - index = status_bit / __BITS_PER_LONG; - mask = 1L << (status_bit % __BITS_PER_LONG); - mask = endian_swap(mask); +**NOTE:** Events are automatically unregistered when execve() is invoked. During +fork() the registered events will be retained and must be unregistered manually +in each process if wanted. - ... +Status +------ +When tools attach/record user based events the status of the event is updated +in realtime. This allows user programs to only incur the cost of the write() or +writev() calls when something is actively attached to the event. - if (status_page[index] & mask) { - /* Enabled */ - } +The kernel will update the specified bit that was registered for the event as +tools attach/detach from the event. User programs simply check if the bit is set +to see if something is attached or not. Administrators can easily check the status of all registered events by reading the user_events_status file directly via a terminal. The output is as follows:: - Byte:Name [# Comments] + Name [# Comments] ... Active: ActiveCount Busy: BusyCount - Max: MaxCount For example, on a system that has a single event the output looks like this:: - 1:test + test Active: 1 Busy: 0 - Max: 32768 If a user enables the user event via ftrace, the output would change to this:: - 1:test # Used by ftrace + test # Used by ftrace Active: 1 Busy: 1 - Max: 32768 - -**NOTE:** *A status bit of 0 will never be returned. This allows user programs -to have a bit that can be used on error cases.* Writing Data ------------ @@ -217,7 +244,7 @@ For example, if I have a struct like this:: int src; int dst; int flags; - }; + } __attribute__((__packed__)); It's advised for user programs to do the following:: diff --git a/Documentation/translations/it_IT/admin-guide/security-bugs.rst b/Documentation/translations/it_IT/admin-guide/security-bugs.rst index 18a5822c7d9a..20994f4bfa31 100644 --- a/Documentation/translations/it_IT/admin-guide/security-bugs.rst +++ b/Documentation/translations/it_IT/admin-guide/security-bugs.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-ita.rst -:Original: :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` +:Original: :ref:`Documentation/process/security-bugs.rst <securitybugs>` .. _it_securitybugs: diff --git a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst index 0f6898860d6d..17abc25ee4c1 100644 --- a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst +++ b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst @@ -1,7 +1,6 @@ .. include:: ../disclaimer-ita.rst -:Original: :doc:`../../../core-api/symbol-namespaces` -:Translator: Federico Vaga <federico.vaga@vaga.pv.it> +:Original: Documentation/core-api/symbol-namespaces.rst =========================== Spazio dei nomi dei simboli diff --git a/Documentation/translations/it_IT/doc-guide/parse-headers.rst b/Documentation/translations/it_IT/doc-guide/parse-headers.rst index 993d549ee2b8..c7076a21667a 100644 --- a/Documentation/translations/it_IT/doc-guide/parse-headers.rst +++ b/Documentation/translations/it_IT/doc-guide/parse-headers.rst @@ -1,7 +1,6 @@ .. include:: ../disclaimer-ita.rst -.. note:: Per leggere la documentazione originale in inglese: - :ref:`Documentation/doc-guide/index.rst <doc_guide>` +:Original: Documentation/doc-guide/index.rst ========================================= Includere gli i file di intestazione uAPI @@ -190,7 +189,7 @@ COPYRIGHT Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab@s-opensource.com>. -Licenza GPLv2: GNU GPL version 2 <http://gnu.org/licenses/gpl.html>. +Licenza GPLv2: GNU GPL version 2 <https://gnu.org/licenses/gpl.html>. Questo è software libero: siete liberi di cambiarlo e ridistribuirlo. Non c'è alcuna garanzia, nei limiti permessi dalla legge. diff --git a/Documentation/translations/it_IT/index.rst b/Documentation/translations/it_IT/index.rst index fc5f39814e83..b95dfa1ded04 100644 --- a/Documentation/translations/it_IT/index.rst +++ b/Documentation/translations/it_IT/index.rst @@ -2,9 +2,9 @@ .. _it_linux_doc: -=================== -Traduzione italiana -=================== +================================== +La documentazione del kernel Linux +================================== .. raw:: latex @@ -12,6 +12,18 @@ Traduzione italiana :manutentore: Federico Vaga <federico.vaga@vaga.pv.it> +Questo è il livello principale della documentazione del kernel in +lingua italiana. La traduzione è incompleta, noterete degli avvisi +che vi segnaleranno la mancanza di una traduzione o di un gruppo di +traduzioni. + +Più in generale, la documentazione, come il kernel stesso, sono in +costante sviluppo; particolarmente vero in quanto stiamo lavorando +alla riorganizzazione della documentazione in modo più coerente. +I miglioramenti alla documentazione sono sempre i benvenuti; per cui, +se vuoi aiutare, iscriviti alla lista di discussione linux-doc presso +vger.kernel.org. + .. _it_disclaimer: Avvertenze @@ -54,23 +66,8 @@ Se avete bisogno d'aiuto per comunicare con la comunità Linux ma non vi sentite a vostro agio nello scrivere in inglese, potete chiedere aiuto al manutentore della traduzione. -La documentazione del kernel Linux -================================== - -Questo è il livello principale della documentazione del kernel in -lingua italiana. La traduzione è incompleta, noterete degli avvisi -che vi segnaleranno la mancanza di una traduzione o di un gruppo di -traduzioni. - -Più in generale, la documentazione, come il kernel stesso, sono in -costante sviluppo; particolarmente vero in quanto stiamo lavorando -alla riorganizzazione della documentazione in modo più coerente. -I miglioramenti alla documentazione sono sempre i benvenuti; per cui, -se vuoi aiutare, iscriviti alla lista di discussione linux-doc presso -vger.kernel.org. - Lavorare con la comunità di sviluppo ------------------------------------- +==================================== Le guide fondamentali per l'interazione con la comunità di sviluppo del kernel e su come vedere il proprio lavoro integrato. @@ -85,7 +82,7 @@ su come vedere il proprio lavoro integrato. Manuali sull'API interna ------------------------- +======================== Di seguito una serie di manuali per gli sviluppatori che hanno bisogno di interfacciarsi con il resto del kernel. @@ -96,7 +93,7 @@ interfacciarsi con il resto del kernel. core-api/index Strumenti e processi per lo sviluppo ------------------------------------- +==================================== Di seguito una serie di manuali contenenti informazioni utili a tutti gli sviluppatori del kernel. @@ -109,7 +106,7 @@ sviluppatori del kernel. kernel-hacking/index Documentazione per gli utenti ------------------------------ +============================= Di seguito una serie di manuali per gli *utenti* del kernel - ovvero coloro che stanno cercando di farlo funzionare al meglio per un dato sistema, ma anche @@ -120,16 +117,16 @@ Consultate anche `Linux man pages <https://www.kernel.org/doc/man-pages/>`_, che vengono mantenuti separatamente dalla documentazione del kernel Linux Documentazione relativa ai firmware ------------------------------------ +=================================== Di seguito informazioni sulle aspettative del kernel circa i firmware. Documentazione specifica per architettura ------------------------------------------ +========================================= Documentazione varia --------------------- +==================== Ci sono documenti che sono difficili da inserire nell'attuale organizzazione della documentazione; altri hanno bisogno di essere migliorati e/o convertiti diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index 05d362b16bf0..a9e781d2e323 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -1029,6 +1029,11 @@ Dato che questo è un problema abbastanza comune con una propensione alle corse critiche, dovreste usare timer_delete_sync() (``include/linux/timer.h``) per gestire questo caso. +Prima di rilasciare un temporizzatore dovreste chiamare la funzione +timer_shutdown() o timer_shutdown_sync() di modo che non venga più ricarmato. +Ogni successivo tentativo di riarmare il temporizzatore verrà silenziosamente +ignorato. + Velocità della sincronizzazione =============================== diff --git a/Documentation/translations/it_IT/process/5.Posting.rst b/Documentation/translations/it_IT/process/5.Posting.rst index cf92a16ed7e5..a7e2a3238415 100644 --- a/Documentation/translations/it_IT/process/5.Posting.rst +++ b/Documentation/translations/it_IT/process/5.Posting.rst @@ -265,15 +265,18 @@ Le etichette in uso più comuni sono: :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` - Reported-by: menziona l'utente che ha riportato il problema corretto da - questa patch; quest'etichetta viene usata per dare credito alle persone - che hanno verificato il codice e ci hanno fatto sapere quando le cose non - funzionavano correttamente. + questa patch; quest'etichetta viene usata per dare credito alle persone che + hanno verificato il codice e ci hanno fatto sapere quando le cose non + funzionavano correttamente. Se esiste un rapporto disponibile sul web, allora + L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto. - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto l'opportunità di commentarla. -State attenti ad aggiungere queste etichette alla vostra patch: solo -"Cc:" può essere aggiunta senza il permesso esplicito della persona menzionata. +State attenti ad aggiungere queste etichette alla vostra patch: solo "Cc:" può +essere aggiunta senza il permesso esplicito della persona menzionata. Il più +delle volte anche Reported-by: va bene, ma è sempre meglio chiedere specialmente +se il baco è stato riportato in una comunicazione privata. Inviare la modifica ------------------- diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst index 473ec2cc558e..f37c53f8b524 100644 --- a/Documentation/translations/it_IT/process/changes.rst +++ b/Documentation/translations/it_IT/process/changes.rst @@ -36,7 +36,7 @@ GNU C 5.1 gcc --version Clang/LLVM (optional) 11.0.0 clang --version GNU make 3.81 make --version bash 4.2 bash --version -binutils 2.23 ld -v +binutils 2.25 ld -v flex 2.5.35 flex --version bison 2.0 bison --version pahole 1.16 pahole --version @@ -97,7 +97,7 @@ Questo richiede bash 4.2 o successivo. Binutils -------- -Per generare il kernel è necessario avere Binutils 2.23 o superiore. +Per generare il kernel è necessario avere Binutils 2.25 o superiore. pkg-config ---------- diff --git a/Documentation/translations/it_IT/process/clang-format.rst b/Documentation/translations/it_IT/process/clang-format.rst index 77eac809a639..29f83c198025 100644 --- a/Documentation/translations/it_IT/process/clang-format.rst +++ b/Documentation/translations/it_IT/process/clang-format.rst @@ -40,7 +40,7 @@ Linux più popolari. Cercate ``clang-format`` nel vostro repositorio. Altrimenti, potete scaricare una versione pre-generata dei binari di LLVM/clang oppure generarlo dai codici sorgenti: - http://releases.llvm.org/download.html + https://releases.llvm.org/download.html Troverete più informazioni ai seguenti indirizzi: diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index a393ee4182af..5f244e16f511 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -1204,10 +1204,10 @@ ISBN 0-201-61586-X. Manuali GNU - nei casi in cui sono compatibili con K&R e questo documento - per indent, cpp, gcc e i suoi dettagli interni, tutto disponibile qui -http://www.gnu.org/manual/ +https://www.gnu.org/manual/ WG14 è il gruppo internazionale di standardizzazione per il linguaggio C, -URL: http://www.open-std.org/JTC1/SC22/WG14/ +URL: https://www.open-std.org/JTC1/SC22/WG14/ -Kernel process/coding-style.rst, by greg@kroah.com at OLS 2002: +Kernel CodingStyle, by greg@kroah.com at OLS 2002: http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst index febf83897783..57b501f0dfa4 100644 --- a/Documentation/translations/it_IT/process/deprecated.rst +++ b/Documentation/translations/it_IT/process/deprecated.rst @@ -332,7 +332,7 @@ zero come risultato:: Il valore di ``size`` nell'ultima riga sarà ``zero``, quando uno invece si aspetterebbe che il suo valore sia la dimensione totale in -byte dell'allocazione dynamica che abbiamo appena fatto per l'array +byte dell'allocazione dinamica che abbiamo appena fatto per l'array ``items``. Qui un paio di esempi reali del problema: `collegamento 1 <https://git.kernel.org/linus/f2cd32a443da694ac4e28fbf4ac6f9d5cc63a539>`_, `collegamento 2 @@ -381,4 +381,29 @@ combinazione con struct_size() e flex_array_size():: instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); instance->count = count; - memcpy(instance->items, source, flex_array_size(instance, items, instance->count)); + memcpy(instance->items, source, flex_array_size(instance, items, instance->count)); + +Ci sono due casi speciali dove è necessario usare la macro DECLARE_FLEX_ARRAY() +(da notare che la stessa macro è chiamata __DECLARE_FLEX_ARRAY() nei file di +intestazione UAPI). Uno è quando l'array flessibile è l'unico elemento di una +struttura, e l'altro è quando è parti un unione. Per motivi non tecnici, entrambi +i casi d'uso non sono permessi dalla specifica C99. Per esempio, per +convertire il seguente codice:: + + struct something { + ... + union { + struct type1 one[0]; + struct type2 two[0]; + }; + }; + +La macro di supporto dev'essere usata:: + + struct something { + ... + union { + DECLARE_FLEX_ARRAY(struct type1, one); + DECLARE_FLEX_ARRAY(struct type2, two); + }; + }; diff --git a/Documentation/translations/it_IT/process/email-clients.rst b/Documentation/translations/it_IT/process/email-clients.rst index 970671cd91af..76ca3226c8cd 100644 --- a/Documentation/translations/it_IT/process/email-clients.rst +++ b/Documentation/translations/it_IT/process/email-clients.rst @@ -364,3 +364,28 @@ un editor esterno. Un altro problema è che Gmail usa la codifica base64 per tutti quei messaggi che contengono caratteri non ASCII. Questo include cose tipo i nomi europei. + +Proton Mail +*********** + +Il servizio Proton Mail ha una funzionalità che cripta tutti i messaggi verso +ogni destinatario per cui è possibile trovare una chiave usando il *Web Key +Directory* (WKD). Il servizio kernel.org pubblica il WKD per ogni sviluppatore +in possesso di un conto kernel.org. Di conseguenza, tutti i messaggi inviati +usando Proton Mail verso indirizzi kernel.org verranno criptati. + +Proton Mail non fornisce alcun meccanismo per disabilitare questa funzionalità +perché verrebbe considerato un problema per la riservatezza. Questa funzionalità +è attiva anche quando si inviano messaggi usando il Proton Mail Bridge. Dunque +tutta la posta in uscita verrà criptata, incluse le patch inviate con ``git +send-email``. + +I messaggi criptati sono una fonte di problemi; altri sviluppatori potrebbero +non aver configurato i loro programmi, o strumenti, per gestire messaggi +criptati; inoltre, alcuni programmi di posta elettronica potrebbero criptare le +risposte a messaggi criptati per tutti i partecipanti alla discussione, inclusa +la lista di discussione stessa. + +A meno che non venga introdotta una maniera per disabilitare questa +funzionalità , non è consigliato usare Proton Mail per contribuire allo sviluppo +del kernel. diff --git a/Documentation/translations/it_IT/process/index.rst b/Documentation/translations/it_IT/process/index.rst index 25602c1a97d1..cd7977905fb8 100644 --- a/Documentation/translations/it_IT/process/index.rst +++ b/Documentation/translations/it_IT/process/index.rst @@ -10,6 +10,7 @@ .. _it_process_index: +=============================================== Lavorare con la comunità di sviluppo del kernel =============================================== diff --git a/Documentation/translations/it_IT/process/magic-number.rst b/Documentation/translations/it_IT/process/magic-number.rst index 02eb7eb2448e..ae92ab633c16 100644 --- a/Documentation/translations/it_IT/process/magic-number.rst +++ b/Documentation/translations/it_IT/process/magic-number.rst @@ -78,7 +78,6 @@ PG_MAGIC 'P' pg_{read,write}_hdr ``include/linux/ APM_BIOS_MAGIC 0x4101 apm_user ``arch/x86/kernel/apm_32.c`` FASYNC_MAGIC 0x4601 fasync_struct ``include/linux/fs.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` -MGSLPC_MAGIC 0x5402 mgslpc_info ``drivers/char/pcmcia/synclink_cs.c`` BAYCOM_MAGIC 0x19730510 baycom_state ``drivers/net/baycom_epp.c`` HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state ``include/linux/hdlcdrv.h`` KV_MAGIC 0x5f4b565f kernel_vars_s ``arch/mips/include/asm/sn/klkernvars.h`` diff --git a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst index 5526bcabeb0a..cdc43c4a9b0b 100644 --- a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst +++ b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst @@ -68,42 +68,24 @@ stesso. Strumenti PGP ============= -Usare GnuPG v2 --------------- +Usare GnuPG 2.2 o successivo +---------------------------- La vostra distribuzione potrebbe avere già installato GnuPG, dovete solo -verificare che stia utilizzando la versione 2.x e non la serie 1.4 -- -molte distribuzioni forniscono entrambe, di base il comando ''gpg'' -invoca GnuPG v.1. Per controllate usate:: +verificare che stia utilizzando la versione abbastanza recente. Per controllate +usate:: $ gpg --version | head -n1 -Se visualizzate ``gpg (GnuPG) 1.4.x``, allora state usando GnuPG v.1. -Provate il comando ``gpg2`` (se non lo avete, potreste aver bisogno -di installare il pacchetto gnupg2):: - - $ gpg2 --version | head -n1 - -Se visualizzate ``gpg (GnuPG) 2.x.x``, allora siete pronti a partire. -Questa guida assume che abbiate la versione 2.2.(o successiva) di GnuPG. -Se state usando la versione 2.0, alcuni dei comandi indicati qui non -funzioneranno, in questo caso considerate un aggiornamento all'ultima versione, -la 2.2. Versioni di gnupg-2.1.11 e successive dovrebbero essere compatibili -per gli obiettivi di questa guida. - -Se avete entrambi i comandi: ``gpg`` e ``gpg2``, assicuratevi di utilizzare -sempre la versione V2, e non quella vecchia. Per evitare errori potreste creare -un alias:: - - $ alias gpg=gpg2 - -Potete mettere questa opzione nel vostro ``.bashrc`` in modo da essere sicuri. +Se state utilizzando la version 2.2 o successiva, allora siete pronti a partire. +Se invece state usando una versione precedente, allora alcuni comandi elencati +in questa guida potrebbero non funzionare. Configurare le opzioni di gpg-agent ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L'agente GnuPG è uno strumento di aiuto che partirà automaticamente ogni volta -che userete il comando ``gpg`` e funzionerà in background con l'obiettivo di +che userete il comando ``gpg`` e funzionerà in *background* con l'obiettivo di individuare la passphrase. Ci sono due opzioni che dovreste conoscere per personalizzare la scadenza della passphrase nella cache: @@ -131,19 +113,7 @@ valori:: riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più bene il loro compito. -Impostare un *refresh* con cronjob -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Potreste aver bisogno di rinfrescare regolarmente il vostro portachiavi in -modo aggiornare le chiavi pubbliche di altre persone, lavoro che è svolto -al meglio con un cronjob giornaliero:: - - @daily /usr/bin/gpg2 --refresh >/dev/null 2>&1 - -Controllate il percorso assoluto del vostro comando ``gpg`` o ``gpg2`` e usate -il comando ``gpg2`` se per voi ``gpg`` corrisponde alla versione GnuPG v.1. - -.. _it_master_key: +.. _it_protect_your_key: Proteggere la vostra chiave PGP primaria ======================================== @@ -155,55 +125,62 @@ al documento "`Protecting Code Integrity`_" che abbiamo menzionato prima. Dovreste inoltre creare una nuova chiave se quella attuale è inferiore a 2048 bit (RSA). -Chiave principale o sottochiavi -------------------------------- - -Le sottochiavi sono chiavi PGP totalmente indipendenti, e sono collegate alla -chiave principale attraverso firme certificate. È quindi importante -comprendere i seguenti punti: - -1. Non ci sono differenze tecniche tra la chiave principale e la sottochiave. -2. In fase di creazione, assegniamo limitazioni funzionali ad ogni chiave - assegnando capacità specifiche. -3. Una chiave PGP può avere 4 capacità : +Le sottochiavi PGP +------------------ - - **[S]** può essere usata per firmare - - **[E]** può essere usata per criptare - - **[A]** può essere usata per autenticare - - **[C]** può essere usata per certificare altre chiavi +Raramente le chiavi PGP sono composte da una singola coppia -- solitamente, sono +una collezione di sottochiavi indipendenti usate per diversi scopi in funzione +delle capacità assegnate al momento della creazione. Una chiave PGP può avere +quattro capacità : + +- **[S]** può essere usata per firmare +- **[E]** può essere usata per criptare +- **[A]** può essere usata per autenticare +- **[C]** può essere usata per certificare altre chiavi + +La chiave con la capacità **[C]** viene spesso chiamata chiave "passepartout" +(*master key*), ma è una terminologia fuorviante perché lascia intendere che la +chiave di certificato possa essere usate in sostituzione delle altre (proprio +come le vere chiavi passpartout in grado di aprire diverse serrature). Dato che +questo non è il caso, per evitare fraintendimenti, in questa guida ci riferiremo +a questa chiave chiamandola "La chiave di certificazione". + +I seguenti punti sono molto importanti: + +1. Tutte le sottochiavi sono indipendenti. Se perdete una sottochiave privata + non potrete recuperarla usando le altre. +2. Ad eccezione della chiave di certificazione, ci possono essere più + sottochiavi con le stesse capacità (per esempio, potete avere 2 sottochiavi + per criptare, 3 per firmare, ma solo una per una sola per certificare). Tutte + le sottochiavi sono indipendenti -- un messaggio criptato usando una chiave + **[E]** non può essere decriptato usano altre sottochiavi **[E]**. +3. Una sottochiave può avere più capacità (per esempio, la chiave **[C]** può + anche essere una chiave **[S]**). + +La chiave con capacità **[C]** (certificazione) è la sola che può essere usata +per indicare relazioni fra chiavi. Solo la chiave **[C]** può essere usata per: + +- aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A; +- aggiungere, modificare o eliminare le identità (unids) associate alla chiave; +- aggiungere o modificare la propria data di scadenza o delle sottochiavi; +- firmare le chiavi di altre persone a scopo di creare una rete di fiducia. -4. Una singola chiave può avere più capacità -5. Una sottochiave è completamente indipendente dalla chiave principale. - Un messaggio criptato con la sottochiave non può essere decrittato con - quella principale. Se perdete la vostra sottochiave privata, non può - essere rigenerata in nessun modo da quella principale. +Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue: -La chiave con capacità **[C]** (certify) è identificata come la chiave -principale perché è l'unica che può essere usata per indicare la relazione -con altre chiavi. Solo la chiave **[C]** può essere usata per: +- Una chiave la capacità di certificazione che quella di firma (**[SC]**) +- Una sottochiave separata con capacità di criptare (**[E]**) -- Aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A -- Aggiungere, modificare o eliminare le identità (unids) associate alla chiave -- Aggiungere o modificare la data di termine di sé stessa o di ogni sottochiave -- Firmare le chiavi di altre persone a scopo di creare una rete di fiducia -Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue: -- Una chiave madre che porta sia la capacità di certificazione che quella - di firma (**[SC]**) -- Una sottochiave separata con capacità di criptaggio (**[E]**) -Se avete usato i parametri di base per generare la vostra chiave, quello +Se avete usato i parametri predefiniti per generare la vostra chiave, quello sarà il risultato. Potete verificarlo utilizzando ``gpg --list-secret-keys``, per esempio:: - sec rsa2048 2018-01-23 [SC] [expires: 2020-01-23] + sec ed25519 2022-12-20 [SC] [expires: 2024-12-19] 000000000000000000000000AAAABBBBCCCCDDDD uid [ultimate] Alice Dev <adev@kernel.org> - ssb rsa2048 2018-01-23 [E] [expires: 2020-01-23] - -Qualsiasi chiave che abbia la capacità **[C]** è la vostra chiave madre, -indipendentemente da quali altre capacità potreste averle assegnato. + ssb cv25519 2022-12-20 [E] [expires: 2024-12-19] La lunga riga sotto la voce ``sec`` è la vostra impronta digitale -- negli esempi che seguono, quando vedere ``[fpr]`` ci si riferisce a questa @@ -238,20 +215,10 @@ possano ricevere la vostra nuova sottochiave:: $ gpg --send-key [fpr] .. note:: Supporto ECC in GnuPG - GnuPG 2.1 e successivi supportano pienamente *Elliptic Curve Cryptography*, - con la possibilità di combinare sottochiavi ECC con le tradizionali chiavi - primarie RSA. Il principale vantaggio della crittografia ECC è che è molto - più veloce da calcolare e crea firme più piccole se confrontate byte per - byte con le chiavi RSA a più di 2048 bit. A meno che non pensiate di - utilizzare un dispositivo smartcard che non supporta le operazioni ECC, vi - raccomandiamo ti creare sottochiavi di firma ECC per il vostro lavoro col - kernel. - - Se per qualche ragione preferite rimanere con sottochiavi RSA, nel comando - precedente, sostituite "ed25519" con "rsa2048". In aggiunta, se avete - intenzione di usare un dispositivo hardware che non supporta le chiavi - ED25519 ECC, come la Nitrokey Pro o la Yubikey, allora dovreste usare - "nistp256" al posto di "ed25519". + + Tenete presente che se avete intenzione di usare un dispositivo che non + supporta chiavi ED25519 ECC, allora dovreste usare "nistp256" al posto di + "ed25519". Più avanti ci sono alcune raccomandazioni per i dispositivi. Copia di riserva della chiave primaria per gestire il recupero da disastro -------------------------------------------------------------------------- @@ -360,13 +327,13 @@ Per prima cosa, identificate il keygrip della vostra chiave primaria:: L'output assomiglierà a questo:: - pub rsa2048 2018-01-24 [SC] [expires: 2020-01-24] + pub ed25519 2022-12-20 [SC] [expires: 2022-12-19] 000000000000000000000000AAAABBBBCCCCDDDD Keygrip = 1111000000000000000000000000000000000000 uid [ultimate] Alice Dev <adev@kernel.org> - sub rsa2048 2018-01-24 [E] [expires: 2020-01-24] + sub cv25519 2022-12-20 [E] [expires: 2022-12-19] Keygrip = 2222000000000000000000000000000000000000 - sub ed25519 2018-01-24 [S] + sub ed25519 2022-12-20 [S] Keygrip = 3333000000000000000000000000000000000000 Trovate la voce keygrid che si trova sotto alla riga ``pub`` (appena sotto @@ -389,11 +356,11 @@ Ora, se eseguite il comando ``--list-secret-keys``, vedrete che la chiave primaria non compare più (il simbolo ``#`` indica che non è disponibile):: $ gpg --list-secret-keys - sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24] + sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19] 000000000000000000000000AAAABBBBCCCCDDDD uid [ultimate] Alice Dev <adev@kernel.org> - ssb rsa2048 2018-01-24 [E] [expires: 2020-01-24] - ssb ed25519 2018-01-24 [S] + ssb cv25519 2022-12-20 [E] [expires: 2024-12-19] + ssb ed25519 2022-12-20 [S] Dovreste rimuovere anche i file ``secring.gpg`` che si trovano nella cartella ``~/.gnupg``, in quanto rimasugli delle versioni precedenti di GnuPG. @@ -461,18 +428,20 @@ soluzioni disponibili: computer portatili più recenti. In aggiunta, offre altre funzionalità di sicurezza come FIDO, U2F, e ora supporta anche le chiavi ECC (NISTP) -`Su LWN c'è una buona recensione`_ dei modelli elencati qui sopra e altri. -La scelta dipenderà dal costo, dalla disponibilità nella vostra area -geografica e vostre considerazioni sull'hardware aperto/proprietario. +La vostra scelta dipenderà dal costo, la disponibilità nella vostra regione, e +sulla scelta fra dispositivi aperti e proprietari. -Se volete usare chiavi ECC, la vostra migliore scelta sul mercato è la -Nitrokey Start. +.. note:: + + Se siete nella lista MAINTAINERS o avete un profilo su kernel.org, allora + `potrete avere gratuitamente una Nitrokey Start`_ grazie alla fondazione + Linux. .. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6 .. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3 .. _`Yubikey 5`: https://www.yubico.com/product/yubikey-5-overview/ -.. _Gnuk: http://www.fsij.org/doc-gnuk/ -.. _`Su LWN c'è una buona recensione`: https://lwn.net/Articles/736231/ +.. _Gnuk: https://www.fsij.org/doc-gnuk/ +.. _`potrete avere gratuitamente una Nitrokey Start`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html Configurare il vostro dispositivo smartcard ------------------------------------------- @@ -513,6 +482,12 @@ altre informazioni sulla carta che potrebbero trapelare in caso di smarrimento. A dispetto del nome "PIN", né il PIN utente né quello dell'amministratore devono essere esclusivamente numerici. +.. warning:: + + Alcuni dispositivi richiedono la presenza delle sottochiavi nel dispositivo + stesso prima che possiate cambiare la passphare. Verificate la + documentazione del produttore. + Spostare le sottochiavi sulla smartcard --------------------------------------- @@ -525,11 +500,11 @@ dell'amministratore:: Secret subkeys are available. - pub rsa2048/AAAABBBBCCCCDDDD - created: 2018-01-23 expires: 2020-01-23 usage: SC + pub ed25519/AAAABBBBCCCCDDDD + created: 2022-12-20 expires: 2024-12-19 usage: SC trust: ultimate validity: ultimate - ssb rsa2048/1111222233334444 - created: 2018-01-23 expires: never usage: E + ssb cv25519/1111222233334444 + created: 2022-12-20 expires: never usage: E ssb ed25519/5555666677778888 created: 2017-12-07 expires: never usage: S [ultimate] (1). Alice Dev <adev@kernel.org> @@ -594,11 +569,11 @@ Ora, se doveste usare l'opzione ``--list-secret-keys``, vedrete una sottile differenza nell'output:: $ gpg --list-secret-keys - sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24] + sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19] 000000000000000000000000AAAABBBBCCCCDDDD uid [ultimate] Alice Dev <adev@kernel.org> - ssb> rsa2048 2018-01-24 [E] [expires: 2020-01-24] - ssb> ed25519 2018-01-24 [S] + ssb> cv25519 2022-12-20 [E] [expires: 2024-12-19] + ssb> ed25519 2022-12-20 [S] Il simbolo ``>`` in ``ssb>`` indica che la sottochiave è disponibile solo nella smartcard. Se tornate nella vostra cartella delle chiavi segrete e @@ -661,7 +636,7 @@ eseguite:: Se per voi è più facile da memorizzare, potete anche utilizzare una data specifica (per esempio, il vostro compleanno o capodanno):: - $ gpg --quick-set-expire [fpr] 2020-07-01 + $ gpg --quick-set-expire [fpr] 2025-07-01 Ricordatevi di inviare l'aggiornamento ai keyserver:: @@ -676,6 +651,21 @@ dovreste importarle nella vostra cartella di lavoro abituale:: $ gpg --export | gpg --homedir ~/.gnupg --import $ unset GNUPGHOME +Usare gpg-agent con ssh +~~~~~~~~~~~~~~~~~~~~~~~ + +Se dovete firmare tag o commit su un sistema remoto, potete ridirezionare il +vostro gpg-agent attraverso ssh. Consultate le istruzioni disponibili nella wiki +GnuPG: + +- `Agent Forwarding over SSH`_ + +Funziona senza troppi intoppi se avete la possibilità di modificare le +impostazioni di sshd sul sistema remoto. + +.. _`Agent Forwarding over SSH`: https://wiki.gnupg.org/AgentForwarding + +.. _it_pgp_with_git: Usare PGP con Git ================= @@ -709,11 +699,6 @@ avere più chiavi segrete, potete dire a git quale dovrebbe usare (``[fpg]`` $ git config --global user.signingKey [fpr] -**IMPORTANTE**: se avete una comando dedicato per ``gpg2``, allora dovreste -dire a git di usare sempre quello piuttosto che il vecchio comando ``gpg``:: - - $ git config --global gpg.program gpg2 - Come firmare i tag ------------------ @@ -812,6 +797,61 @@ Potete dire a git di firmare sempre i commit:: .. _it_verify_identities: +Come lavorare con patch firmate +------------------------------- + +Esiste la possibilità di usare la vostra chiave PGP per firmare le patch che +invierete alla liste di discussione del kernel. I meccanismi esistenti per la +firma delle email (PGP-Mime o PGP-inline) tendono a causare problemi +nell'attività di revisione del codice. Si suggerisce, invece, di utilizare lo +strumento sviluppato da kernel.org che mette nell'intestazione del messaggio +un'attestazione delle firme crittografiche (tipo DKIM): + +- `Patatt Patch Attestation`_ + +.. _`Patatt Patch Attestation`: https://pypi.org/project/patatt/ + +Installare e configurate patatt +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Lo strumento patatt è disponibile per diverse distribuzioni, dunque cercatelo +prima lì. Oppure potete installarlo usano pypi "``pip install patatt``" + +Se avete già configurato git con la vostra chiave PGP (usando +``user.signingKey``), allora patatt non ha bisogno di alcuna configurazione +aggiuntiva. Potete iniziare a firmare le vostre patch aggiungendo un aggancio a +git-send-email nel vostro repositorio:: + + patatt install-hook + +Ora, qualsiasi patch che invierete con ``git send-email`` verrà automaticamente +firmata usando la vostra firma crittografica. + +Verificare le firme di patatt +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Se usate ``b4`` per verificare ed applicare le patch, allora tenterà +automaticamente di verificare tutte le firme DKIM e patatt disponibili. Per +esempio:: + + $ b4 am 20220720205013.890942-1-broonie@kernel.org + [...] + Checking attestation on all messages, may take a moment... + --- + ✓ [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation for SVE Z registers + ✓ [PATCH v1 2/3] arm64/sve: Document our actual ABI for clearing registers on syscall + ✓ [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE syscalls + --- + ✓ Signed: openpgp/broonie@kernel.org + ✓ Signed: DKIM/kernel.org + +.. note:: + + Lo sviluppo di patatt e b4 è piuttosto attivo. Si consiglia di verificare la + documentazione più recente. + +.. _it_kernel_identities: + Come verificare l'identità degli sviluppatori del kernel ======================================================== @@ -884,64 +924,18 @@ di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione trust-model tofu+pgp -Come usare i keyserver in sicurezza ------------------------------------ -Se ottenete l'errore "No public key" quando cercate di validate il tag di -qualcuno, allora dovreste cercare quella chiave usando un keyserver. È -importante tenere bene a mente che non c'è alcuna garanzia che la chiave -che avete recuperato da un keyserver PGP appartenga davvero alla persona -reale -- è progettato così. Dovreste usare il Web of Trust per assicurarvi -che la chiave sia valida. - -Come mantenere il Web of Trust va oltre gli scopi di questo documento, -semplicemente perché farlo come si deve richiede sia sforzi che perseveranza -che tendono ad andare oltre al livello di interesse della maggior parte degli -esseri umani. Qui di seguito alcuni rapidi suggerimenti per aiutarvi a ridurre -il rischio di importare chiavi maligne. - -Primo, diciamo che avete provato ad eseguire ``git verify-tag`` ma restituisce -un errore dicendo che la chiave non è stata trovata:: - - $ git verify-tag sunxi-fixes-for-4.15-2 - gpg: Signature made Sun 07 Jan 2018 10:51:55 PM EST - gpg: using RSA key DA73759BF8619E484E5A3B47389A54219C0F2430 - gpg: issuer "wens@...org" - gpg: Can't check signature: No public key - -Cerchiamo nel keyserver per maggiori informazioni sull'impronta digitale -della chiave (l'impronta digitale, probabilmente, appartiene ad una -sottochiave, dunque non possiamo usarla direttamente senza trovare prima -l'ID della chiave primaria associata ad essa):: - - $ gpg --search DA73759BF8619E484E5A3B47389A54219C0F2430 - gpg: data source: hkp://keys.gnupg.net - (1) Chen-Yu Tsai <wens@...org> - 4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires: 2019-03-15 - Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430". Enter number(s), N)ext, or Q)uit > q - -Localizzate l'ID della chiave primaria, nel nostro esempio -``C94035C21B4F2AEB``. Ora visualizzate le chiavi di Linus Torvalds -che avete nel vostro portachiavi:: - - $ gpg --list-key torvalds@kernel.org - pub rsa2048 2011-09-20 [SC] - ABAF11C65A2970B130ABE3C479BE3E4300411886 - uid [ unknown] Linus Torvalds <torvalds@kernel.org> - sub rsa2048 2011-09-20 [E] - -Poi, cercate un percorso affidabile da Linux Torvalds alla chiave che avete -trovato con ``gpg --search`` usando la chiave sconosciuta.Per farlo potete usare -diversi strumenti come https://github.com/mricon/wotmate, -https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, e -https://the.earth.li/~noodles/pathfind.html. - -Se trovate un paio di percorsi affidabili è un buon segno circa la validità -della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver:: - - $ gpg --recv-key C94035C21B4F2AEB - -Questa procedura non è perfetta, e ovviamente state riponendo la vostra -fiducia nell'amministratore del servizio *PGP Pathfinder* sperando che non -sia malintenzionato (infatti, questo va contro :ref:`it_devs_not_infra`). -Tuttavia, se mantenete con cura la vostra rete di fiducia sarà un deciso -miglioramento rispetto alla cieca fiducia nei keyserver. +Usare il repositorio kernel.org per il web of trust +--------------------------------------------------- + +Il progetto kernel.org mantiene un repositorio git con le chiavi pubbliche degli sviluppatori in alternativa alla replica dei server di chiavi che negli ultimi anni sono spariti. La documentazione completa su come impostare il repositorio come vostra sorgente di chiavi pubbliche può essere trovato qui: + +- `Kernel developer PGP Keyring`_ + +Se siete uno sviluppatore del kernel, per favore valutate l'idea di inviare la +vostra chiave per l'inclusione in quel portachiavi. + + +If you are a kernel developer, please consider submitting your key for +inclusion into that keyring. + +.. _`Kernel developer PGP Keyring`: https://korg.docs.kernel.org/pgpkeys.html diff --git a/Documentation/translations/it_IT/process/programming-language.rst b/Documentation/translations/it_IT/process/programming-language.rst index c1a9b481a6f9..5bc5b9d42f31 100644 --- a/Documentation/translations/it_IT/process/programming-language.rst +++ b/Documentation/translations/it_IT/process/programming-language.rst @@ -18,10 +18,6 @@ Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione Questo dialetto contiene diverse estensioni al linguaggio [it-gnu-extensions]_, e molte di queste vengono usate sistematicamente dal kernel. -Il kernel offre un certo livello di supporto per la compilazione con -``icc`` [it-icc]_ su diverse architetture, tuttavia in questo momento -il supporto non è completo e richiede delle patch aggiuntive. - Attributi --------- @@ -43,11 +39,30 @@ possono usare e/o per accorciare il codice. Per maggiori informazioni consultate il file d'intestazione ``include/linux/compiler_attributes.h``. +Rust +---- + +Il kernel supporta sperimentalmente il linguaggio di programmazione Rust +[it-rust-language]_ abilitando l'opzione di configurazione ``CONFIG_RUST``. Il +codice verrà compilato usando ``rustc`` [it-rustc]_ con l'opzione +``--edition=2021`` [it-rust-editions]_. Le edizioni Rust sono un modo per +introdurre piccole modifiche senza compatibilità all'indietro._ + +In aggiunta, nel kernel vengono utilizzate alcune funzionalità considerate +instabili [it-rust-unstable-features]_. Queste funzionalità potrebbero cambiare +in futuro, dunque è un'obiettivo importante è quello di far uso solo di +funzionalità stabili. + +Per maggiori informazioni fate riferimento a Documentation/rust/index.rst . + .. [it-c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards .. [it-gcc] https://gcc.gnu.org .. [it-clang] https://clang.llvm.org -.. [it-icc] https://software.intel.com/en-us/c-compilers .. [it-gcc-c-dialect-options] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html .. [it-gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html .. [it-gcc-attribute-syntax] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html .. [it-n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf +.. [it-rust-language] https://www.rust-lang.org +.. [it-rustc] https://doc.rust-lang.org/rustc/ +.. [it-rust-editions] https://doc.rust-lang.org/edition-guide/editions/ +.. [it-rust-unstable-features] https://github.com/Rust-for-Linux/linux/issues/2 diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index 0be675b03199..248bf1e4b171 100644 --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst @@ -106,6 +106,12 @@ al messaggio della patch, così: commit <sha1> upstream. +o in alternativa: + +.. code-block:: none + + [ Upstream commit <sha1> ] + In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero dipendere da altre che devo essere incluse. Questa situazione può essere indicata nel seguente modo nell'area dedicata alle firme: diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index c2cfa0948b2b..447b18792e61 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -272,7 +272,7 @@ embargo potrebbe essere preso in considerazione per dare il tempo alle distribuzioni di prendere la patch e renderla disponibile ai loro utenti; in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna lista di discussione pubblica. Leggete anche -Documentation/admin-guide/security-bugs.rst. +Documentation/process/security-bugs.rst. Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga:: @@ -429,7 +429,7 @@ poi dovete solo aggiungere una riga che dice:: Signed-off-by: Random J Developer <random@developer.example.org> -usando il vostro vero nome (spiacenti, non si accettano pseudonimi o +usando il vostro vero nome (spiacenti, non si accettano contributi anonimi). Questo verrà fatto automaticamente se usate ``git commit -s``. Anche il ripristino di uno stato precedente dovrebbe includere "Signed-off-by", se usate ``git revert -s`` questo verrà @@ -785,7 +785,7 @@ Riferimenti ----------- Andrew Morton, "La patch perfetta" (tpp). - <http://www.ozlabs.org/~akpm/stuff/tpp.txt> + <https://www.ozlabs.org/~akpm/stuff/tpp.txt> Jeff Garzik, "Formato per la sottomissione di patch per il kernel Linux" <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html> diff --git a/Documentation/translations/it_IT/process/volatile-considered-harmful.rst b/Documentation/translations/it_IT/process/volatile-considered-harmful.rst index efc640cac596..4fff9a59b548 100644 --- a/Documentation/translations/it_IT/process/volatile-considered-harmful.rst +++ b/Documentation/translations/it_IT/process/volatile-considered-harmful.rst @@ -119,9 +119,9 @@ concorrenza siano stati opportunamente considerati. Riferimenti =========== -[1] http://lwn.net/Articles/233481/ +[1] https://lwn.net/Articles/233481/ -[2] http://lwn.net/Articles/233482/ +[2] https://lwn.net/Articles/233482/ Crediti ======= diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst index 9b0b3436dfcf..8d856ebe873c 100644 --- a/Documentation/translations/ja_JP/howto.rst +++ b/Documentation/translations/ja_JP/howto.rst @@ -167,7 +167,7 @@ linux-api@vger.kernel.org ã«é€ã‚‹ã“ã¨ã‚’勧ã‚ã¾ã™ã€‚ ã“ã®ãƒ‰ã‚ュメント㯠Linux 開発ã®æ€æƒ³ã‚’ç†è§£ã™ã‚‹ã®ã«éžå¸¸ã«é‡è¦ã§ã™ã€‚ ãã—ã¦ã€ä»–ã®OSã§ã®é–‹ç™ºè€…㌠Linux ã«ç§»ã‚‹æ™‚ã«ã¨ã¦ã‚‚é‡è¦ã§ã™ã€‚ - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` ã‚‚ã— Linux カーãƒãƒ«ã§ã‚»ã‚ュリティå•é¡Œã‚’発見ã—ãŸã‚ˆã†ã«æ€ã£ãŸã‚‰ã€ã“ ã®ãƒ‰ã‚ュメントã®ã‚¹ãƒ†ãƒƒãƒ—ã«å¾“ã£ã¦ã‚«ãƒ¼ãƒãƒ«é–‹ç™ºè€…ã«é€£çµ¡ã—ã€å•é¡Œè§£æ±ºã‚’ 支æ´ã—ã¦ãã ã•ã„。 diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst index 969e91a95bb0..34f14899c155 100644 --- a/Documentation/translations/ko_KR/howto.rst +++ b/Documentation/translations/ko_KR/howto.rst @@ -157,7 +157,7 @@ mtk.manpages@gmail.comì˜ ë©”ì¸í…Œì´ë„ˆì—게 보낼 ê²ƒì„ ê¶Œìž¥í•œë‹¤. 리눅스로 ì „í–¥í•˜ëŠ” 사람들ì—게는 매우 중요하다. - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` ì—¬ëŸ¬ë¶„ë“¤ì´ ë¦¬ëˆ…ìŠ¤ 커ë„ì˜ ë³´ì•ˆ ë¬¸ì œë¥¼ ë°œê²¬í–ˆë‹¤ê³ ìƒê°í•œë‹¤ë©´ ì´ ë¬¸ì„œì— ë‚˜ì˜¨ ë‹¨ê³„ì— ë”°ë¼ì„œ ì»¤ë„ ê°œë°œìžë“¤ì—게 ì•Œë¦¬ê³ ê·¸ ë¬¸ì œë¥¼ í•´ê²°í• ìˆ˜ 있ë„ë¡ ë„와 달ë¼. diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst index f9818d687b54..f1629738b49d 100644 --- a/Documentation/translations/sp_SP/howto.rst +++ b/Documentation/translations/sp_SP/howto.rst @@ -135,7 +135,7 @@ de obligada lectura: de Linux y es muy importante para las personas que se mudan a Linux tras desarrollar otros sistemas operativos. - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` Si cree que ha encontrado un problema de seguridad en el kernel de Linux, siga los pasos de este documento para ayudar a notificar a los desarrolladores del kernel y ayudar a resolver el problema. diff --git a/Documentation/translations/sp_SP/memory-barriers.txt b/Documentation/translations/sp_SP/memory-barriers.txt index f62bd797216d..27097a808c88 100644 --- a/Documentation/translations/sp_SP/memory-barriers.txt +++ b/Documentation/translations/sp_SP/memory-barriers.txt @@ -604,7 +604,7 @@ READ_ONCE() para DEC Alpha, lo que significa que las únicas personas que necesitan prestar atención a esta sección son aquellas que trabajan en el código especÃfico de la arquitectura DEC Alpha y aquellas que trabajan en READ_ONCE() por dentro. Para aquellos que lo necesitan, y para aquellos que -estén interesados ​​desde un punto de vista histórico, aquà está la historia +estén interesados desde un punto de vista histórico, aquà está la historia de las barreras de dependencia de dirección. [!] Si bien las dependencias de direcciones se observan tanto en carga a diff --git a/Documentation/translations/sp_SP/process/deprecated.rst b/Documentation/translations/sp_SP/process/deprecated.rst new file mode 100644 index 000000000000..d52120e0d753 --- /dev/null +++ b/Documentation/translations/sp_SP/process/deprecated.rst @@ -0,0 +1,381 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/process/deprecated.rst <deprecated>` +:Translator: Sergio Gonzalez <sergio.collado@gmail.com> + +.. _sp_deprecated: + +============================================================================ +Interfaces obsoletos, CaracterÃsticas del lenguaje, Atributos y Convenciones +============================================================================ + +En un mundo perfecto, serÃa posible convertir todas las instancias de +alguna API obsoleta en una nueva API y quitar la API anterior en un +único ciclo de desarrollo. Desafortunadamente, debido al tamaño del kernel, +la jerarquÃa de mantenimiento, y el tiempo, no siempre es posible hacer +estos cambios de una única vez. Esto significa que las nuevas instancias +han de ir creándose en el kernel, mientras que las antiguas se quitan, +haciendo que la cantidad de trabajo para limpiar las APIs crezca. Para +informar a los desarrolladores sobre qué ha sido declarado obsoleto y por +qué, ha sido creada esta lista como un lugar donde indicar cuando los usos +obsoletos son propuestos para incluir en el kernel. + +__deprecated +------------ +Mientras que este atributo señala visualmente que un interface ha sido +declarado obsoleto, este `no produce más avisos durante las compilaciones +<https://git.kernel.org/linus/771c035372a036f83353eef46dbb829780330234>`_ +porque uno de los objetivos del kernel es que compile sin avisos, y +nadie ha hecho nada para quitar estos interfaces obsoletos. Mientras +que usar `__deprecated` es sencillo para anotar una API obsoleta en +un archivo de cabecera, no es la solución completa. Dichos interfaces +deben o bien ser quitados por completo, o añadidos a este archivo para +desanimar a otros a usarla en el futuro. + +BUG() y BUG_ON() +---------------- +Use WARN() y WARN_ON() en su lugar, y gestione las condiciones de error +"imposibles" tan elegantemente como se pueda. Mientras que la familia de +funciones BUG() fueron originalmente diseñadas para actuar como una +"situación imposible", confirmar y disponer de un hilo del kernel de forma +"segura", estas funciones han resultado ser demasiado arriesgadas. (e.g. +"¿en qué orden se necesitan liberar los locks? ¿Se han restaurado sus +estados?). La popular función BUG() desestabilizará el sistema o lo romperá +totalmente, lo cual hace imposible depurarlo o incluso generar reportes de +crash. Linus tiene una `opinión muy fuerte +<https://lore.kernel.org/lkml/CA+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO=82SPKCpLQ@mail.gmail.com/>`_ +y sentimientos `sobre esto +<https://lore.kernel.org/lkml/CAHk-=whDHsbK3HTOpTF=ue_o04onRwTEaK_ZoJp_fjbqq4+=Jw@mail.gmail.com/>`_. + +Nótese que la familia de funciones WARN() únicamente deberÃa ser usada +en situaciones que se "esperan no sean alcanzables". Si se quiere +avisar sobre situaciones "alcanzables pero no deseadas", úsese la familia +de funciones pr_warn(). Los responsables del sistema pueden haber definido +*panic_on_warn* sysctl para asegurarse que sus sistemas no continúan +ejecutándose en presencia del condiciones "no alcanzables". (Por ejemplo, +véase commits como `este +<https://git.kernel.org/linus/d4689846881d160a4d12a514e991a740bcb5d65a>`_.) + +Operaciones aritméticas en los argumentos de reserva de memoria +--------------------------------------------------------------- +Los cálculos dinámicos de tamaño (especialmente multiplicaciones) no +deberÃan realizarse en los argumentos de reserva de memoria (o similares) +debido al riesgo de desbordamiento. Esto puede llevar a valores rotando y +que se realicen reservas de memoria menores que las que se esperaban. El +uso de esas reservas puede llevar a desbordamientos en el 'heap' de memoria +y otros funcionamientos incorrectos. (Una excepción a esto son los valores +literales donde el compilador si puede avisar si estos puede desbordarse. +De todos modos, el método recomendado en estos caso es reescribir el código +como se sugiere a continuación para evitar las operaciones aritméticas en +la reserva de memoria.) + +Por ejemplo, no utilice `count * size`` como argumento, como en:: + + foo = kmalloc(count * size, GFP_KERNEL); + +En vez de eso, utilice la reserva con dos argumentos:: + + foo = kmalloc_array(count, size, GFP_KERNEL); + +EspecÃficamente, kmalloc() puede ser sustituido con kmalloc_array(), +kzalloc() puede ser sustituido con kcalloc(). + +Si no existen funciones con dos argumentos, utilice las funciones que se +saturan, en caso de desbordamiento:: + + bar = vmalloc(array_size(count, size)); + +Otro caso común a evitar es calcular el tamaño de una estructura com +la suma de otras estructuras, como en:: + + header = kzalloc(sizeof(*header) + count * sizeof(*header->item), + GFP_KERNEL); + +En vez de eso emplee:: + + header = kzalloc(struct_size(header, item, count), GFP_KERNEL); + +.. note:: Si se usa struct_size() en una estructura que contiene un elemento + de longitud cero o un array de un único elemento como un array miembro, + por favor reescribir ese uso y cambiar a un `miembro array flexible + <#zero-length-and-one-element-arrays>`_ + + +Para otros cálculos, por favor use las funciones de ayuda: size_mul(), +size_add(), and size_sub(). Por ejemplo, en el caso de:: + + foo = krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL); + +Re-escrÃbase, como:: + + foo = krealloc(size_add(current_size, + size_mul(chunk_size, + size_sub(count, 3))), GFP_KERNEL); + +Para más detalles, mire también array3_size() y flex_array_size(), +como también la familia de funciones relacionadas check_mul_overflow(), +check_add_overflow(), check_sub_overflow(), y check_shl_overflow(). + + +simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull() +---------------------------------------------------------------------- +Las funciones: simple_strtol(), simple_strtoll(), simple_strtoul(), y +simple_strtoull() explÃcitamente ignoran los desbordamientos, lo que puede +llevar a resultados inesperados por las funciones que las llaman. Las +funciones respectivas kstrtol(), kstrtoll(), kstrtoul(), y kstrtoull() +tienden a ser reemplazos correctos, aunque nótese que necesitarán que la +cadena de caracteres termine en NUL o en el carácter de lÃnea nueva. + + +strcpy() +-------- +strcpy() no realiza verificaciones de los lÃmites del buffer de destino. +Esto puede resultar en desbordamientos lineals más allá del fin del buffer, +causando todo tipo de errores. Mientras `CONFIG_FORTIFY_SOURCE=y` otras +varias opciones de compilación reducen el riesgo de usar esta función, no +hay ninguna buena razón para añadir nuevos usos de esta. El remplazo seguro +es la función strscpy(), aunque se ha de tener cuidado con cualquier caso +en el el valor retornado por strcpy() sea usado, ya que strscpy() no +devuelve un puntero a el destino, sino el número de caracteres no nulos +compilados (o el valor negativo de errno cuando se trunca la cadena de +caracteres). + +strncpy() en cadenas de caracteres terminadas en NUL +---------------------------------------------------- +El uso de strncpy() no garantiza que el buffer de destino esté terminado en +NUL. Esto puede causar varios errores de desbordamiento en lectura y otros +tipos de funcionamiento erróneo debido a que falta la terminación en NUL. +Esta función también termina la cadena de caracteres en NUL en el buffer de +destino si la cadena de origen es más corta que el buffer de destino, lo +cual puede ser una penalización innecesaria para funciones usen esta +función con cadenas de caracteres que sà están terminadas en NUL. + +Cuando se necesita que la cadena de destino sea terminada en NUL, +el mejor reemplazo es usar la función strscpy(), aunque se ha de tener +cuidado en los casos en los que el valor de strncpy() fuera usado, ya que +strscpy() no devuelve un puntero al destino, sino el número de +caracteres no nulos copiados (o el valor negativo de errno cuando se trunca +la cadena de caracteres). Cualquier caso restante que necesitase todavÃa +ser terminado en el caracter nulo, deberÃa usar strscpy_pad(). + +Si una función usa cadenas de caracteres que no necesitan terminar en NUL, +deberÃa usarse strtomem(), y el destino deberÃa señalarse con el atributo +`__nonstring +<https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_ +para evitar avisos futuros en el compilador. Para casos que todavÃa +necesitan cadenas de caracteres que se rellenen al final con el +caracter NUL, usar strtomem_pad(). + +strlcpy() +--------- +strlcpy() primero lee por completo el buffer de origen (ya que el valor +devuelto intenta ser el mismo que el de strlen()). Esta lectura puede +sobrepasar el lÃmite de tamaño del destino. Esto ineficiente y puede causar +desbordamientos de lectura si la cadena de origen no está terminada en el +carácter NUL. El reemplazo seguro de esta función es strscpy(), pero se ha +de tener cuidado que en los casos en lso que se usase el valor devuelto de +strlcpy(), ya que strscpy() devolverá valores negativos de erno cuando se +produzcan truncados. + +Especificación de formato %p +---------------------------- +Tradicionalmente,el uso de "%p" en el formato de cadenas de caracteres +resultarÃa en exponer esas direcciones en dmesg, proc, sysfs, etc. En vez +de dejar que sean una vulnerabilidad, todos los "%p" que se usan en el +kernel se imprimen como un hash, haciéndolos efectivamente inutilizables +para usarlos como direcciones de memoria. Nuevos usos de "%p" no deberÃan +ser añadidos al kernel. Para textos de direcciones, usar "%pS" es +mejor, ya que resulta en el nombre del sÃmbolo. Para prácticamente el +resto de casos, mejor no usar "%p" en absoluto. + +Parafraseando las actuales `direcciones de Linus <https://lore.kernel.org/lkml/CA+55aFwQEd_d40g4mUCSsVRZzrFPUJt74vc6PPpb675hYNXcKw@mail.gmail.com/>`_: + +- Si el valor "hasheado" "%p" no tienen ninguna finalidad, preguntarse si el + puntero es realmente importante. ¿Quizás se podrÃa quitar totalmente? +- Si realmente se piensa que el valor del puntero es importante, ¿porqué + algún estado del sistema o nivel de privilegio de usuario es considerado + "especial"? Si piensa que puede justificarse (en comentarios y mensajes + del commit), de forma suficiente como para pasar el escrutinio de Linux, + quizás pueda usar el "%p", a la vez que se asegura que tiene los permisos + correspondientes. + +Si está depurando algo donde el "%p" hasheado está causando problemas, +se puede arrancar temporalmente con la opción de depuración "`no_hash_pointers +<https://git.kernel.org/linus/5ead723a20e0447bc7db33dc3070b420e5f80aa6>`_". + + +Arrays de longitud variable (VLAs) +---------------------------------- +Usando VLA en la pila (stack) produce un código mucho peor que los arrays +de tamaño estático. Mientras que estos errores no triviales de `rendimiento +<https://git.kernel.org/linus/02361bc77888>`_ son razón suficiente +para no usar VLAs, esto además son un riesgo de seguridad. El crecimiento +dinámico del array en la pila, puede exceder la memoria restante en +el segmento de la pila. Esto podrÃa llevara a un fallo, posible sobre-escritura +de contenido al final de la pila (cuando se construye sin +`CONFIG_THREAD_INFO_IN_TASK=y`), o sobre-escritura de la memoria adyacente +a la pila (cuando se construye sin `CONFIG_VMAP_STACK=y`). + + +Switch case fall-through implÃcito +---------------------------------- +El lenguaje C permite a las sentencias 'switch' saltar de un caso al +siguiente caso cuando la sentencia de ruptura "break" no aparece al final +del caso. Esto, introduce ambigüedad en el código, ya que no siempre está +claro si el 'break' que falta es intencionado o un olvido. Por ejemplo, no +es obvio solamente mirando al código si `STATE_ONE` está escrito para +intencionadamente saltar en `STATE_TWO`:: + + switch (value) { + case STATE_ONE: + do_something(); + case STATE_TWO: + do_other(); + break; + default: + WARN("unknown state"); + } + +Ya que ha habido una larga lista de defectos `debidos a declaraciones de "break" +que faltan <https://cwe.mitre.org/data/definitions/484.html>`_, no se +permiten 'fall-through' implÃcitos. Para identificar 'fall-through' +intencionados, se ha adoptado la pseudo-palabra-clave macro "falltrhrough", +que expande las extensiones de gcc `__attribute__((__fallthrough__)) +<https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html>`_. +(Cuando la sintaxis de C17/c18 `[[fallthrough]]` sea más comúnmente +soportadas por los compiladores de C, analizadores estáticos, e IDEs, +se puede cambiar a usar esa sintaxis para esa pseudo-palabra-clave. + +Todos los bloques switch/case deben acabar en uno de: + +* break; +* fallthrough; +* continue; +* goto <label>; +* return [expression]; + + +Arrays de longitud cero y un elemento +------------------------------------- +Hay una necesidad habitual en el kernel de proveer una forma para declarar +un grupo de elementos consecutivos de tamaño dinámico en una estructura. +El código del kernel deberÃa usar siempre `"miembros array flexible" <https://en.wikipedia.org/wiki/Flexible_array_member>`_ +en estos casos. El estilo anterior de arrays de un elemento o de longitud +cero, no deben usarse más. + +En el código C más antiguo, los elementos finales de tamaño dinámico se +obtenÃan especificando un array de un elemento al final de una estructura:: + + struct something { + size_t count; + struct foo items[1]; + }; + +En código C más antiguo, elementos seguidos de tamaño dinámico eran creados +especificando una array de un único elemento al final de una estructura:: + + struct something { + size_t count; + struct foo items[1]; + }; + +Esto llevó a resultados incorrectos en los cálculos de tamaño mediante +sizeof() (el cual hubiera necesitado eliminar el tamaño del último elemento +para tener un tamaño correcto de la "cabecera"). Una `extensión de GNU C +<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_ se empezó a usar +para permitir los arrays de longitud cero, para evitar estos tipos de +problemas de tamaño:: + + struct something { + size_t count; + struct foo items[0]; + }; + +Pero esto llevó a otros problemas, y no solucionó algunos otros problemas +compartidos por ambos estilos, como no ser capaz de detectar cuando ese array +accidentalmente _no_ es usado al final de la estructura (lo que podÃa pasar +directamente, o cuando dicha estructura era usada en uniones, estructuras +de estructuras, etc). + +C99 introdujo "los arrays miembros flexibles", los cuales carecen de un +tamaño numérico en su declaración del array:: + + struct something { + size_t count; + struct foo items[]; + }; + +Esta es la forma en la que el kernel espera que se declaren los elementos +de tamaño dinámico concatenados. Esto permite al compilador generar +errores, cuando el array flexible no es declarado en el último lugar de la +estructura, lo que ayuda a prevenir errores en él código del tipo +`comportamiento indefinido <https://git.kernel.org/linus/76497732932f15e7323dc805e8ea8dc11bb587cf>`_. +Esto también permite al compilador analizar correctamente los tamaños de +los arrays (via sizeof(), `CONFIG_FORTIFY_SOURCE`, y `CONFIG_UBSAN_BOUNDS`). +Por ejemplo, si no hay un mecanismo que avise que el siguiente uso de +sizeof() en un array de longitud cero, siempre resulta en cero:: + + struct something { + size_t count; + struct foo items[0]; + }; + + struct something *instance; + + instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); + instance->count = count; + + size = sizeof(instance->items) * instance->count; + memcpy(instance->items, source, size); + +En la última lÃnea del código anterior, ``zero`` vale ``cero``, cuando uno +podrÃa esperar que representa el tamaño total en bytes de la memoria dinámica +reservada para el array consecutivo ``items``. Aquà hay un par de ejemplos +más sobre este tema: `link 1 +<https://git.kernel.org/linus/f2cd32a443da694ac4e28fbf4ac6f9d5cc63a539>`_, +`link 2 +<https://git.kernel.org/linus/ab91c2a89f86be2898cee208d492816ec238b2cf>`_. +Sin embargo, los array de miembros flexibles tienen un type incompleto, y +no se ha de aplicar el operador sizeof()<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_, +asà cualquier mal uso de dichos operadores será detectado inmediatamente en +el momento de compilación. + +Con respecto a los arrays de un único elemento, se ha de ser consciente de +que dichos arrays ocupan al menos tanto espacio como un único objeto del +tipo https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_, de ahà que +estos contribuyan al tamaño de la estructura que los contiene. Esto es +proclive a errores cada vez que se quiere calcular el tamaño total de la +memoria dinámica para reservar una estructura que contenga un array de este +tipo como su miembro:: + + struct something { + size_t count; + struct foo items[1]; + }; + + struct something *instance; + + instance = kmalloc(struct_size(instance, items, count - 1), GFP_KERNEL); + instance->count = count; + + size = sizeof(instance->items) * instance->count; + memcpy(instance->items, source, size); + +En el ejemplo anterior, hemos de recordar calcular ``count - 1``, cuando se +usa la función de ayuda struct_size(), de otro modo estarÃamos +--desintencionadamente--reservando memoria para un ``items`` de más. La +forma más clara y menos proclive a errores es implementar esto mediante el +uso de `array miembro flexible`, junto con las funciones de ayuda: +struct_size() y flex_array_size():: + + struct something { + size_t count; + struct foo items[]; + }; + + struct something *instance; + + instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); + instance->count = count; + + memcpy(instance->items, source, flex_array_size(instance, items, instance->count)); diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst index 0f1e131b3bb1..3b0c32593726 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -18,3 +18,4 @@ email-clients magic-number programming-language + deprecated diff --git a/Documentation/translations/sp_SP/process/magic-number.rst b/Documentation/translations/sp_SP/process/magic-number.rst index 2b62cec34e8e..7c7dfb4ba80b 100644 --- a/Documentation/translations/sp_SP/process/magic-number.rst +++ b/Documentation/translations/sp_SP/process/magic-number.rst @@ -77,7 +77,6 @@ PG_MAGIC 'P' pg_{read,write}_hdr ``include/linux/ APM_BIOS_MAGIC 0x4101 apm_user ``arch/x86/kernel/apm_32.c`` FASYNC_MAGIC 0x4601 fasync_struct ``include/linux/fs.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` -MGSLPC_MAGIC 0x5402 mgslpc_info ``drivers/char/pcmcia/synclink_cs.c`` BAYCOM_MAGIC 0x19730510 baycom_state ``drivers/net/baycom_epp.c`` HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state ``include/linux/hdlcdrv.h`` KV_MAGIC 0x5f4b565f kernel_vars_s ``arch/mips/include/asm/sn/klkernvars.h`` diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rst b/Documentation/translations/sp_SP/process/submitting-patches.rst index bf95ceb5e865..c2757d9ab216 100644 --- a/Documentation/translations/sp_SP/process/submitting-patches.rst +++ b/Documentation/translations/sp_SP/process/submitting-patches.rst @@ -276,7 +276,7 @@ parche a security@kernel.org. Para errores graves, se debe mantener un poco de discreción y permitir que los distribuidores entreguen el parche a los usuarios; en esos casos, obviamente, el parche no debe enviarse a ninguna lista pública. Revise también -Documentation/admin-guide/security-bugs.rst. +Documentation/process/security-bugs.rst. Los parches que corrigen un error grave en un kernel en uso deben dirigirse hacia los maintainers estables poniendo una lÃnea como esta:: diff --git a/Documentation/translations/zh_CN/accounting/delay-accounting.rst b/Documentation/translations/zh_CN/accounting/delay-accounting.rst index a01dc3d5b0db..7b8693ccf80a 100644 --- a/Documentation/translations/zh_CN/accounting/delay-accounting.rst +++ b/Documentation/translations/zh_CN/accounting/delay-accounting.rst @@ -92,15 +92,15 @@ getdelayså‘½ä»¤çš„ä¸€èˆ¬æ ¼å¼:: CPU count real total virtual total delay total delay average 8 7000000 6872122 3382277 0.423ms IO count delay total delay average - 0 0 0ms + 0 0 0.000ms SWAP count delay total delay average - 0 0 0ms + 0 0 0.000ms RECLAIM count delay total delay average - 0 0 0ms + 0 0 0.000ms THRASHING count delay total delay average - 0 0 0ms + 0 0 0.000ms COMPACT count delay total delay average - 0 0 0ms + 0 0 0.000ms WPCOPY count delay total delay average 0 0 0ms diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst index 812ef315c8f6..03d33c710604 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst @@ -250,7 +250,7 @@ LRU的优先级的æå‡ï¼ŒåŒæ—¶é™ä½Žé‚£äº›è¶…过120ç§’æ— äººè®¿é—®çš„å†…å˜åŒ ç†è¢«é™åˆ¶åœ¨æœ€å¤š1%çš„CPU以é¿å…DAMON_LRU_SORT消费过多CPU时间。在系统空闲内å˜è¶…过50% æ—¶DAMON_LRU_SORTåœæ¢å·¥ä½œï¼Œå¹¶åœ¨ä½ŽäºŽ40%æ—¶é‡æ–°å¼€å§‹å·¥ä½œã€‚如果DAMON_RECLAIM没有å–å¾— 进展且空闲内å˜ä½ŽäºŽ20%，å†æ¬¡è®©DAMON_LRU_SORTåœæ¢å·¥ä½œï¼Œä»¥æ¤å›žé€€åˆ°ä»¥LRU链表为基础 -以页é¢ä¸ºå•ä½çš„内å˜å›žæ”¶ä¸Šã€‚ +以页é¢ä¸ºå•ä½çš„内å˜å›žæ”¶ä¸Šã€‚ :: # cd /sys/modules/damon_lru_sort/parameters # echo 500 > hot_thres_access_freq diff --git a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst index b8120391755d..d6b8f8a4e7f6 100644 --- a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst +++ b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :doc:`../../../admin-guide/security-bugs` +:Original: :doc:`../../../process/security-bugs` :译者: diff --git a/Documentation/translations/zh_CN/arch.rst b/Documentation/translations/zh_CN/arch/index.rst index 690e173d8b2a..908ea131bb1c 100644 --- a/Documentation/translations/zh_CN/arch.rst +++ b/Documentation/translations/zh_CN/arch/index.rst @@ -8,12 +8,12 @@ .. toctree:: :maxdepth: 2 - mips/index - arm64/index - riscv/index + ../mips/index + ../arm64/index + ../riscv/index openrisc/index parisc/index - loongarch/index + ../loongarch/index TODOList: diff --git a/Documentation/translations/zh_CN/openrisc/index.rst b/Documentation/translations/zh_CN/arch/openrisc/index.rst index 9ad6cc600884..da21f8ab894b 100644 --- a/Documentation/translations/zh_CN/openrisc/index.rst +++ b/Documentation/translations/zh_CN/arch/openrisc/index.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/openrisc/index.rst +:Original: Documentation/arch/openrisc/index.rst :翻译: diff --git a/Documentation/translations/zh_CN/openrisc/openrisc_port.rst b/Documentation/translations/zh_CN/arch/openrisc/openrisc_port.rst index b8a67670492d..cadc580fa23b 100644 --- a/Documentation/translations/zh_CN/openrisc/openrisc_port.rst +++ b/Documentation/translations/zh_CN/arch/openrisc/openrisc_port.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/openrisc/openrisc_port.rst +:Original: Documentation/arch/openrisc/openrisc_port.rst :翻译: diff --git a/Documentation/translations/zh_CN/openrisc/todo.rst b/Documentation/translations/zh_CN/arch/openrisc/todo.rst index 63c38717edb1..1f6f95616633 100644 --- a/Documentation/translations/zh_CN/openrisc/todo.rst +++ b/Documentation/translations/zh_CN/arch/openrisc/todo.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/openrisc/todo.rst +:Original: Documentation/arch/openrisc/todo.rst :翻译: diff --git a/Documentation/translations/zh_CN/parisc/debugging.rst b/Documentation/translations/zh_CN/arch/parisc/debugging.rst index 68b73eb57105..c6b9de6d3175 100644 --- a/Documentation/translations/zh_CN/parisc/debugging.rst +++ b/Documentation/translations/zh_CN/arch/parisc/debugging.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/parisc/debugging.rst +:Original: Documentation/arch/parisc/debugging.rst :翻译: diff --git a/Documentation/translations/zh_CN/parisc/index.rst b/Documentation/translations/zh_CN/arch/parisc/index.rst index 0cc553fc8272..9f69283bd1c9 100644 --- a/Documentation/translations/zh_CN/parisc/index.rst +++ b/Documentation/translations/zh_CN/arch/parisc/index.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/parisc/index.rst +:Original: Documentation/arch/parisc/index.rst :翻译: diff --git a/Documentation/translations/zh_CN/parisc/registers.rst b/Documentation/translations/zh_CN/arch/parisc/registers.rst index d2ab1874a602..a55250afcc27 100644 --- a/Documentation/translations/zh_CN/parisc/registers.rst +++ b/Documentation/translations/zh_CN/arch/parisc/registers.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/parisc/registers.rst +:Original: Documentation/arch/parisc/registers.rst :翻译: diff --git a/Documentation/translations/zh_CN/core-api/kernel-api.rst b/Documentation/translations/zh_CN/core-api/kernel-api.rst index a4b373c48c0c..a1ea7081077c 100644 --- a/Documentation/translations/zh_CN/core-api/kernel-api.rst +++ b/Documentation/translations/zh_CN/core-api/kernel-api.rst @@ -226,7 +226,7 @@ kernel/relay.c 该APIåœ¨ä»¥ä¸‹å†…æ ¸ä»£ç ä¸: -kernel/kmod.c +kernel/module/kmod.c 模å—接å£æ”¯æŒ ------------ diff --git a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst index 74fa473bb504..84ce2322fdba 100644 --- a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst +++ b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst @@ -219,7 +219,6 @@ GPIO 值的命令需è¦ç‰å¾…其信æ¯æŽ’到队首æ‰å‘é€å‘½ä»¤ï¼Œå†èŽ·å¾—å…¶ ## gpio_free_array() gpio_free() - gpio_set_debounce() @@ -654,25 +653,6 @@ GPIO 控制器的路径类似 /sys/class/gpio/gpiochip42/ (对于从#42 GPIO 确定给定信å·æ‰€ç”¨çš„ GPIO ç¼–å·ã€‚ -ä»Žå†…æ ¸ä»£ç ä¸å¯¼å‡º ----------------- - -å†…æ ¸ä»£ç å¯ä»¥æ˜Žç¡®åœ°ç®¡ç†é‚£äº›å·²é€šè¿‡ gpio_request()申请的 GPIO 的导出:: - - /* 导出 GPIO 到用户空间 */ - int gpio_export(unsigned gpio, bool direction_may_change); - - /* gpio_export()的逆æ“作 */ - void gpio_unexport(); - -åœ¨ä¸€ä¸ªå†…æ ¸é©±åŠ¨ç”³è¯·ä¸€ä¸ª GPIO 之åŽï¼Œå®ƒå¯ä»¥é€šè¿‡ gpio_export()使其在 sysfs -接å£ä¸å¯è§ã€‚该驱动å¯ä»¥æŽ§åˆ¶ä¿¡å·æ–¹å‘是å¦å¯ä¿®æ”¹ã€‚这有助于防æ¢ç”¨æˆ·ç©ºé—´ä»£ç æ— æ„é—´ -ç ´åé‡è¦çš„系统状æ€ã€‚ - -这个明确的导出有助于(通过使æŸäº›å®žéªŒæ›´å®¹æ˜“æ¥)调试，也å¯ä»¥æ供一个始终å˜åœ¨çš„接å£ï¼Œ -与文档é…åˆä½œä¸ºæ¿çº§æ”¯æŒåŒ…的一部分。 - - APIå‚考 ======= diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt b/Documentation/translations/zh_CN/filesystems/sysfs.txt index 046cc1d52058..547062759e60 100644 --- a/Documentation/translations/zh_CN/filesystems/sysfs.txt +++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt @@ -329,8 +329,8 @@ void device_remove_file(struct device *dev, const struct device_attribute * attr struct bus_attribute { struct attribute attr; - ssize_t (*show)(struct bus_type *, char * buf); - ssize_t (*store)(struct bus_type *, const char * buf, size_t count); + ssize_t (*show)(const struct bus_type *, char * buf); + ssize_t (*store)(const struct bus_type *, const char * buf, size_t count); }; 声明: diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 7c3216845b71..299704c0818d 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -120,7 +120,7 @@ TODOList: .. toctree:: :maxdepth: 2 - arch + arch/index 其他文档 -------- diff --git a/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst b/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst index c1fa35315d8b..b7a0544224ad 100644 --- a/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst +++ b/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst @@ -15,7 +15,8 @@ Hugetlbfs 预留 概述 ==== -Documentation/mm/hugetlbpage.rst ä¸æ述的巨页通常是预先分é…给应用程åºä½¿ç”¨çš„。如果VMA指 +Documentation/admin-guide/mm/hugetlbpage.rst +ä¸æ述的巨页通常是预先分é…给应用程åºä½¿ç”¨çš„ 。如果VMA指 示è¦ä½¿ç”¨å·¨é¡µï¼Œè¿™äº›å·¨é¡µä¼šåœ¨ç¼ºé¡µå¼‚常时被实例化到任务的地å€ç©ºé—´ã€‚如果在缺页异常 时没有巨页å˜åœ¨ï¼Œä»»åŠ¡å°±ä¼šè¢«å‘é€ä¸€ä¸ªSIGBUS，并ç»å¸¸ä¸é«˜å…´åœ°æ»åŽ»ã€‚åœ¨åŠ å…¥å·¨é¡µæ”¯ æŒåŽä¸ä¹…，人们决定，在mmap()时检测巨页的çŸç¼ºæƒ…况会更好。这个想法是，如果 diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst index 10254751df6a..cc47be356dd3 100644 --- a/Documentation/translations/zh_CN/process/howto.rst +++ b/Documentation/translations/zh_CN/process/howto.rst @@ -125,7 +125,7 @@ Linuxå†…æ ¸ä»£ç ä¸åŒ…å«æœ‰å¤§é‡çš„文档。这些文档对于å¦ä¹ 如何与 这篇文档对于ç†è§£Linuxçš„å¼€å‘哲å¦è‡³å…³é‡è¦ã€‚对于将开å‘å¹³å°ä»Žå…¶ä»–æ“作系 统转移到Linux的人æ¥è¯´ä¹Ÿå¾ˆé‡è¦ã€‚ - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` å¦‚æžœä½ è®¤ä¸ºè‡ªå·±å‘现了Linuxå†…æ ¸çš„å®‰å…¨æ€§é—®é¢˜ï¼Œè¯·æ ¹æ®è¿™ç¯‡æ–‡æ¡£ä¸çš„æ¥éª¤æ¥ æé†’å…¶ä»–å†…æ ¸å¼€å‘者并帮助解决这个问题。 diff --git a/Documentation/translations/zh_CN/process/magic-number.rst b/Documentation/translations/zh_CN/process/magic-number.rst index 0617ce125e12..37ed33034134 100644 --- a/Documentation/translations/zh_CN/process/magic-number.rst +++ b/Documentation/translations/zh_CN/process/magic-number.rst @@ -61,7 +61,6 @@ PG_MAGIC 'P' pg_{read,write}_hdr ``include/linux/ APM_BIOS_MAGIC 0x4101 apm_user ``arch/x86/kernel/apm_32.c`` FASYNC_MAGIC 0x4601 fasync_struct ``include/linux/fs.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` -MGSLPC_MAGIC 0x5402 mgslpc_info ``drivers/char/pcmcia/synclink_cs.c`` BAYCOM_MAGIC 0x19730510 baycom_state ``drivers/net/baycom_epp.c`` HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state ``include/linux/hdlcdrv.h`` KV_MAGIC 0x5f4b565f kernel_vars_s ``arch/mips/include/asm/sn/klkernvars.h`` diff --git a/Documentation/translations/zh_CN/scheduler/sched-arch.rst b/Documentation/translations/zh_CN/scheduler/sched-arch.rst index 754a15c6b60f..ce3f39d9b3cb 100644 --- a/Documentation/translations/zh_CN/scheduler/sched-arch.rst +++ b/Documentation/translations/zh_CN/scheduler/sched-arch.rst @@ -70,7 +70,5 @@ arch/x86/kernel/process.c有轮询和ç¡çœ 空闲函数的例å。 ia64 - safe_halt的调用与ä¸æ–相比，是å¦å¾ˆè’谬？ (它ç¡çœ 了å—) (å‚考 #4a) -sh64 - ç¡çœ 与ä¸æ–相比，是å¦å¾ˆè’谬？ (å‚考 #4a) - sparc - 在这一点上，IRQ是开ç€çš„（？），把local_irq_save改为_disable。 - 待办事项: 需è¦ç¬¬äºŒä¸ªCPUæ¥ç¦ç”¨æŠ¢å (å‚考 #1) diff --git a/Documentation/translations/zh_CN/scheduler/sched-capacity.rst b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst index e07ffdd391d3..8cba135dcd1a 100644 --- a/Documentation/translations/zh_CN/scheduler/sched-capacity.rst +++ b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst @@ -231,7 +231,7 @@ CFS调度类基于实体负载跟踪机制（Per-Entity Load Tracking, PELTï¼‰ç» å½“å‰ï¼ŒLinuxæ— æ³•å‡è‡ªèº«ç®—出CPUç®—åŠ›ï¼Œå› æ¤å¿…é¡»è¦æœ‰æŠŠè¿™ä¸ªä¿¡æ¯ä¼ 递给Linuxçš„æ–¹å¼ã€‚æ¯ä¸ªæž¶æž„å¿…é¡»ä¸ºæ¤ å®šä¹‰arch_scale_cpu_capacity()函数。 -armå’Œarm64架构直接把这个信æ¯æ˜ 射到arch_topology驱动的CPU scalingæ•°æ®ä¸ï¼ˆè¯‘注：å‚考 +armã€arm64å’ŒRISC-V架构直接把这个信æ¯æ˜ 射到arch_topology驱动的CPU scalingæ•°æ®ä¸ï¼ˆè¯‘注：å‚考 arch_topology.hçš„percpuå˜é‡cpu_scale），它是从capacity-dmips-mhz CPU bindingä¸è¡ç”Ÿè®¡ç®— 出æ¥çš„。å‚è§Documentation/devicetree/bindings/cpu/cpu-capacity.txt。 diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst index eed260ef0c37..15f8e9005071 100644 --- a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst +++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_TW.rst -:Original: :doc:`../../../admin-guide/security-bugs` +:Original: :doc:`../../../process/security-bugs` :è¯è€…: diff --git a/Documentation/translations/zh_TW/filesystems/sysfs.txt b/Documentation/translations/zh_TW/filesystems/sysfs.txt index acd677f19d4f..280824cc7e5d 100644 --- a/Documentation/translations/zh_TW/filesystems/sysfs.txt +++ b/Documentation/translations/zh_TW/filesystems/sysfs.txt @@ -332,8 +332,8 @@ void device_remove_file(struct device *dev, const struct device_attribute * attr struct bus_attribute { struct attribute attr; - ssize_t (*show)(struct bus_type *, char * buf); - ssize_t (*store)(struct bus_type *, const char * buf, size_t count); + ssize_t (*show)(const struct bus_type *, char * buf); + ssize_t (*store)(const struct bus_type *, const char * buf, size_t count); }; è²æ˜Ž: diff --git a/Documentation/translations/zh_TW/gpio.txt b/Documentation/translations/zh_TW/gpio.txt index 1b986bbb0909..62e560ffe628 100644 --- a/Documentation/translations/zh_TW/gpio.txt +++ b/Documentation/translations/zh_TW/gpio.txt @@ -226,7 +226,6 @@ GPIO 值的命令需è¦ç‰å¾…其信æ¯æŽ’到隊首æ‰ç™¼é€å‘½ä»¤ï¼Œå†ç²å¾—å…¶ ## gpio_free_array() gpio_free() - gpio_set_debounce() @@ -615,21 +614,3 @@ GPIO 控制器的路徑類似 /sys/class/gpio/gpiochip42/ (å°æ–¼å¾ž#42 GPIO 固定的,例如在擴展å¡ä¸Šçš„ GPIOæœƒæ ¹æ“šæ‰€ä½¿ç”¨çš„ä¸»æ¿æˆ–æ‰€åœ¨å †ç–Šæž¶æ§‹ä¸å…¶ä»–çš„æ¿å而 有所ä¸åŒã€‚在這種情æ³ä¸‹,ä½ å¯èƒ½éœ€è¦ä½¿ç”¨ gpiochip 節點(儘å¯èƒ½åœ°çµåˆé›»è·¯åœ–)來 確定給定信號所用的 GPIO 編號。 - - -å¾žå…§æ ¸ä»£ç¢¼ä¸å°Žå‡º -------------- -å…§æ ¸ä»£ç¢¼å¯ä»¥æ˜Žç¢ºåœ°ç®¡ç†é‚£äº›å·²é€šéŽ gpio_request()申請的 GPIO 的導出: - - /* 導出 GPIO 到用戶空間 */ - int gpio_export(unsigned gpio, bool direction_may_change); - - /* gpio_export()的逆æ“作 */ - void gpio_unexport(); - -åœ¨ä¸€å€‹å…§æ ¸é©…å‹•ç”³è«‹ä¸€å€‹ GPIO 之後，它å¯ä»¥é€šéŽ gpio_export()使其在 sysfs -接å£ä¸å¯è¦‹ã€‚該驅動å¯ä»¥æŽ§åˆ¶ä¿¡è™Ÿæ–¹å‘是å¦å¯ä¿®æ”¹ã€‚這有助於防æ¢ç”¨æˆ¶ç©ºé–“代碼無æ„é–“ -ç ´å£žé‡è¦çš„系統狀態。 - -這個明確的導出有助於(通éŽä½¿æŸäº›å¯¦é©—更容易來)調試，也å¯ä»¥æ供一個始終å˜åœ¨çš„接å£ï¼Œ -與文檔é…åˆä½œçˆ²æ¿ç´šæ”¯æŒåŒ…的一部分。 diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst index 8fb8edcaee66..ea2f468d3e58 100644 --- a/Documentation/translations/zh_TW/process/howto.rst +++ b/Documentation/translations/zh_TW/process/howto.rst @@ -128,7 +128,7 @@ Linuxå…§æ ¸ä»£ç¢¼ä¸åŒ…å«æœ‰å¤§é‡çš„文檔。這些文檔å°æ–¼å¸ç¿’如何與 這篇文檔å°æ–¼ç†è§£Linux的開發哲å¸è‡³é—œé‡è¦ã€‚å°æ–¼å°‡é–‹ç™¼å¹³å°å¾žå…¶ä»–æ“作系 統轉移到Linux的人來說也很é‡è¦ã€‚ - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` å¦‚æžœä½ èªçˆ²è‡ªå·±ç™¼ç¾äº†Linuxå…§æ ¸çš„å®‰å…¨æ€§å•é¡Œï¼Œè«‹æ ¹æ“šé€™ç¯‡æ–‡æª”ä¸çš„æ¥é©Ÿä¾† æé†’å…¶ä»–å…§æ ¸é–‹ç™¼è€…ä¸¦å¹«åŠ©è§£æ±ºé€™å€‹å•é¡Œã€‚ diff --git a/Documentation/translations/zh_TW/process/magic-number.rst b/Documentation/translations/zh_TW/process/magic-number.rst index f3f7082e17c6..1d48e1bbf5f2 100644 --- a/Documentation/translations/zh_TW/process/magic-number.rst +++ b/Documentation/translations/zh_TW/process/magic-number.rst @@ -64,7 +64,6 @@ PG_MAGIC 'P' pg_{read,write}_hdr ``include/linux/ APM_BIOS_MAGIC 0x4101 apm_user ``arch/x86/kernel/apm_32.c`` FASYNC_MAGIC 0x4601 fasync_struct ``include/linux/fs.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` -MGSLPC_MAGIC 0x5402 mgslpc_info ``drivers/char/pcmcia/synclink_cs.c`` BAYCOM_MAGIC 0x19730510 baycom_state ``drivers/net/baycom_epp.c`` HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state ``include/linux/hdlcdrv.h`` KV_MAGIC 0x5f4b565f kernel_vars_s ``arch/mips/include/asm/sn/klkernvars.h`` diff --git a/Documentation/usb/gadget_uvc.rst b/Documentation/usb/gadget_uvc.rst new file mode 100644 index 000000000000..62bd81ba3dd1 --- /dev/null +++ b/Documentation/usb/gadget_uvc.rst @@ -0,0 +1,380 @@ +======================= +Linux UVC Gadget Driver +======================= + +Overview +-------- +The UVC Gadget driver is a driver for hardware on the *device* side of a USB +connection. It is intended to run on a Linux system that has USB device-side +hardware such as boards with an OTG port. + +On the device system, once the driver is bound it appears as a V4L2 device with +the output capability. + +On the host side (once connected via USB cable), a device running the UVC Gadget +driver *and controlled by an appropriate userspace program* should appear as a UVC +specification compliant camera, and function appropriately with any program +designed to handle them. The userspace program running on the device system can +queue image buffers from a variety of sources to be transmitted via the USB +connection. Typically this would mean forwarding the buffers from a camera sensor +peripheral, but the source of the buffer is entirely dependent on the userspace +companion program. + +Configuring the device kernel +----------------------------- +The Kconfig options USB_CONFIGFS, USB_LIBCOMPOSITE, USB_CONFIGFS_F_UVC and +USB_F_UVC must be selected to enable support for the UVC gadget. + +Configuring the gadget through configfs +--------------------------------------- +The UVC Gadget expects to be configured through configfs using the UVC function. +This allows a significant degree of flexibility, as many of a UVC device's +settings can be controlled this way. + +Not all of the available attributes are described here. For a complete enumeration +see Documentation/ABI/testing/configfs-usb-gadget-uvc + +Assumptions +~~~~~~~~~~~ +This section assumes that you have mounted configfs at `/sys/kernel/config` and +created a gadget as `/sys/kernel/config/usb_gadget/g1`. + +The UVC Function +~~~~~~~~~~~~~~~~ + +The first step is to create the UVC function: + +.. code-block:: bash + + # These variables will be assumed throughout the rest of the document + CONFIGFS="/sys/kernel/config" + GADGET="$CONFIGFS/usb_gadget/g1" + FUNCTION="$GADGET/functions/uvc.0" + + mkdir -p $FUNCTION + +Formats and Frames +~~~~~~~~~~~~~~~~~~ + +You must configure the gadget by telling it which formats you support, as well +as the frame sizes and frame intervals that are supported for each format. In +the current implementation there is no way for the gadget to refuse to set a +format that the host instructs it to set, so it is important that this step is +completed *accurately* to ensure that the host never asks for a format that +can't be provided. + +Formats are created under the streaming/uncompressed and streaming/mjpeg configfs +groups, with the framesizes created under the formats in the following +structure: + +:: + + uvc.0 + + | + + streaming + + | + + mjpeg + + | | + | + mjpeg + + | | + | + 720p + | | + | + 1080p + | + + uncompressed + + | + + yuyv + + | + + 720p + | + + 1080p + +Each frame can then be configured with a width and height, plus the maximum +buffer size required to store a single frame, and finally with the supported +frame intervals for that format and framesize. Width and height are enumerated in +units of pixels, frame interval in units of 100ns. To create the structure +above with 2, 15 and 100 fps frameintervals for each framesize for example you +might do: + +.. code-block:: bash + + create_frame() { + # Example usage: + # create_frame <width> <height> <group> <format name> + + WIDTH=$1 + HEIGHT=$2 + FORMAT=$3 + NAME=$4 + + wdir=$FUNCTION/streaming/$FORMAT/$NAME/${HEIGHT}p + + mkdir -p $wdir + echo $WIDTH > $wdir/wWidth + echo $HEIGHT > $wdir/wHeight + echo $(( $WIDTH * $HEIGHT * 2 )) > $wdir/dwMaxVideoFrameBufferSize + cat <<EOF > $wdir/dwFrameInterval + 666666 + 100000 + 5000000 + EOF + } + + create_frame 1280 720 mjpeg mjpeg + create_frame 1920 1080 mjpeg mjpeg + create_frame 1280 720 uncompressed yuyv + create_frame 1920 1080 uncompressed yuyv + +The only uncompressed format currently supported is YUYV, which is detailed at +Documentation/userspace-api/media/v4l/pixfmt-packed.yuv.rst. + +Color Matching Descriptors +~~~~~~~~~~~~~~~~~~~~~~~~~~ +It's possible to specify some colometry information for each format you create. +This step is optional, and default information will be included if this step is +skipped; those default values follow those defined in the Color Matching Descriptor +section of the UVC specification. + +To create a Color Matching Descriptor, create a configfs item and set its three +attributes to your desired settings and then link to it from the format you wish +it to be associated with: + +.. code-block:: bash + + # Create a new Color Matching Descriptor + + mkdir $FUNCTION/streaming/color_matching/yuyv + pushd $FUNCTION/streaming/color_matching/yuyv + + echo 1 > bColorPrimaries + echo 1 > bTransferCharacteristics + echo 4 > bMatrixCoefficients + + popd + + # Create a symlink to the Color Matching Descriptor from the format's config item + ln -s $FUNCTION/streaming/color_matching/yuyv $FUNCTION/streaming/uncompressed/yuyv + +For details about the valid values, consult the UVC specification. Note that a +default color matching descriptor exists and is used by any format which does +not have a link to a different Color Matching Descriptor. It's possible to +change the attribute settings for the default descriptor, so bear in mind that if +you do that you are altering the defaults for any format that does not link to +a different one. + + +Header linking +~~~~~~~~~~~~~~ + +The UVC specification requires that Format and Frame descriptors be preceded by +Headers detailing things such as the number and cumulative size of the different +Format descriptors that follow. This and similar operations are acheived in +configfs by linking between the configfs item representing the header and the +config items representing those other descriptors, in this manner: + +.. code-block:: bash + + mkdir $FUNCTION/streaming/header/h + + # This section links the format descriptors and their associated frames + # to the header + cd $FUNCTION/streaming/header/h + ln -s ../../uncompressed/yuyv + ln -s ../../mjpeg/mjpeg + + # This section ensures that the header will be transmitted for each + # speed's set of descriptors. If support for a particular speed is not + # needed then it can be skipped here. + cd ../../class/fs + ln -s ../../header/h + cd ../../class/hs + ln -s ../../header/h + cd ../../class/ss + ln -s ../../header/h + cd ../../../control + mkdir header/h + ln -s header/h class/fs + ln -s header/h class/ss + + +Extension Unit Support +~~~~~~~~~~~~~~~~~~~~~~ + +A UVC Extension Unit (XU) basically provides a distinct unit to which control set +and get requests can be addressed. The meaning of those control requests is +entirely implementation dependent, but may be used to control settings outside +of the UVC specification (for example enabling or disabling video effects). An +XU can be inserted into the UVC unit chain or left free-hanging. + +Configuring an extension unit involves creating an entry in the appropriate +directory and setting its attributes appropriately, like so: + +.. code-block:: bash + + mkdir $FUNCTION/control/extensions/xu.0 + pushd $FUNCTION/control/extensions/xu.0 + + # Set the bUnitID of the Processing Unit as the source for this + # Extension Unit + echo 2 > baSourceID + + # Set this XU as the source of the default output terminal. This inserts + # the XU into the UVC chain between the PU and OT such that the final + # chain is IT > PU > XU.0 > OT + cat bUnitID > ../../terminal/output/default/baSourceID + + # Flag some controls as being available for use. The bmControl field is + # a bitmap with each bit denoting the availability of a particular + # control. For example to flag the 0th, 2nd and 3rd controls available: + echo 0x0d > bmControls + + # Set the GUID; this is a vendor-specific code identifying the XU. + echo -e -n "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10" > guidExtensionCode + + popd + +The bmControls attribute and the baSourceID attribute are multi-value attributes. +This means that you may write multiple newline separated values to them. For +example to flag the 1st, 2nd, 9th and 10th controls as being available you would +need to write two values to bmControls, like so: + +.. code-block:: bash + + cat << EOF > bmControls + 0x03 + 0x03 + EOF + +The multi-value nature of the baSourceID attribute belies the fact that XUs can +be multiple-input, though note that this currently has no significant effect. + +The bControlSize attribute reflects the size of the bmControls attribute, and +similarly bNrInPins reflects the size of the baSourceID attributes. Both +attributes are automatically increased / decreased as you set bmControls and +baSourceID. It is also possible to manually increase or decrease bControlSize +which has the effect of truncating entries to the new size, or padding entries +out with 0x00, for example: + +:: + + $ cat bmControls + 0x03 + 0x05 + + $ cat bControlSize + 2 + + $ echo 1 > bControlSize + $ cat bmControls + 0x03 + + $ echo 2 > bControlSize + $ cat bmControls + 0x03 + 0x00 + +bNrInPins and baSourceID function in the same way. + +Configuring Supported Controls for Camera Terminal and Processing Unit +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The Camera Terminal and Processing Units in the UVC chain also have bmControls +attributes which function similarly to the same field in an Extension Unit. +Unlike XUs however, the meaning of the bitflag for these units is defined in +the UVC specification; you should consult the "Camera Terminal Descriptor" and +"Processing Unit Descriptor" sections for an enumeration of the flags. + +.. code-block:: bash + + # Set the Processing Unit's bmControls, flagging Brightness, Contrast + # and Hue as available controls: + echo 0x05 > $FUNCTION/control/processing/default/bmControls + + # Set the Camera Terminal's bmControls, flagging Focus Absolute and + # Focus Relative as available controls: + echo 0x60 > $FUNCTION/control/terminal/camera/default/bmControls + +If you do not set these fields then by default the Auto-Exposure Mode control +for the Camera Terminal and the Brightness control for the Processing Unit will +be flagged as available; if they are not supported you should set the field to +0x00. + +Note that the size of the bmControls field for a Camera Terminal or Processing +Unit is fixed by the UVC specification, and so the bControlSize attribute is +read-only here. + +Custom Strings Support +~~~~~~~~~~~~~~~~~~~~~~ + +String descriptors that provide a textual description for various parts of a +USB device can be defined in the usual place within USB configfs, and may then +be linked to from the UVC function root or from Extension Unit directories to +assign those strings as descriptors: + +.. code-block:: bash + + # Create a string descriptor in us-EN and link to it from the function + # root. The name of the link is significant here, as it declares this + # descriptor to be intended for the Interface Association Descriptor. + # Other significant link names at function root are vs0_desc and vs1_desc + # For the VideoStreaming Interface 0/1 Descriptors. + + mkdir -p $GADGET/strings/0x409/iad_desc + echo -n "Interface Associaton Descriptor" > $GADGET/strings/0x409/iad_desc/s + ln -s $GADGET/strings/0x409/iad_desc $FUNCTION/iad_desc + + # Because the link to a String Descriptor from an Extension Unit clearly + # associates the two, the name of this link is not significant and may + # be set freely. + + mkdir -p $GADGET/strings/0x409/xu.0 + echo -n "A Very Useful Extension Unit" > $GADGET/strings/0x409/xu.0/s + ln -s $GADGET/strings/0x409/xu.0 $FUNCTION/control/extensions/xu.0 + +The interrupt endpoint +~~~~~~~~~~~~~~~~~~~~~~ + +The VideoControl interface has an optional interrupt endpoint which is by default +disabled. This is intended to support delayed response control set requests for +UVC (which should respond through the interrupt endpoint rather than tying up +endpoint 0). At present support for sending data through this endpoint is missing +and so it is left disabled to avoid confusion. If you wish to enable it you can +do so through the configfs attribute: + +.. code-block:: bash + + echo 1 > $FUNCTION/control/enable_interrupt_ep + +Bandwidth configuration +~~~~~~~~~~~~~~~~~~~~~~~ + +There are three attributes which control the bandwidth of the USB connection. +These live in the function root and can be set within limits: + +.. code-block:: bash + + # streaming_interval sets bInterval. Values range from 1..255 + echo 1 > $FUNCTION/streaming_interval + + # streaming_maxpacket sets wMaxPacketSize. Valid values are 1024/2048/3072 + echo 3072 > $FUNCTION/streaming_maxpacket + + # streaming_maxburst sets bMaxBurst. Valid values are 1..15 + echo 1 > $FUNCTION/streaming_maxburst + + +The values passed here will be clamped to valid values according to the UVC +specification (which depend on the speed of the USB connection). To understand +how the settings influence bandwidth you should consult the UVC specifications, +but a rule of thumb is that increasing the streaming_maxpacket setting will +improve bandwidth (and thus the maximum possible framerate), whilst the same is +true for streaming_maxburst provided the USB connection is running at SuperSpeed. +Increasing streaming_interval will reduce bandwidth and framerate. + +The userspace application +------------------------- +By itself, the UVC Gadget driver cannot do anything particularly interesting. It +must be paired with a userspace program that responds to UVC control requests and +fills buffers to be queued to the V4L2 device that the driver creates. How those +things are achieved is implementation dependent and beyond the scope of this +document, but a reference application can be found at https://gitlab.freedesktop.org/camera/uvc-gadget diff --git a/Documentation/usb/index.rst b/Documentation/usb/index.rst index b656c9be23ed..27955dad95e1 100644 --- a/Documentation/usb/index.rst +++ b/Documentation/usb/index.rst @@ -16,6 +16,7 @@ USB support gadget_multi gadget_printer gadget_serial + gadget_uvc gadget-testing iuu_phoenix mass-storage diff --git a/Documentation/userspace-api/ELF.rst b/Documentation/userspace-api/ELF.rst new file mode 100644 index 000000000000..ac8aeacd458d --- /dev/null +++ b/Documentation/userspace-api/ELF.rst @@ -0,0 +1,34 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +Linux-specific ELF idiosyncrasies +================================= + +Definitions +=========== + +"First" program header is the one with the smallest offset in the file: +e_phoff. + +"Last" program header is the one with the biggest offset in the file: +e_phoff + (e_phnum - 1) * sizeof(Elf_Phdr). + +PT_INTERP +========= + +First PT_INTERP program header is used to locate the filename of ELF +interpreter. Other PT_INTERP headers are ignored (since Linux 2.4.11). + +PT_GNU_STACK +============ + +Last PT_GNU_STACK program header defines userspace stack executability +(since Linux 2.6.6). Other PT_GNU_STACK headers are ignored. + +PT_GNU_PROPERTY +=============== + +ELF interpreter's last PT_GNU_PROPERTY program header is used (since +Linux 5.8). If interpreter doesn't have one, then the last PT_GNU_PROPERTY +program header of an executable is used. Other PT_GNU_PROPERTY headers +are ignored. diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index f16337bdb852..72a65db0c498 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -23,6 +23,7 @@ place where this information is gathered. spec_ctrl accelerators/ocxl ebpf/index + ELF ioctl/index iommu iommufd diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 0a1882e296ae..176e8fc3f31b 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -222,7 +222,6 @@ Code Seq# Include File Comments 'b' 00-FF conflict! bit3 vme host bridge <mailto:natalia@nikhefk.nikhef.nl> 'b' 00-0F linux/dma-buf.h conflict! -'c' all linux/cm4000_cs.h conflict! 'c' 00-7F linux/comstats.h conflict! 'c' 00-7F linux/coda.h conflict! 'c' 00-1F linux/chio.h conflict! diff --git a/Documentation/userspace-api/media/v4l/dev-overlay.rst b/Documentation/userspace-api/media/v4l/dev-overlay.rst index 4f4b23b95b9b..d52977120b41 100644 --- a/Documentation/userspace-api/media/v4l/dev-overlay.rst +++ b/Documentation/userspace-api/media/v4l/dev-overlay.rst @@ -67,6 +67,7 @@ ioctls must be supported by all video overlay devices. Setup ===== +*Note: support for this has been removed.* Before overlay can commence applications must program the driver with frame buffer parameters, namely the address and size of the frame buffer and the image format, for example RGB 5:6:5. The @@ -92,11 +93,13 @@ A driver may support any (or none) of five clipping/blending methods: 1. Chroma-keying displays the overlaid image only where pixels in the primary graphics surface assume a certain color. -2. A bitmap can be specified where each bit corresponds to a pixel in +2. *Note: support for this has been removed.* + A bitmap can be specified where each bit corresponds to a pixel in the overlaid image. When the bit is set, the corresponding video pixel is displayed, otherwise a pixel of the graphics surface. -3. A list of clipping rectangles can be specified. In these regions *no* +3. *Note: support for this has been removed.* + A list of clipping rectangles can be specified. In these regions *no* video is displayed, so the graphics surface can be seen here. 4. The framebuffer has an alpha channel that can be used to clip or @@ -185,6 +188,7 @@ struct v4l2_window be 0xRRGGBB on a little endian, 0xBBGGRR on a big endian host. ``struct v4l2_clip * clips`` + *Note: support for this has been removed.* When chroma-keying has *not* been negotiated and :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability, applications can set this field to point to an array of clipping @@ -201,6 +205,7 @@ struct v4l2_window are undefined. ``__u32 clipcount`` + *Note: support for this has been removed.* When the application set the ``clips`` field, this field must contain the number of clipping rectangles in the list. When clip lists are not supported the driver ignores this field, its contents @@ -208,6 +213,7 @@ struct v4l2_window supported but no clipping is desired this field must be set to zero. ``void * bitmap`` + *Note: support for this has been removed.* When chroma-keying has *not* been negotiated and :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability, applications can set this field to point to a clipping bit mask. diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst index 506dd3c98884..06b78e5589d2 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst @@ -88,6 +88,11 @@ Compressed Formats - ``V4L2_PIX_FMT_H263`` - 'H263' - H263 video elementary stream. + * .. _V4L2-PIX-FMT-SPK: + + - ``V4L2_PIX_FMT_SPK`` + - 'SPK0' + - Sorenson Spark is an implementation of H.263 for use in Flash Video and Adobe Flash files * .. _V4L2-PIX-FMT-MPEG1: - ``V4L2_PIX_FMT_MPEG1`` @@ -232,6 +237,26 @@ Compressed Formats Metadata associated with the frame to decode is required to be passed through the ``V4L2_CID_STATELESS_FWHT_PARAMS`` control. See the :ref:`associated Codec Control ID <codec-stateless-fwht>`. + * .. _V4L2-PIX-FMT-RV30: + + - ``V4L2_PIX_FMT_RV30`` + - 'RV30' + - RealVideo, or also spelled as Real Video, is a suite of + proprietary video compression formats developed by + RealNetworks - the specific format changes with the version. + RealVideo codecs are identified by four-character codes. + RV30 corresponds to RealVideo 8, suspected to be based + largely on an early draft of H.264 + * .. _V4L2-PIX-FMT-RV40: + + - ``V4L2_PIX_FMT_RV40`` + - 'RV40' + - RV40 represents RealVideo 9 and RealVideo 10. + RealVideo 9, suspected to be based on H.264. + RealVideo 10, aka RV9 EHQ, This refers to an improved encoder + for the RV9 format that is fully backwards compatible with + RV9 players - the format and decoder did not change, only + the encoder did. As a result, it uses the same FourCC. .. raw:: latex diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst index 24a771542059..9f111ed594d2 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst @@ -257,6 +257,34 @@ the second byte and Y'\ :sub:`7-0` in the third byte. - The padding bits contain undefined values that must be ignored by all applications and drivers. +The next table lists the packed YUV 4:4:4 formats with 12 bits per component. +Expand the bits per component to 16 bits, data in the high bits, zeros in the low bits, +arranged in little endian order, storing 1 pixel in 6 bytes. + +.. flat-table:: Packed YUV 4:4:4 Image Formats (12bpc) + :header-rows: 1 + :stub-columns: 0 + + * - Identifier + - Code + - Byte 1-0 + - Byte 3-2 + - Byte 5-4 + - Byte 7-6 + - Byte 9-8 + - Byte 11-10 + + * .. _V4L2-PIX-FMT-YUV48-12: + + - ``V4L2_PIX_FMT_YUV48_12`` + - 'Y312' + + - Y'\ :sub:`0` + - Cb\ :sub:`0` + - Cr\ :sub:`0` + - Y'\ :sub:`1` + - Cb\ :sub:`1` + - Cr\ :sub:`1` 4:2:2 Subsampling ================= diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst index d330aeb4d3eb..b71b80d634d6 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst @@ -778,7 +778,7 @@ number of bits for each component. \tiny \setlength{\tabcolsep}{2pt} -.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| +.. tabularcolumns:: |p{3.2cm}|p{0.8cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| .. flat-table:: RGB Formats 10 Bits Per Color Component @@ -868,7 +868,6 @@ number of bits for each component. - r\ :sub:`4` - r\ :sub:`3` - r\ :sub:`2` - - * .. _V4L2-PIX-FMT-RGBA1010102: - ``V4L2_PIX_FMT_RGBA1010102`` @@ -909,7 +908,6 @@ number of bits for each component. - r\ :sub:`4` - r\ :sub:`3` - r\ :sub:`2` - - * .. _V4L2-PIX-FMT-ARGB2101010: - ``V4L2_PIX_FMT_ARGB2101010`` @@ -950,12 +948,53 @@ number of bits for each component. - r\ :sub:`6` - r\ :sub:`5` - r\ :sub:`4` - - .. raw:: latex \endgroup +12 Bits Per Component +============================== + +These formats store an RGB triplet in six or eight bytes, with 12 bits per component. +Expand the bits per component to 16 bits, data in the high bits, zeros in the low bits, +arranged in little endian order. + +.. raw:: latex + + \small + +.. flat-table:: RGB Formats With 12 Bits Per Component + :header-rows: 1 + + * - Identifier + - Code + - Byte 1-0 + - Byte 3-2 + - Byte 5-4 + - Byte 7-6 + * .. _V4L2-PIX-FMT-BGR48-12: + + - ``V4L2_PIX_FMT_BGR48_12`` + - 'B312' + + - B\ :sub:`15-4` + - G\ :sub:`15-4` + - R\ :sub:`15-4` + - + * .. _V4L2-PIX-FMT-ABGR64-12: + + - ``V4L2_PIX_FMT_ABGR64_12`` + - 'B412' + + - B\ :sub:`15-4` + - G\ :sub:`15-4` + - R\ :sub:`15-4` + - A\ :sub:`15-4` + +.. raw:: latex + + \normalsize Deprecated RGB Formats ====================== diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst index 62078a01de76..cf8e4dfbfbd4 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst @@ -103,6 +103,17 @@ are often referred to as greyscale formats. - ... - ... + * .. _V4L2-PIX-FMT-Y012: + + - ``V4L2_PIX_FMT_Y012`` + - 'Y012' + + - Y'\ :sub:`0`\ [3:0] `0000` + - Y'\ :sub:`0`\ [11:4] + - ... + - ... + - ... + * .. _V4L2-PIX-FMT-Y14: - ``V4L2_PIX_FMT_Y14`` @@ -146,3 +157,7 @@ are often referred to as greyscale formats. than 16 bits. For example, 10 bits per pixel uses values in the range 0 to 1023. For the IPU3_Y10 format 25 pixels are packed into 32 bytes, which leaves the 6 most significant bits of the last byte padded with 0. + + For Y012 and Y12 formats, Y012 places its data in the 12 high bits, with + padding zeros in the 4 low bits, in contrast to the Y12 format, which has + its padding located in the most significant bits of the 16 bit word. diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index f1d5bb7b806d..72324274f20c 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -123,6 +123,20 @@ All components are stored with the same number of bits per component. - Cb, Cr - Yes - 4x4 tiles + * - V4L2_PIX_FMT_P012 + - 'P012' + - 12 + - 4:2:0 + - Cb, Cr + - Yes + - Linear + * - V4L2_PIX_FMT_P012M + - 'PM12' + - 12 + - 4:2:0 + - Cb, Cr + - No + - Linear * - V4L2_PIX_FMT_NV16 - 'NV16' - 8 @@ -586,6 +600,86 @@ Data in the 10 high bits, zeros in the 6 low bits, arranged in little endian ord - Cb\ :sub:`11` - Cr\ :sub:`11` +.. _V4L2-PIX-FMT-P012: +.. _V4L2-PIX-FMT-P012M: + +P012 and P012M +-------------- + +P012 is like NV12 with 12 bits per component, expanded to 16 bits. +Data in the 12 high bits, zeros in the 4 low bits, arranged in little endian order. + +.. flat-table:: Sample 4x4 P012 Image + :header-rows: 0 + :stub-columns: 0 + + * - start + 0: + - Y'\ :sub:`00` + - Y'\ :sub:`01` + - Y'\ :sub:`02` + - Y'\ :sub:`03` + * - start + 8: + - Y'\ :sub:`10` + - Y'\ :sub:`11` + - Y'\ :sub:`12` + - Y'\ :sub:`13` + * - start + 16: + - Y'\ :sub:`20` + - Y'\ :sub:`21` + - Y'\ :sub:`22` + - Y'\ :sub:`23` + * - start + 24: + - Y'\ :sub:`30` + - Y'\ :sub:`31` + - Y'\ :sub:`32` + - Y'\ :sub:`33` + * - start + 32: + - Cb\ :sub:`00` + - Cr\ :sub:`00` + - Cb\ :sub:`01` + - Cr\ :sub:`01` + * - start + 40: + - Cb\ :sub:`10` + - Cr\ :sub:`10` + - Cb\ :sub:`11` + - Cr\ :sub:`11` + +.. flat-table:: Sample 4x4 P012M Image + :header-rows: 0 + :stub-columns: 0 + + * - start0 + 0: + - Y'\ :sub:`00` + - Y'\ :sub:`01` + - Y'\ :sub:`02` + - Y'\ :sub:`03` + * - start0 + 8: + - Y'\ :sub:`10` + - Y'\ :sub:`11` + - Y'\ :sub:`12` + - Y'\ :sub:`13` + * - start0 + 16: + - Y'\ :sub:`20` + - Y'\ :sub:`21` + - Y'\ :sub:`22` + - Y'\ :sub:`23` + * - start0 + 24: + - Y'\ :sub:`30` + - Y'\ :sub:`31` + - Y'\ :sub:`32` + - Y'\ :sub:`33` + * - + * - start1 + 0: + - Cb\ :sub:`00` + - Cr\ :sub:`00` + - Cb\ :sub:`01` + - Cr\ :sub:`01` + * - start1 + 8: + - Cb\ :sub:`10` + - Cr\ :sub:`10` + - Cb\ :sub:`11` + - Cr\ :sub:`11` + Fully Planar YUV Formats ======================== diff --git a/Documentation/userspace-api/media/v4l/user-func.rst b/Documentation/userspace-api/media/v4l/user-func.rst index 228c1521f190..15ff0bf7bbe6 100644 --- a/Documentation/userspace-api/media/v4l/user-func.rst +++ b/Documentation/userspace-api/media/v4l/user-func.rst @@ -72,6 +72,7 @@ Function Reference vidioc-subdev-g-frame-interval vidioc-subdev-g-routing vidioc-subdev-g-selection + vidioc-subdev-g-client-cap vidioc-subdev-querycap vidioc-subscribe-event func-mmap 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 892cfeb8b988..5292d5e1a91f 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -185,6 +185,16 @@ still cause this situation. - ``p_u32`` - A pointer to a matrix control of unsigned 32-bit values. Valid if this control is of type ``V4L2_CTRL_TYPE_U32``. + * - __u32 * + - ``p_s32`` + - A pointer to a matrix control of signed 32-bit values. Valid if + this control is of type ``V4L2_CTRL_TYPE_INTEGER`` and + ``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is set. + * - __u32 * + - ``p_s64`` + - A pointer to a matrix control of signed 64-bit values. Valid if + this control is of type ``V4L2_CTRL_TYPE_INTEGER64`` and + ``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is set. * - struct :c:type:`v4l2_area` * - ``p_area`` - A pointer to a struct :c:type:`v4l2_area`. Valid if this control is diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst b/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst index b6cc1a823207..b651e53643dd 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst @@ -49,6 +49,9 @@ of a graphics card. A non-destructive overlay blends video images into a VGA signal or graphics into a video signal. *Video Output Overlays* are always non-destructive. +Destructive overlay support has been removed: with modern GPUs and CPUs +this is no longer needed, and it was always a very dangerous feature. + To get the current parameters applications call the :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` ioctl with a pointer to a struct :c:type:`v4l2_framebuffer` structure. The driver fills all fields of the structure or returns an @@ -63,18 +66,12 @@ this structure, the driver prepares for the overlay and returns the framebuffer parameters as :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` does, or it returns an error code. -To set the parameters for a *non-destructive Video Overlay*, +To set the parameters for a *Video Capture Overlay* applications must initialize the ``flags`` field, the ``fmt`` substructure, and call :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. Again the driver prepares for the overlay and returns the framebuffer parameters as :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` does, or it returns an error code. -For a *destructive Video Overlay* applications must additionally provide -a ``base`` address. Setting up a DMA to a random memory location can -jeopardize the system security, its stability or even damage the -hardware, therefore only the superuser can set the parameters for a -destructive video overlay. - .. tabularcolumns:: |p{3.5cm}|p{3.5cm}|p{3.5cm}|p{6.6cm}| .. c:type:: v4l2_framebuffer @@ -100,17 +97,14 @@ destructive video overlay. - ``base`` - - Physical base address of the framebuffer, that is the address of - the pixel in the top left corner of the framebuffer. [#f1]_ - * - - - - - - - This field is irrelevant to *non-destructive Video Overlays*. For - *destructive Video Overlays* applications must provide a base - address. The driver may accept only base addresses which are a - multiple of two, four or eight bytes. For *Video Output Overlays* - the driver must return a valid base address, so applications can + the pixel in the top left corner of the framebuffer. + For :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` this field is no longer supported + and the kernel will always set this to NULL. + For *Video Output Overlays* + the driver will return a valid base address, so applications can find the corresponding Linux framebuffer device (see - :ref:`osd`). + :ref:`osd`). For *Video Capture Overlays* this field will always be + NULL. * - struct - ``fmt`` - @@ -136,8 +130,7 @@ destructive video overlay. * - - - - - For *destructive Video Overlays* applications must initialize this - field. For *Video Output Overlays* the driver must return a valid + - For *Video Output Overlays* the driver must return a valid format. * - - @@ -165,13 +158,6 @@ destructive video overlay. This field is irrelevant to *non-destructive Video Overlays*. - For *destructive Video Overlays* both applications and drivers can - set this field to request padding bytes at the end of each line. - Drivers however may ignore the requested value, returning - ``width`` times bytes-per-pixel or a larger value required by the - hardware. That implies applications can just set this field to - zero to get a reasonable default. - For *Video Output Overlays* the driver must return a valid value. Video hardware may access padding bytes, therefore they must @@ -190,9 +176,8 @@ destructive video overlay. * - - __u32 - ``sizeimage`` - - This field is irrelevant to *non-destructive Video Overlays*. For - *destructive Video Overlays* applications must initialize this - field. For *Video Output Overlays* the driver must return a valid + - This field is irrelevant to *non-destructive Video Overlays*. + For *Video Output Overlays* the driver must return a valid format. Together with ``base`` it defines the framebuffer memory @@ -232,9 +217,11 @@ destructive video overlay. * - ``V4L2_FBUF_CAP_LIST_CLIPPING`` - 0x0004 - The device supports clipping using a list of clip rectangles. + Note that this is no longer supported. * - ``V4L2_FBUF_CAP_BITMAP_CLIPPING`` - 0x0008 - The device supports clipping using a bit mask. + Note that this is no longer supported. * - ``V4L2_FBUF_CAP_LOCAL_ALPHA`` - 0x0010 - The device supports clipping/blending using the alpha channel of @@ -342,10 +329,3 @@ EPERM EINVAL The :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` parameters are unsuitable. - -.. [#f1] - A physical base address may not suit all platforms. GK notes in - theory we should pass something like PCI device + memory region + - offset instead. If you encounter problems please discuss on the - linux-media mailing list: - `https://linuxtv.org/lists.php <https://linuxtv.org/lists.php>`__. diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst index 3ef361c0dca7..e3ae84df5486 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst @@ -31,18 +31,30 @@ Arguments Description =========== -This ioctl allows applications to enumerate all frame sizes supported by -a sub-device on the given pad for the given media bus format. Supported -formats can be retrieved with the +This ioctl allows applications to access the enumeration of frame sizes +supported by a sub-device on the specified pad +for the specified media bus format. +Supported formats can be retrieved with the :ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE` ioctl. -To enumerate frame sizes applications initialize the ``pad``, ``which`` -, ``code`` and ``index`` fields of the struct -:c:type:`v4l2_subdev_mbus_code_enum` and -call the :ref:`VIDIOC_SUBDEV_ENUM_FRAME_SIZE` ioctl with a pointer to the -structure. Drivers fill the minimum and maximum frame sizes or return an -EINVAL error code if one of the input parameters is invalid. +The enumerations are defined by the driver, and indexed using the ``index`` field +of the struct :c:type:`v4l2_subdev_frame_size_enum`. +Each pair of ``pad`` and ``code`` correspond to a separate enumeration. +Each enumeration starts with the ``index`` of 0, and +the lowest invalid index marks the end of the enumeration. + +Therefore, to enumerate frame sizes allowed on the specified pad +and using the specified mbus format, initialize the +``pad``, ``which``, and ``code`` fields to desired values, +and set ``index`` to 0. +Then call the :ref:`VIDIOC_SUBDEV_ENUM_FRAME_SIZE` ioctl with a pointer to the +structure. + +A successful call will return with minimum and maximum frame sizes filled in. +Repeat with increasing ``index`` until ``EINVAL`` is received. +``EINVAL`` means that either no more entries are available in the enumeration, +or that an input parameter was invalid. Sub-devices that only support discrete frame sizes (such as most sensors) will return one or more frame sizes with identical minimum and @@ -72,26 +84,28 @@ information about try formats. * - __u32 - ``index`` - - Number of the format in the enumeration, set by the application. + - Index of the frame size in the enumeration belonging to the given pad + and format. Filled in by the application. * - __u32 - ``pad`` - Pad number as reported by the media controller API. + Filled in by the application. * - __u32 - ``code`` - The media bus format code, as defined in - :ref:`v4l2-mbus-format`. + :ref:`v4l2-mbus-format`. Filled in by the application. * - __u32 - ``min_width`` - - Minimum frame width, in pixels. + - Minimum frame width, in pixels. Filled in by the driver. * - __u32 - ``max_width`` - - Maximum frame width, in pixels. + - Maximum frame width, in pixels. Filled in by the driver. * - __u32 - ``min_height`` - - Minimum frame height, in pixels. + - Minimum frame height, in pixels. Filled in by the driver. * - __u32 - ``max_height`` - - Maximum frame height, in pixels. + - Maximum frame height, in pixels. Filled in by the driver. * - __u32 - ``which`` - Frame sizes to be enumerated, from enum diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst index 248f6f9ee7c5..4ad7dec27e25 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst @@ -31,15 +31,28 @@ Arguments Description =========== -To enumerate media bus formats available at a given sub-device pad -applications initialize the ``pad``, ``which`` and ``index`` fields of -struct -:c:type:`v4l2_subdev_mbus_code_enum` and -call the :ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE` ioctl with a pointer to this -structure. Drivers fill the rest of the structure or return an ``EINVAL`` -error code if either the ``pad`` or ``index`` are invalid. All media bus -formats are enumerable by beginning at index zero and incrementing by -one until ``EINVAL`` is returned. +This call is used by the application to access the enumeration +of media bus formats for the selected pad. + +The enumerations are defined by the driver, and indexed using the ``index`` field +of struct :c:type:`v4l2_subdev_mbus_code_enum`. +Each enumeration starts with the ``index`` of 0, and +the lowest invalid index marks the end of enumeration. + +Therefore, to enumerate media bus formats available at a given sub-device pad, +initialize the ``pad``, and ``which`` fields to desired values, +and set ``index`` to 0. +Then call the :ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE` ioctl +with a pointer to this structure. + +A successful call will return with the ``code`` field filled in +with a mbus code value. +Repeat with increasing ``index`` until ``EINVAL`` is received. +``EINVAL`` means that either ``pad`` is invalid, +or that there are no more codes available at this pad. + +The driver must not return the same value of ``code`` for different indices +at the same pad. Available media bus formats may depend on the current 'try' formats at other pads of the sub-device, as well as on the current active links. @@ -57,14 +70,16 @@ information about the try formats. * - __u32 - ``pad`` - - Pad number as reported by the media controller API. + - Pad number as reported by the media controller API. Filled in by the + application. * - __u32 - ``index`` - - Number of the format in the enumeration, set by the application. + - Index of the mbus code in the enumeration belonging to the given pad. + Filled in by the application. * - __u32 - ``code`` - The media bus format code, as defined in - :ref:`v4l2-mbus-format`. + :ref:`v4l2-mbus-format`. Filled in by the driver. * - __u32 - ``which`` - Media bus format codes to be enumerated, from enum diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst new file mode 100644 index 000000000000..20f12a1cc0f7 --- /dev/null +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later +.. c:namespace:: V4L + +.. _VIDIOC_SUBDEV_G_CLIENT_CAP: + +************************************************************ +ioctl VIDIOC_SUBDEV_G_CLIENT_CAP, VIDIOC_SUBDEV_S_CLIENT_CAP +************************************************************ + +Name +==== + +VIDIOC_SUBDEV_G_CLIENT_CAP - VIDIOC_SUBDEV_S_CLIENT_CAP - Get or set client +capabilities. + +Synopsis +======== + +.. c:macro:: VIDIOC_SUBDEV_G_CLIENT_CAP + +``int ioctl(int fd, VIDIOC_SUBDEV_G_CLIENT_CAP, struct v4l2_subdev_client_capability *argp)`` + +.. c:macro:: VIDIOC_SUBDEV_S_CLIENT_CAP + +``int ioctl(int fd, VIDIOC_SUBDEV_S_CLIENT_CAP, struct v4l2_subdev_client_capability *argp)`` + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() <func-open>`. + +``argp`` + Pointer to struct :c:type:`v4l2_subdev_client_capability`. + +Description +=========== + +These ioctls are used to get and set the client (the application using the +subdevice ioctls) capabilities. The client capabilities are stored in the file +handle of the opened subdev device node, and the client must set the +capabilities for each opened subdev separately. + +By default no client capabilities are set when a subdev device node is opened. + +The purpose of the client capabilities are to inform the kernel of the behavior +of the client, mainly related to maintaining compatibility with different +kernel and userspace versions. + +The ``VIDIOC_SUBDEV_G_CLIENT_CAP`` ioctl returns the current client capabilities +associated with the file handle ``fd``. + +The ``VIDIOC_SUBDEV_S_CLIENT_CAP`` ioctl sets client capabilities for the file +handle ``fd``. The new capabilities fully replace the current capabilities, the +ioctl can therefore also be used to remove capabilities that have previously +been set. + +``VIDIOC_SUBDEV_S_CLIENT_CAP`` modifies the struct +:c:type:`v4l2_subdev_client_capability` to reflect the capabilities that have +been accepted. A common case for the kernel not accepting a capability is that +the kernel is older than the headers the userspace uses, and thus the capability +is unknown to the kernel. + +.. flat-table:: Client Capabilities + :header-rows: 1 + + * - Capability + - Description + * - ``V4L2_SUBDEV_CLIENT_CAP_STREAMS`` + - The client is aware of streams. Setting this flag enables the use + of 'stream' fields (referring to the stream number) with various + ioctls. If this is not set (which is the default), the 'stream' fields + will be forced to 0 by the kernel. + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes <gen-errors>` chapter. + +ENOIOCTLCMD + The kernel does not support this ioctl. diff --git a/Documentation/userspace-api/netlink/genetlink-legacy.rst b/Documentation/userspace-api/netlink/genetlink-legacy.rst index 3bf0bcdf21d8..802875a37a27 100644 --- a/Documentation/userspace-api/netlink/genetlink-legacy.rst +++ b/Documentation/userspace-api/netlink/genetlink-legacy.rst @@ -162,9 +162,91 @@ Other quirks (todo) Structures ---------- -Legacy families can define C structures both to be used as the contents -of an attribute and as a fixed message header. The plan is to define -the structs in ``definitions`` and link the appropriate attrs. +Legacy families can define C structures both to be used as the contents of +an attribute and as a fixed message header. Structures are defined in +``definitions`` and referenced in operations or attributes. Note that +structures defined in YAML are implicitly packed according to C +conventions. For example, the following struct is 4 bytes, not 6 bytes: + +.. code-block:: c + + struct { + u8 a; + u16 b; + u8 c; + } + +Any padding must be explicitly added and C-like languages should infer the +need for explicit padding from whether the members are naturally aligned. + +Here is the struct definition from above, declared in YAML: + +.. code-block:: yaml + + definitions: + - + name: message-header + type: struct + members: + - + name: a + type: u8 + - + name: b + type: u16 + - + name: c + type: u8 + +Fixed Headers +~~~~~~~~~~~~~ + +Fixed message headers can be added to operations using ``fixed-header``. +The default ``fixed-header`` can be set in ``operations`` and it can be set +or overridden for each operation. + +.. code-block:: yaml + + operations: + fixed-header: message-header + list: + - + name: get + fixed-header: custom-header + attribute-set: message-attrs + +Attributes +~~~~~~~~~~ + +A ``binary`` attribute can be interpreted as a C structure using a +``struct`` property with the name of the structure definition. The +``struct`` property implies ``sub-type: struct`` so it is not necessary to +specify a sub-type. + +.. code-block:: yaml + + attribute-sets: + - + name: stats-attrs + attributes: + - + name: stats + type: binary + struct: vport-stats + +C Arrays +-------- + +Legacy families also use ``binary`` attributes to encapsulate C arrays. The +``sub-type`` is used to identify the type of scalar to extract. + +.. code-block:: yaml + + attributes: + - + name: ports + type: binary + sub-type: u32 Multi-message DO ---------------- diff --git a/Documentation/userspace-api/netlink/specs.rst b/Documentation/userspace-api/netlink/specs.rst index 6ffe8137cd90..2e4acde890b7 100644 --- a/Documentation/userspace-api/netlink/specs.rst +++ b/Documentation/userspace-api/netlink/specs.rst @@ -24,6 +24,10 @@ YAML specifications can be found under ``Documentation/netlink/specs/`` This document describes details of the schema. See :doc:`intro-specs` for a practical starting guide. +All specs must be licensed under +``((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)`` +to allow for easy adoption in user space code. + Compatibility levels ==================== @@ -197,9 +201,15 @@ value Numerical attribute ID, used in serialized Netlink messages. The ``value`` property can be skipped, in which case the attribute ID will be the value of the previous attribute plus one (recursively) -and ``0`` for the first attribute in the attribute set. +and ``1`` for the first attribute in the attribute set. + +Attributes (and operations) use ``1`` as the default value for the first +entry (unlike enums in definitions which start from ``0``) because +entry ``0`` is almost always reserved as undefined. Spec can explicitly +set value to ``0`` if needed. -Note that the ``value`` of an attribute is defined only in its main set. +Note that the ``value`` of an attribute is defined only in its main set +(not in subsets). enum ~~~~ @@ -244,6 +254,16 @@ rather than depend on what is specified in the spec file. The validation policy in the kernel is formed by combining the type definition (``type`` and ``nested-attributes``) and the ``checks``. +sub-type +~~~~~~~~ + +Legacy families have special ways of expressing arrays. ``sub-type`` can be +used to define the type of array members in case array members are not +fully defined as attributes (in a bona fide attribute space). For instance +a C array of u32 values can be specified with ``type: binary`` and +``sub-type: u32``. Binary types and legacy array formats are described in +more detail in :doc:`genetlink-legacy`. + operations ---------- diff --git a/Documentation/virt/coco/sev-guest.rst b/Documentation/virt/coco/sev-guest.rst index bf593e88cfd9..68b0d2363af8 100644 --- a/Documentation/virt/coco/sev-guest.rst +++ b/Documentation/virt/coco/sev-guest.rst @@ -37,11 +37,11 @@ along with a description: the return value. General error numbers (-ENOMEM, -EINVAL) are not detailed, but errors with specific meanings are. -The guest ioctl should be issued on a file descriptor of the /dev/sev-guest device. -The ioctl accepts struct snp_user_guest_request. The input and output structure is -specified through the req_data and resp_data field respectively. If the ioctl fails -to execute due to a firmware error, then fw_err code will be set otherwise the -fw_err will be set to 0x00000000000000ff. +The guest ioctl should be issued on a file descriptor of the /dev/sev-guest +device. The ioctl accepts struct snp_user_guest_request. The input and +output structure is specified through the req_data and resp_data field +respectively. If the ioctl fails to execute due to a firmware error, then +the fw_error code will be set, otherwise fw_error will be set to -1. The firmware checks that the message sequence counter is one greater than the guests message sequence counter. If guest driver fails to increment message @@ -57,8 +57,14 @@ counter (e.g. counter overflow), then -EIO will be returned. __u64 req_data; __u64 resp_data; - /* firmware error code on failure (see psp-sev.h) */ - __u64 fw_err; + /* bits[63:32]: VMM error code, bits[31:0] firmware error code (see psp-sev.h) */ + union { + __u64 exitinfo2; + struct { + __u32 fw_error; + __u32 vmm_error; + }; + }; }; 2.1 SNP_GET_REPORT diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 62de0768d6aa..add067793b90 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -5645,7 +5645,8 @@ with the KVM_XEN_VCPU_GET_ATTR ioctl. }; Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The -``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr`` +``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. +``length`` must not be bigger than 2^31 - PAGE_SIZE bytes. The ``addr`` field must point to a buffer which the tags will be copied to or from. ``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or @@ -6029,6 +6030,44 @@ delivery must be provided via the "reg_aen" struct. The "pad" and "reserved" fields may be used for future extensions and should be set to 0s by userspace. +4.138 KVM_ARM_SET_COUNTER_OFFSET +-------------------------------- + +:Capability: KVM_CAP_COUNTER_OFFSET +:Architectures: arm64 +:Type: vm ioctl +:Parameters: struct kvm_arm_counter_offset (in) +:Returns: 0 on success, < 0 on error + +This capability indicates that userspace is able to apply a single VM-wide +offset to both the virtual and physical counters as viewed by the guest +using the KVM_ARM_SET_CNT_OFFSET ioctl and the following data structure: + +:: + + struct kvm_arm_counter_offset { + __u64 counter_offset; + __u64 reserved; + }; + +The offset describes a number of counter cycles that are subtracted from +both virtual and physical counter views (similar to the effects of the +CNTVOFF_EL2 and CNTPOFF_EL2 system registers, but only global). The offset +always applies to all vcpus (already created or created after this ioctl) +for this VM. + +It is userspace's responsibility to compute the offset based, for example, +on previous values of the guest counters. + +Any value other than 0 for the "reserved" field may result in an error +(-EINVAL) being returned. This ioctl can also return -EBUSY if any vcpu +ioctl is issued concurrently. + +Note that using this ioctl results in KVM ignoring subsequent userspace +writes to the CNTVCT_EL0 and CNTPCT_EL0 registers using the SET_ONE_REG +interface. No error will be returned, but the resulting offset will not be +applied. + 5. The kvm_run structure ======================== @@ -6218,15 +6257,40 @@ to the byte array. __u64 nr; __u64 args[6]; __u64 ret; - __u32 longmode; - __u32 pad; + __u64 flags; } hypercall; -Unused. This was once used for 'hypercall to userspace'. To implement -such functionality, use KVM_EXIT_IO (x86) or KVM_EXIT_MMIO (all except s390). + +It is strongly recommended that userspace use ``KVM_EXIT_IO`` (x86) or +``KVM_EXIT_MMIO`` (all except s390) to implement functionality that +requires a guest to interact with host userpace. .. note:: KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO. +For arm64: +---------- + +SMCCC exits can be enabled depending on the configuration of the SMCCC +filter. See the Documentation/virt/kvm/devices/vm.rst +``KVM_ARM_SMCCC_FILTER`` for more details. + +``nr`` contains the function ID of the guest's SMCCC call. Userspace is +expected to use the ``KVM_GET_ONE_REG`` ioctl to retrieve the call +parameters from the vCPU's GPRs. + +Definition of ``flags``: + - ``KVM_HYPERCALL_EXIT_SMC``: Indicates that the guest used the SMC + conduit to initiate the SMCCC call. If this bit is 0 then the guest + used the HVC conduit for the SMCCC call. + + - ``KVM_HYPERCALL_EXIT_16BIT``: Indicates that the guest used a 16bit + instruction to initiate the SMCCC call. If this bit is 0 then the + guest used a 32bit instruction. An AArch64 guest always has this + bit set to 0. + +At the point of exit, PC points to the instruction immediately following +the trapping instruction. + :: /* KVM_EXIT_TPR_ACCESS */ @@ -7266,6 +7330,7 @@ and injected exceptions. will clear DR6.RTM. 7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 +-------------------------------------- :Architectures: x86, arm64, mips :Parameters: args[0] whether feature should be enabled or not @@ -7456,7 +7521,7 @@ system fingerprint. To prevent userspace from circumventing such restrictions by running an enclave in a VM, KVM prevents access to privileged attributes by default. -See Documentation/x86/sgx.rst for more details. +See Documentation/arch/x86/sgx.rst for more details. 7.26 KVM_CAP_PPC_RPT_INVALIDATE ------------------------------- @@ -8296,11 +8361,11 @@ ENOSYS for the others. 8.35 KVM_CAP_PMU_CAPABILITY --------------------------- -:Capability KVM_CAP_PMU_CAPABILITY +:Capability: KVM_CAP_PMU_CAPABILITY :Architectures: x86 :Type: vm :Parameters: arg[0] is bitmask of PMU virtualization capabilities. -:Returns 0 on success, -EINVAL when arg[0] contains invalid bits +:Returns: 0 on success, -EINVAL when arg[0] contains invalid bits This capability alters PMU virtualization in KVM. diff --git a/Documentation/virt/kvm/devices/vm.rst b/Documentation/virt/kvm/devices/vm.rst index 147efec626e5..9d726e60ec47 100644 --- a/Documentation/virt/kvm/devices/vm.rst +++ b/Documentation/virt/kvm/devices/vm.rst @@ -321,3 +321,82 @@ Allows userspace to query the status of migration mode. if it is enabled :Returns: -EFAULT if the given address is not accessible from kernel space; 0 in case of success. + +6. GROUP: KVM_ARM_VM_SMCCC_CTRL +=============================== + +:Architectures: arm64 + +6.1. ATTRIBUTE: KVM_ARM_VM_SMCCC_FILTER (w/o) +--------------------------------------------- + +:Parameters: Pointer to a ``struct kvm_smccc_filter`` + +:Returns: + + ====== =========================================== + EEXIST Range intersects with a previously inserted + or reserved range + EBUSY A vCPU in the VM has already run + EINVAL Invalid filter configuration + ENOMEM Failed to allocate memory for the in-kernel + representation of the SMCCC filter + ====== =========================================== + +Requests the installation of an SMCCC call filter described as follows:: + + enum kvm_smccc_filter_action { + KVM_SMCCC_FILTER_HANDLE = 0, + KVM_SMCCC_FILTER_DENY, + KVM_SMCCC_FILTER_FWD_TO_USER, + }; + + struct kvm_smccc_filter { + __u32 base; + __u32 nr_functions; + __u8 action; + __u8 pad[15]; + }; + +The filter is defined as a set of non-overlapping ranges. Each +range defines an action to be applied to SMCCC calls within the range. +Userspace can insert multiple ranges into the filter by using +successive calls to this attribute. + +The default configuration of KVM is such that all implemented SMCCC +calls are allowed. Thus, the SMCCC filter can be defined sparsely +by userspace, only describing ranges that modify the default behavior. + +The range expressed by ``struct kvm_smccc_filter`` is +[``base``, ``base + nr_functions``). The range is not allowed to wrap, +i.e. userspace cannot rely on ``base + nr_functions`` overflowing. + +The SMCCC filter applies to both SMC and HVC calls initiated by the +guest. The SMCCC filter gates the in-kernel emulation of SMCCC calls +and as such takes effect before other interfaces that interact with +SMCCC calls (e.g. hypercall bitmap registers). + +Actions: + + - ``KVM_SMCCC_FILTER_HANDLE``: Allows the guest SMCCC call to be + handled in-kernel. It is strongly recommended that userspace *not* + explicitly describe the allowed SMCCC call ranges. + + - ``KVM_SMCCC_FILTER_DENY``: Rejects the guest SMCCC call in-kernel + and returns to the guest. + + - ``KVM_SMCCC_FILTER_FWD_TO_USER``: The guest SMCCC call is forwarded + to userspace with an exit reason of ``KVM_EXIT_HYPERCALL``. + +The ``pad`` field is reserved for future use and must be zero. KVM may +return ``-EINVAL`` if the field is nonzero. + +KVM reserves the 'Arm Architecture Calls' range of function IDs and +will reject attempts to define a filter for any portion of these ranges: + + =========== =============== + Start End (inclusive) + =========== =============== + 0x8000_0000 0x8000_FFFF + 0xC000_0000 0xC000_FFFF + =========== =============== diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 14c4e9fa501d..8c77554e4896 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -21,7 +21,7 @@ The acquisition orders for mutexes are as follows: - kvm->mn_active_invalidate_count ensures that pairs of invalidate_range_start() and invalidate_range_end() callbacks use the same memslots array. kvm->slots_lock and kvm->slots_arch_lock - are taken on the waiting side in install_new_memslots, so MMU notifiers + are taken on the waiting side when modifying memslots, so MMU notifiers must not take either kvm->slots_lock or kvm->slots_arch_lock. For SRCU: diff --git a/Documentation/x86/xstate.rst b/Documentation/x86/xstate.rst deleted file mode 100644 index 5cec7fb558d6..000000000000 --- a/Documentation/x86/xstate.rst +++ /dev/null @@ -1,74 +0,0 @@ -Using XSTATE features in user space applications -================================================ - -The x86 architecture supports floating-point extensions which are -enumerated via CPUID. Applications consult CPUID and use XGETBV to -evaluate which features have been enabled by the kernel XCR0. - -Up to AVX-512 and PKRU states, these features are automatically enabled by -the kernel if available. Features like AMX TILE_DATA (XSTATE component 18) -are enabled by XCR0 as well, but the first use of related instruction is -trapped by the kernel because by default the required large XSTATE buffers -are not allocated automatically. - -Using dynamically enabled XSTATE features in user space applications --------------------------------------------------------------------- - -The kernel provides an arch_prctl(2) based mechanism for applications to -request the usage of such features. The arch_prctl(2) options related to -this are: - --ARCH_GET_XCOMP_SUPP - - arch_prctl(ARCH_GET_XCOMP_SUPP, &features); - - ARCH_GET_XCOMP_SUPP stores the supported features in userspace storage of - type uint64_t. The second argument is a pointer to that storage. - --ARCH_GET_XCOMP_PERM - - arch_prctl(ARCH_GET_XCOMP_PERM, &features); - - ARCH_GET_XCOMP_PERM stores the features for which the userspace process - has permission in userspace storage of type uint64_t. The second argument - is a pointer to that storage. - --ARCH_REQ_XCOMP_PERM - - arch_prctl(ARCH_REQ_XCOMP_PERM, feature_nr); - - ARCH_REQ_XCOMP_PERM allows to request permission for a dynamically enabled - feature or a feature set. A feature set can be mapped to a facility, e.g. - AMX, and can require one or more XSTATE components to be enabled. - - The feature argument is the number of the highest XSTATE component which - is required for a facility to work. - -When requesting permission for a feature, the kernel checks the -availability. The kernel ensures that sigaltstacks in the process's tasks -are large enough to accommodate the resulting large signal frame. It -enforces this both during ARCH_REQ_XCOMP_SUPP and during any subsequent -sigaltstack(2) calls. If an installed sigaltstack is smaller than the -resulting sigframe size, ARCH_REQ_XCOMP_SUPP results in -ENOSUPP. Also, -sigaltstack(2) results in -ENOMEM if the requested altstack is too small -for the permitted features. - -Permission, when granted, is valid per process. Permissions are inherited -on fork(2) and cleared on exec(3). - -The first use of an instruction related to a dynamically enabled feature is -trapped by the kernel. The trap handler checks whether the process has -permission to use the feature. If the process has no permission then the -kernel sends SIGILL to the application. If the process has permission then -the handler allocates a larger xstate buffer for the task so the large -state can be context switched. In the unlikely cases that the allocation -fails, the kernel sends SIGSEGV. - -Dynamic features in signal frames ---------------------------------- - -Dynamcally enabled features are not written to the signal frame upon signal -entry if the feature is in its initial configuration. This differs from -non-dynamic features which are always written regardless of their -configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV -field to determine if a features was written. |