diff options
Diffstat (limited to 'Documentation')
948 files changed, 22980 insertions, 7112 deletions
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 282de3680367..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 diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index 3becc9a82bdf..534b7a3d59fc 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -136,6 +136,22 @@ Description: The last executed device administrative command's status/error. Also last configuration error overloaded. Writing to it will clear the status. +What: /sys/bus/dsa/devices/dsa<m>/iaa_cap +Date: Sept 14, 2022 +KernelVersion: 6.0.0 +Contact: dmaengine@vger.kernel.org +Description: IAA (IAX) capability mask. Exported to user space for application + consumption. This attribute should only be visible on IAA devices + that are version 2 or later. + +What: /sys/bus/dsa/devices/dsa<m>/event_log_size +Date: Sept 14, 2022 +KernelVersion: 6.4.0 +Contact: dmaengine@vger.kernel.org +Description: The event log size to be configured. Default is 64 entries and + occupies 4k size if the evl entry is 64 bytes. It's visible + only on platforms that support the capability. + What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault Date: Oct 27, 2020 KernelVersion: 5.11.0 @@ -219,6 +235,16 @@ Contact: dmaengine@vger.kernel.org Description: Indicate whether ATS disable is turned on for the workqueue. 0 indicates ATS is on, and 1 indicates ATS is off for the workqueue. +What: /sys/bus/dsa/devices/wq<m>.<n>/prs_disable +Date: Sept 14, 2022 +KernelVersion: 6.4.0 +Contact: dmaengine@vger.kernel.org +Description: Controls whether PRS disable is turned on for the workqueue. + 0 indicates PRS is on, and 1 indicates PRS is off for the + workqueue. This option overrides block_on_fault attribute + if set. It's visible only on platforms that support the + capability. + What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy Date May 25, 2021 KernelVersion: 5.14.0 @@ -302,3 +328,28 @@ Description: Allows control of the number of batch descriptors that can be 1 (1/2 of max value), 2 (1/4 of the max value), and 3 (1/8 of the max value). It's visible only on platforms that support the capability. + +What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_faults +Date: Sept 14, 2022 +KernelVersion: 6.4.0 +Contact: dmaengine@vger.kernel.org +Description: Show the number of Completion Record (CR) faults this application + has caused. + +What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_fault_failures +Date: Sept 14, 2022 +KernelVersion: 6.4.0 +Contact: dmaengine@vger.kernel.org +Description: Show the number of Completion Record (CR) faults failures that this + application has caused. The failure counter is incremented when the + driver cannot fault in the address for the CR. Typically this is caused + by a bad address programmed in the submitted descriptor or a malicious + submitter is using bad CR address on purpose. + +What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/pid +Date: Sept 14, 2022 +KernelVersion: 6.4.0 +Contact: dmaengine@vger.kernel.org +Description: Show the process id of the application that opened the file. This is + helpful information for a monitor daemon that wants to kill the + application that opened the file. 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-counter b/Documentation/ABI/testing/sysfs-bus-counter index ff83320b4255..1417c4272c6c 100644 --- a/Documentation/ABI/testing/sysfs-bus-counter +++ b/Documentation/ABI/testing/sysfs-bus-counter @@ -1,3 +1,33 @@ +What: /sys/bus/counter/devices/counterX/cascade_counts_enable +KernelVersion: 6.4 +Contact: linux-iio@vger.kernel.org +Description: + Indicates the cascading of Counts on Counter X. + + Valid attribute values are boolean. + +What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select +KernelVersion: 6.4 +Contact: linux-iio@vger.kernel.org +Description: + Selects the external clock pin for phase counting mode of + Counter X. + + MTCLKA-MTCLKB: + MTCLKA and MTCLKB pins are selected for the external + phase clock. + + MTCLKC-MTCLKD: + MTCLKC and MTCLKD pins are selected for the external + phase clock. + +What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_available +KernelVersion: 6.4 +Contact: linux-iio@vger.kernel.org +Description: + Discrete set of available values for the respective device + configuration are listed in this file. + What: /sys/bus/counter/devices/counterX/countY/count KernelVersion: 5.2 Contact: linux-iio@vger.kernel.org @@ -215,6 +245,8 @@ Contact: linux-iio@vger.kernel.org Description: This attribute indicates the number of overflows of count Y. +What: /sys/bus/counter/devices/counterX/cascade_counts_enable_component_id +What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_component_id What: /sys/bus/counter/devices/counterX/countY/capture_component_id What: /sys/bus/counter/devices/counterX/countY/ceiling_component_id What: /sys/bus/counter/devices/counterX/countY/floor_component_id diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 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-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-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/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/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.txt b/Documentation/admin-guide/kernel-parameters.txt index 10e2e5c3ff0b..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. @@ -1579,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) @@ -3326,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. @@ -3570,7 +3612,10 @@ 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. noaliencache [MM, NUMA, SLAB] Disables the allocation of alien @@ -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 @@ -6127,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 @@ -7062,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/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/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/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/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/arch/x86/sva.rst b/Documentation/arch/x86/sva.rst index 2e9b8b0f9a0f..33cb05005982 100644 --- a/Documentation/arch/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/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst index 5cec7fb558d6..ae5c69e48b11 100644 --- a/Documentation/arch/x86/xstate.rst +++ b/Documentation/arch/x86/xstate.rst @@ -11,6 +11,22 @@ 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 -------------------------------------------------------------------- @@ -64,6 +80,61 @@ 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 --------------------------------- @@ -72,3 +143,32 @@ 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/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 b421d94dc9f2..609b71f5747d 100644 --- a/Documentation/bpf/bpf_devel_QA.rst +++ b/Documentation/bpf/bpf_devel_QA.rst @@ -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 @@ -684,7 +689,6 @@ when: .. Links -.. _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/ 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/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/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/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/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 e287dcaec203..ff272e517d57 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -141,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 @@ -153,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/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/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/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/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 4f6ffb8182a9..49304a1476ab 100644 --- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml +++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml @@ -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/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml index 02cc6894eb13..d8b91944180a 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml @@ -1,7 +1,7 @@ # 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# +$id: http://devicetree.org/schemas/cache/qcom,llcc.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Last Level Cache Controller 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/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,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,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 8aa87b8c1b33..c752c8985a53 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml @@ -202,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/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-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/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index b42553ac505c..a1ed1004651b 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -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/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/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 cdeb67bc05f0..70ec70922c13 100644 --- a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml +++ b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml @@ -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/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/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,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/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index bda86e6857f5..8c2a737237f2 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -21,10 +21,9 @@ 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 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,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,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/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/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/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/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/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/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/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/dma/apple,admac.yaml b/Documentation/devicetree/bindings/dma/apple,admac.yaml index 05163d124ec3..ab193bc8bdbb 100644 --- a/Documentation/devicetree/bindings/dma/apple,admac.yaml +++ b/Documentation/devicetree/bindings/dma/apple,admac.yaml @@ -26,6 +26,7 @@ properties: - enum: - apple,t6000-admac - apple,t8103-admac + - apple,t8112-admac - const: apple,admac reg: diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index fc5de7b6f19e..f61145c91b6d 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -24,6 +24,7 @@ properties: - qcom,sm6350-gpi-dma - items: - enum: + - qcom,qcm2290-gpi-dma - qcom,qdu1000-gpi-dma - qcom,sc7280-gpi-dma - qcom,sm6115-gpi-dma diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml index f638d3934e71..c284abc6784a 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml @@ -54,6 +54,11 @@ properties: - description: DMA main clock - description: DMA register access clock + clock-names: + items: + - const: main + - const: register + '#dma-cells': const: 1 description: @@ -77,16 +82,23 @@ properties: - description: Reset for DMA ARESETN reset terminal - description: Reset for DMA RST_ASYNC reset terminal + reset-names: + items: + - const: arst + - const: rst_async + required: - compatible - reg - interrupts - interrupt-names - clocks + - clock-names - '#dma-cells' - dma-channels - power-domains - resets + - reset-names additionalProperties: false @@ -124,9 +136,11 @@ examples: "ch12", "ch13", "ch14", "ch15"; clocks = <&cpg CPG_MOD R9A07G044_DMAC_ACLK>, <&cpg CPG_MOD R9A07G044_DMAC_PCLK>; + clock-names = "main", "register"; power-domains = <&cpg>; resets = <&cpg R9A07G044_DMAC_ARESETN>, <&cpg R9A07G044_DMAC_RST_ASYNC>; + reset-names = "arst", "rst_async"; #dma-cells = <1>; dma-channels = <16>; }; diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml index 5c81194e2300..363cf8bd150d 100644 --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml @@ -20,6 +20,7 @@ properties: enum: - snps,axi-dma-1.01a - intel,kmb-axi-dma + - starfive,jh7110-axi-dma reg: minItems: 1 @@ -58,7 +59,8 @@ properties: maximum: 8 resets: - maxItems: 1 + minItems: 1 + maxItems: 2 snps,dma-masters: description: | @@ -109,6 +111,25 @@ required: - snps,priority - snps,block-size +if: + properties: + compatible: + contains: + enum: + - starfive,jh7110-axi-dma +then: + properties: + resets: + minItems: 2 + items: + - description: AXI reset line + - description: AHB reset line + - description: module reset +else: + properties: + resets: + maxItems: 1 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml index 97f6ae9b1236..22f6c5e2f7f4 100644 --- a/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml +++ b/Documentation/devicetree/bindings/dma/ti/k3-udma.yaml @@ -43,7 +43,7 @@ description: | configuration of the legacy peripheral. allOf: - - $ref: "../dma-controller.yaml#" + - $ref: ../dma-controller.yaml# - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# properties: diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml index c0a1408b12ec..23ada8f87526 100644 --- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml @@ -15,7 +15,7 @@ maintainers: - Michael Tretter <m.tretter@pengutronix.de> allOf: - - $ref: "../dma-controller.yaml#" + - $ref: ../dma-controller.yaml# properties: "#dma-cells": diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml index 825294e3f0e8..d6cbd95ec26d 100644 --- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml @@ -16,7 +16,7 @@ maintainers: - Laurent Pinchart <laurent.pinchart@ideasonboard.com> allOf: - - $ref: "../dma-controller.yaml#" + - $ref: ../dma-controller.yaml# properties: "#dma-cells": 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/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/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/nxp,pcf8575.yaml b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml index f0ff66c4c74e..3718103e966a 100644 --- a/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml +++ b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml @@ -39,6 +39,10 @@ properties: reg: maxItems: 1 + gpio-line-names: + minItems: 1 + maxItems: 16 + gpio-controller: true '#gpio-cells': 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/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/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 3f0e94189f2d..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 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/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/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 4e98261f2948..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 @@ -91,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/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/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index 15e3f6645682..11aedf1650a1 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -90,22 +90,51 @@ properties: - heartbeat # LED indicates disk activity - disk-activity + # LED indicates disk read activity - disk-read + # LED indicates disk write activity - disk-write # LED flashes at a fixed, configurable rate - timer # LED alters the brightness for the specified duration with one software # timer (requires "led-pattern" property) - pattern + # LED indicates mic mute state + - audio-micmute + # LED indicates audio mute state + - audio-mute + # LED indicates bluetooth power state + - bluetooth-power + # LED indicates activity of all CPUs + - cpu + # LED indicates camera flash state + - flash + # LED indicated keyboard capslock + - kbd-capslock + # LED indicates MTD memory activity + - mtd + # LED indicates NAND memory activity (deprecated), + # in new implementations use "mtd" + - nand-disk + # No trigger assigned to the LED. This is the default mode + # if trigger is absent + - none + # LED indicates camera torch state + - torch + # LED indicates USB gadget activity - usb-gadget + # LED indicates USB host activity - usb-host + # LED indicates USB port state + - usbport + # LED is triggered by CPU activity - pattern: "^cpu[0-9]*$" - - pattern: "^hci[0-9]+-power$" # LED is triggered by Bluetooth activity - - pattern: "^mmc[0-9]+$" + - pattern: "^hci[0-9]+-power$" # LED is triggered by SD/MMC activity - - pattern: "^phy[0-9]+tx$" + - pattern: "^mmc[0-9]+$" # LED is triggered by WLAN activity + - pattern: "^phy[0-9]+tx$" led-pattern: description: | 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-pca9532.txt b/Documentation/devicetree/bindings/leds/leds-pca9532.txt deleted file mode 100644 index f769c52e3643..000000000000 --- a/Documentation/devicetree/bindings/leds/leds-pca9532.txt +++ /dev/null @@ -1,49 +0,0 @@ -*NXP - pca9532 PWM LED Driver - -The PCA9532 family is SMBus I/O expander optimized for dimming LEDs. -The PWM support 256 steps. - -Required properties: - - compatible: - "nxp,pca9530" - "nxp,pca9531" - "nxp,pca9532" - "nxp,pca9533" - - reg - I2C slave address - -Each led is represented as a sub-node of the nxp,pca9530. - -Optional sub-node properties: - - label: see Documentation/devicetree/bindings/leds/common.txt - - type: Output configuration, see dt-bindings/leds/leds-pca9532.h (default NONE) - - linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt - - default-state: see Documentation/devicetree/bindings/leds/common.txt - This property is only valid for sub-nodes of type <PCA9532_TYPE_LED>. - -Example: - #include <dt-bindings/leds/leds-pca9532.h> - - leds: pca9530@60 { - compatible = "nxp,pca9530"; - reg = <0x60>; - - red-power { - label = "pca:red:power"; - type = <PCA9532_TYPE_LED>; - }; - green-power { - label = "pca:green:power"; - type = <PCA9532_TYPE_LED>; - }; - kernel-booting { - type = <PCA9532_TYPE_LED>; - default-state = "on"; - }; - sys-stat { - type = <PCA9532_TYPE_LED>; - default-state = "keep"; // don't touch, was set by U-Boot - }; - }; - -For more product information please see the link below: -http://nxp.com/documents/data_sheet/PCA9532.pdf diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml index 1df837798249..6295c91f43e8 100644 --- a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml @@ -27,6 +27,7 @@ properties: - qcom,pmc8180c-lpg - qcom,pmi8994-lpg - qcom,pmi8998-lpg + - qcom,pmk8550-pwm "#pwm-cells": const: 2 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/nxp,pca953x.yaml b/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml new file mode 100644 index 000000000000..edf6f55df685 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/nxp,pca953x.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/nxp,pca953x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PCA9532 LED Dimmer + +maintainers: + - Riku Voipio <riku.voipio@iki.fi> + +description: | + The PCA9532 family is SMBus I/O expander optimized for dimming LEDs. + The PWM support 256 steps. + + For more product information please see the link below: + https://www.nxp.com/docs/en/data-sheet/PCA9532.pdf + +properties: + compatible: + enum: + - nxp,pca9530 + - nxp,pca9531 + - nxp,pca9532 + - nxp,pca9533 + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + +patternProperties: + "^led-[0-9a-z]+$": + type: object + $ref: common.yaml# + unevaluatedProperties: false + + properties: + type: + description: | + Output configuration, see include/dt-bindings/leds/leds-pca9532.h + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + minimum: 0 + maximum: 4 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/leds-pca9532.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@62 { + compatible = "nxp,pca9533"; + reg = <0x62>; + + led-1 { + label = "pca:red:power"; + type = <PCA9532_TYPE_LED>; + }; + + led-2 { + label = "pca:green:power"; + type = <PCA9532_TYPE_LED>; + }; + + led-3 { + type = <PCA9532_TYPE_LED>; + default-state = "on"; + }; + + led-4 { + type = <PCA9532_TYPE_LED>; + default-state = "keep"; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml b/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml new file mode 100644 index 000000000000..ffacf703d9f9 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/qcom,spmi-flash-led.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/qcom,spmi-flash-led.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Flash LED device inside Qualcomm Technologies, Inc. PMICs + +maintainers: + - Fenglin Wu <quic_fenglinw@quicinc.com> + +description: | + Flash LED controller is present inside some Qualcomm Technologies, Inc. PMICs. + The flash LED module can have different number of LED channels supported + e.g. 3 or 4. There are some different registers between them but they can + both support maximum current up to 1.5 A per channel and they can also support + ganging 2 channels together to supply maximum current up to 2 A. The current + will be split symmetrically on each channel and they will be enabled and + disabled at the same time. + +properties: + compatible: + items: + - enum: + - qcom,pm6150l-flash-led + - qcom,pm8150c-flash-led + - qcom,pm8150l-flash-led + - qcom,pm8350c-flash-led + - const: qcom,spmi-flash-led + + reg: + maxItems: 1 + +patternProperties: + "^led-[0-3]$": + type: object + $ref: common.yaml# + unevaluatedProperties: false + description: + Represents the physical LED components which are connected to the + flash LED channels' output. + + properties: + led-sources: + description: + The HW indices of the flash LED channels that connect to the + physical LED + allOf: + - minItems: 1 + maxItems: 2 + items: + enum: [1, 2, 3, 4] + + led-max-microamp: + anyOf: + - minimum: 5000 + maximum: 500000 + multipleOf: 5000 + - minimum: 10000 + maximum: 1000000 + multipleOf: 10000 + + flash-max-microamp: + anyOf: + - minimum: 12500 + maximum: 1500000 + multipleOf: 12500 + - minimum: 25000 + maximum: 2000000 + multipleOf: 25000 + + flash-max-timeout-us: + minimum: 10000 + maximum: 1280000 + multipleOf: 10000 + + required: + - led-sources + - led-max-microamp + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + spmi { + #address-cells = <1>; + #size-cells = <0>; + led-controller@ee00 { + compatible = "qcom,pm8350c-flash-led", "qcom,spmi-flash-led"; + reg = <0xee00>; + + led-0 { + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + led-sources = <1>, <4>; + led-max-microamp = <300000>; + flash-max-microamp = <2000000>; + flash-max-timeout-us = <1280000>; + function-enumerator = <0>; + }; + + led-1 { + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_YELLOW>; + led-sources = <2>, <3>; + led-max-microamp = <300000>; + flash-max-microamp = <2000000>; + flash-max-timeout-us = <1280000>; + function-enumerator = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml b/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml new file mode 100644 index 000000000000..14700a2e5fea --- /dev/null +++ b/Documentation/devicetree/bindings/leds/rohm,bd2606mvv.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/rohm,bd2606mvv.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BD2606MVV LED controller + +maintainers: + - Andreas Kemnade <andreas@kemnade.info> + +description: + The BD2606 MVV is a programmable LED controller connected via I2C that can + drive 6 separate lines. Each of them can be individually switched on and off, + but the brightness setting is shared between pairs of them. + + Datasheet is available at + https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/led_driver/bd2606mvv_1-e.pdf + +properties: + compatible: + const: rohm,bd2606mvv + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + enable-gpios: + maxItems: 1 + description: GPIO pin to enable/disable the device. + +patternProperties: + "^led@[0-6]$": + type: object + $ref: common.yaml# + unevaluatedProperties: false + + properties: + reg: + minimum: 0 + maximum: 6 + + required: + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@66 { + compatible = "rohm,bd2606mvv"; + reg = <0x66>; + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0x0>; + color = <LED_COLOR_ID_RED>; + function = LED_FUNCTION_POWER; + }; + + led@2 { + reg = <0x2>; + color = <LED_COLOR_ID_WHITE>; + function = LED_FUNCTION_STATUS; + }; + }; + }; + +... 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/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/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/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 8df859136047..a37447256f8d 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -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/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/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,imx334.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml index 09533496b20c..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>; 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,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-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/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml index 7073d1936c34..91e8f368fb52 100644 --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml @@ -70,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 @@ -109,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/ti,cal.yaml b/Documentation/devicetree/bindings/media/ti,cal.yaml index 478bdbe3d759..f1a940a110d2 100644 --- a/Documentation/devicetree/bindings/media/ti,cal.yaml +++ b/Documentation/devicetree/bindings/media/ti,cal.yaml @@ -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/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/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/canaan,k210-sysctl.yaml b/Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml index e2046f07a40e..8459d3642205 100644 --- a/Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml +++ b/Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml @@ -36,7 +36,7 @@ properties: clock-controller: # Child node type: object - $ref: "../clock/canaan,k210-clk.yaml" + $ref: ../clock/canaan,k210-clk.yaml description: Clock controller for the SoC clocks. This child node definition should follow the bindings specified in @@ -45,7 +45,7 @@ properties: reset-controller: # Child node type: object - $ref: "../reset/canaan,k210-rst.yaml" + $ref: ../reset/canaan,k210-rst.yaml description: Reset controller for the SoC. This child node definition should follow the bindings specified in @@ -54,7 +54,7 @@ properties: syscon-reboot: # Child node type: object - $ref: "../power/reset/syscon-reboot.yaml" + $ref: ../power/reset/syscon-reboot.yaml description: Reboot method for the SoC. This child node definition should follow the bindings specified in diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index cdf1d719efe9..e1ca4f297c6d 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -65,7 +65,7 @@ properties: ARM Cortex M4 Co-processor. Contains the name of the rpmsg device. Used to match the subnode to the rpmsg device announced by the SCP. - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string spi-max-frequency: true @@ -94,23 +94,23 @@ properties: const: 0 typec: - $ref: "/schemas/chrome/google,cros-ec-typec.yaml#" + $ref: /schemas/chrome/google,cros-ec-typec.yaml# ec-pwm: - $ref: "/schemas/pwm/google,cros-ec-pwm.yaml#" + $ref: /schemas/pwm/google,cros-ec-pwm.yaml# deprecated: true pwm: - $ref: "/schemas/pwm/google,cros-ec-pwm.yaml#" + $ref: /schemas/pwm/google,cros-ec-pwm.yaml# kbd-led-backlight: - $ref: "/schemas/chrome/google,cros-kbd-led-backlight.yaml#" + $ref: /schemas/chrome/google,cros-kbd-led-backlight.yaml# keyboard-controller: - $ref: "/schemas/input/google,cros-ec-keyb.yaml#" + $ref: /schemas/input/google,cros-ec-keyb.yaml# proximity: - $ref: "/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#" + $ref: /schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml# codecs: type: object @@ -126,7 +126,7 @@ properties: patternProperties: "^ec-codec@[a-f0-9]+$": type: object - $ref: "/schemas/sound/google,cros-ec-codec.yaml#" + $ref: /schemas/sound/google,cros-ec-codec.yaml# required: - "#address-cells" @@ -151,15 +151,15 @@ properties: patternProperties: "^i2c-tunnel[0-9]*$": type: object - $ref: "/schemas/i2c/google,cros-ec-i2c-tunnel.yaml#" + $ref: /schemas/i2c/google,cros-ec-i2c-tunnel.yaml# "^regulator@[0-9]+$": type: object - $ref: "/schemas/regulator/google,cros-ec-regulator.yaml#" + $ref: /schemas/regulator/google,cros-ec-regulator.yaml# "^extcon[0-9]*$": type: object - $ref: "/schemas/extcon/extcon-usbc-cros-ec.yaml#" + $ref: /schemas/extcon/extcon-usbc-cros-ec.yaml# required: - compatible @@ -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/hisilicon,hi6421-spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml index 22edcb4b212f..bdff5b653453 100644 --- a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml @@ -53,7 +53,7 @@ properties: '^ldo[0-9]+$': type: object - $ref: "/schemas/regulator/regulator.yaml#" + $ref: /schemas/regulator/regulator.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/mfd/maxim,max5970.yaml b/Documentation/devicetree/bindings/mfd/maxim,max5970.yaml new file mode 100644 index 000000000000..da67742c5aa9 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max5970.yaml @@ -0,0 +1,151 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max5970.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Regulator for MAX5970 Smart Switch from Maxim Integrated + +maintainers: + - Patrick Rudolph <patrick.rudolph@9elements.com> + +description: | + The smart switch provides no output regulation, but independent fault protection + and voltage and current sensing. + Programming is done through I2C bus. + + Datasheets: + https://datasheets.maximintegrated.com/en/ds/MAX5970.pdf + https://datasheets.maximintegrated.com/en/ds/MAX5978.pdf + +properties: + compatible: + enum: + - maxim,max5970 + - maxim,max5978 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + leds: + type: object + description: + Properties for four LEDS. + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^led@[0-3]$": + $ref: /schemas/leds/common.yaml# + type: object + + additionalProperties: false + + vss1-supply: + description: Supply of the first channel. + + vss2-supply: + description: Supply of the second channel. + + regulators: + type: object + description: + Properties for both hot swap control/switch. + + patternProperties: + "^sw[0-1]$": + $ref: /schemas/regulator/regulator.yaml# + type: object + properties: + shunt-resistor-micro-ohms: + description: | + The value of current sense resistor in microohms. + + required: + - shunt-resistor-micro-ohms + + unevaluatedProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - regulators + - vss1-supply + +allOf: + - if: + properties: + compatible: + enum: + - maxim,max5970 + then: + required: + - vss2-supply + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + regulator@3a { + compatible = "maxim,max5978"; + reg = <0x3a>; + vss1-supply = <&p3v3>; + + regulators { + sw0_ref_0: sw0 { + shunt-resistor-micro-ohms = <12000>; + }; + }; + + leds { + #address-cells = <1>; + #size-cells = <0>; + led@0 { + reg = <0>; + label = "led0"; + default-state = "on"; + }; + led@1 { + reg = <1>; + label = "led1"; + default-state = "on"; + }; + }; + }; + }; + + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@3a { + compatible = "maxim,max5970"; + reg = <0x3a>; + vss1-supply = <&p3v3>; + vss2-supply = <&p5v>; + + regulators { + sw0_ref_1: sw0 { + shunt-resistor-micro-ohms = <12000>; + }; + sw1_ref_1: sw1 { + shunt-resistor-micro-ohms = <10000>; + }; + }; + }; + }; +... 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/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml index adf88245c409..36de335a33aa 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml @@ -33,6 +33,7 @@ properties: compatible: items: - enum: + - qcom,pm2250 - qcom,pm6125 - qcom,pm6150 - qcom,pm6150l @@ -78,6 +79,7 @@ properties: - qcom,pmk8350 - qcom,pmk8550 - qcom,pmm8155au + - qcom,pmm8654au - qcom,pmp8074 - qcom,pmr735a - qcom,pmr735b @@ -115,6 +117,7 @@ patternProperties: type: object oneOf: - $ref: /schemas/iio/adc/qcom,spmi-iadc.yaml# + - $ref: /schemas/iio/adc/qcom,spmi-rradc.yaml# - $ref: /schemas/iio/adc/qcom,spmi-vadc.yaml# "^adc-tm@[0-9a-f]+$": @@ -135,6 +138,14 @@ patternProperties: type: object $ref: /schemas/pinctrl/qcom,pmic-gpio.yaml# + "^led-controller@[0-9a-f]+$": + type: object + $ref: /schemas/leds/qcom,spmi-flash-led.yaml# + + "^nvram@[0-9a-f]+$": + type: object + $ref: /schemas/nvmem/qcom,spmi-sdam.yaml# + "pon@[0-9a-f]+$": type: object $ref: /schemas/power/reset/qcom,pon.yaml# @@ -276,12 +287,12 @@ examples: #size-cells = <0>; #io-channel-cells = <1>; - adc-chan@6 { + channel@6 { reg = <ADC5_DIE_TEMP>; label = "die_temp"; }; - adc-chan@4f { + channel@4f { reg = <ADC5_AMUX_THM3_100K_PU>; qcom,ratiometric; qcom,hw-settle-time = <200>; diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml index 2eeebe920e6e..fe790af7b4fb 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml @@ -25,12 +25,16 @@ properties: - qcom,sc8280xp-tcsr - qcom,sdm630-tcsr - qcom,sdm845-tcsr + - qcom,sdx55-tcsr + - qcom,sdx65-tcsr - qcom,sm8150-tcsr + - qcom,sm8450-tcsr - qcom,tcsr-apq8064 - qcom,tcsr-apq8084 - qcom,tcsr-ipq5332 - qcom,tcsr-ipq6018 - qcom,tcsr-ipq8064 + - qcom,tcsr-ipq9574 - qcom,tcsr-mdm9615 - qcom,tcsr-msm8226 - qcom,tcsr-msm8660 diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml index 9acad9d326eb..9c51c1b19067 100644 --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml @@ -49,7 +49,7 @@ patternProperties: "rtc@[0-9a-f]+$": type: object - $ref: "../rtc/qcom-pm8xxx-rtc.yaml" + $ref: ../rtc/qcom-pm8xxx-rtc.yaml required: - compatible diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml index d6d120a78094..05747e012516 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml @@ -46,7 +46,7 @@ properties: rohm,clkout-open-drain: description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos". - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1 diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml index ec3adcd3483d..11089aa89ec6 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml @@ -46,7 +46,7 @@ properties: rohm,clkout-open-drain: description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos". - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1 diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index c828c4f5e4a7..8103154bbb52 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -56,6 +56,7 @@ properties: - microchip,lan966x-cpu-syscon - microchip,sparx5-cpu-syscon - mstar,msc313-pmsleep + - nuvoton,ma35d1-sys - nuvoton,wpcm450-shm - rockchip,px30-qos - rockchip,rk3036-qos @@ -67,6 +68,7 @@ properties: - rockchip,rk3568-qos - rockchip,rk3588-qos - rockchip,rv1126-qos + - starfive,jh7100-sysmain - const: syscon diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml index 76ef4352e13c..0c98d913747b 100644 --- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml @@ -62,6 +62,12 @@ patternProperties: description: The phy node corresponding to the ethernet MAC. + "^chipid@[0-9a-f]+$": + type: object + $ref: /schemas/hwinfo/ti,k3-socinfo.yaml# + description: + The node corresponding to SoC chip identification. + required: - compatible - reg @@ -99,5 +105,10 @@ examples: reg = <0x4140 0x18>; #clock-cells = <1>; }; + + chipid@14 { + compatible = "ti,am654-chipid"; + reg = <0x14 0x4>; + }; }; ... diff --git a/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml b/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml new file mode 100644 index 000000000000..28cd5164d46f --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/ti,nspire-misc.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/ti,nspire-misc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI Nspire MISC hardware block + +maintainers: + - Andrew Davis <afd@ti.com> + +description: + System controller node represents a register region containing a set + of miscellaneous registers. The registers are not cohesive enough to + represent as any specific type of device. Currently there is a reset + controller. + +properties: + compatible: + items: + - enum: + - ti,nspire-misc + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + + reboot: + $ref: /schemas/power/reset/syscon-reboot.yaml# + +required: + - compatible + - reg + - reboot + +additionalProperties: false + +examples: + - | + misc: misc@900a0000 { + compatible = "ti,nspire-misc", "syscon", "simple-mfd"; + reg = <0x900a0000 0x1000>; + + reboot { + compatible = "syscon-reboot"; + offset = <0x08>; + value = <0x02>; + }; + }; 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/wlf,arizona.yaml b/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml index ea3337dafaf5..7902f3c5d289 100644 --- a/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml +++ b/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml @@ -156,7 +156,7 @@ properties: entry has a value that is out of range for a 16 bit register then the chip default will be used. If present exactly five values must be specified. - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 maxItems: 5 diff --git a/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml b/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml index 309606d2d806..f3d8394b27e7 100644 --- a/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml +++ b/Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mfd/x-powers,ac100.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mfd/x-powers,ac100.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: X-Powers AC100 diff --git a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml index b7a8747d5fa0..f7f0f2c0421a 100644 --- a/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml +++ b/Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml @@ -47,9 +47,8 @@ allOf: - x-powers,axp209 then: - not: - required: - - x-powers,drive-vbus-en + properties: + x-powers,drive-vbus-en: false - if: not: @@ -59,14 +58,9 @@ allOf: const: x-powers,axp806 then: - allOf: - - not: - required: - - x-powers,self-working-mode - - - not: - required: - - x-powers,master-mode + properties: + x-powers,self-working-mode: false + x-powers,master-mode: false - if: not: @@ -79,6 +73,18 @@ allOf: required: - interrupts + - if: + properties: + compatible: + contains: + enum: + - x-powers,axp313a + - x-powers,axp15060 + + then: + properties: + x-powers,dcdc-freq: false + properties: compatible: oneOf: @@ -88,10 +94,12 @@ properties: - x-powers,axp209 - x-powers,axp221 - x-powers,axp223 + - x-powers,axp313a - x-powers,axp803 - x-powers,axp806 - x-powers,axp809 - x-powers,axp813 + - x-powers,axp15060 - items: - const: x-powers,axp228 - const: x-powers,axp221 @@ -260,7 +268,7 @@ properties: Defines the work frequency of DC-DC in kHz. patternProperties: - "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|drivevbus|dc5ldo)$": + "^(([a-f])?ldo[0-9]|dcdc[0-7a-e]|ldo(_|-)io(0|1)|(dc1)?sw|rtc(_|-)ldo|cpusldo|drivevbus|dc5ldo)$": $ref: /schemas/regulator/regulator.yaml# type: object unevaluatedProperties: false @@ -299,7 +307,7 @@ additionalProperties: false examples: - | - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; @@ -315,7 +323,7 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> - i2c0 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml b/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml index 9efd49c39bd2..6e880a46d7ee 100644 --- a/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml +++ b/Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Bootlin %YAML 1.2 --- -$id: "http://devicetree.org/schemas/mfd/xylon,logicvc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/mfd/xylon,logicvc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Xylon LogiCVC multi-function device 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/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/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/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 837d6db299c4..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: 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/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/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/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml index 2be72ae1169f..24c88942e59e 100644 --- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml @@ -21,8 +21,12 @@ allOf: properties: compatible: - items: + oneOf: - const: rockchip,rk3568-pcie + - items: + - enum: + - rockchip,rk3588-pcie + - const: rockchip,rk3568-pcie reg: items: 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/allwinner,sun50i-h6-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb3-phy.yaml index c03b83103e87..cf4eed230565 100644 --- a/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/allwinner,sun50i-h6-usb3-phy.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Ondrej Jirman <megous@megous.com> %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/allwinner,sun50i-h6-usb3-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/allwinner,sun50i-h6-usb3-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Allwinner H6 USB3 PHY diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml index fe9702e7bdd8..6a4fd4929959 100644 --- a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml +++ b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml @@ -45,7 +45,7 @@ properties: maxItems: 1 allwinner,direction: - $ref: '/schemas/types.yaml#/definitions/string' + $ref: /schemas/types.yaml#/definitions/string description: | Direction of the D-PHY: - "rx" for receiving (e.g. when used with MIPI CSI-2); diff --git a/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml index 5eddaed3d853..64795f170f32 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,axg-mipi-dphy.yaml @@ -2,8 +2,8 @@ # Copyright 2020 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/amlogic,axg-mipi-dphy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/amlogic,axg-mipi-dphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic AXG MIPI D-PHY diff --git a/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml index 7aa0c05d6ce4..c8c83acfb871 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic G12A MIPI analog PHY diff --git a/Documentation/devicetree/bindings/phy/amlogic,g12a-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb2-phy.yaml index bb01c6b34dab..0031fb6a4e76 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,g12a-usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb2-phy.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/amlogic,g12a-usb2-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/amlogic,g12a-usb2-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic G12A USB2 PHY diff --git a/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml index 3314711292d6..1a5a12adb72b 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-usb3-pcie-phy.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/amlogic,g12a-usb3-pcie-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/amlogic,g12a-usb3-pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic G12A USB3 + PCIE Combo PHY diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml index a90fa1baadab..009a39808318 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-mipi-pcie-analog.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/amlogic,meson-axg-mipi-pcie-analog.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/amlogic,meson-axg-mipi-pcie-analog.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic AXG shared MIPI/PCIE analog PHY diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml index 45f3d72b1cca..40fbf8ac3271 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,meson-axg-pcie.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/amlogic,meson-axg-pcie.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/amlogic,meson-axg-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic AXG PCIE PHY diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml index 1f085cdd1c85..6f9fd1c953f0 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/amlogic,meson8-hdmi-tx-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/amlogic,meson8-hdmi-tx-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson8, Meson8b and Meson8m2 HDMI TX PHY diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml index 03c4809dbe8d..df68bfe5f407 100644 --- a/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/amlogic,meson8b-usb2-phy.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/amlogic,meson8b-usb2-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/amlogic,meson8b-usb2-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson8, Meson8b, Meson8m2 and GXBB USB2 PHY diff --git a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml index 0f0bcde9eb88..bd527f566c3b 100644 --- a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/brcm,bcm63xx-usbh-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/brcm,bcm63xx-usbh-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: BCM63xx USBH PHY diff --git a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml index 435b971dfd9b..8467c8e6368c 100644 --- a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/brcm,sata-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/brcm,sata-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Broadcom SATA3 PHY diff --git a/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml b/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml index 3a07285b5470..c9e65a2facd5 100644 --- a/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml +++ b/Documentation/devicetree/bindings/phy/cdns,salvo-phy.yaml @@ -2,8 +2,8 @@ # Copyright (c) 2020 NXP %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/cdns,salvo-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/cdns,salvo-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence SALVO PHY diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml index b11d9873854a..405c6b0b88c0 100644 --- a/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml +++ b/Documentation/devicetree/bindings/phy/hisilicon,hi3660-usb3.yaml @@ -19,11 +19,11 @@ properties: const: 0 hisilicon,pericrg-syscon: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: phandle of syscon used to control iso refclk. hisilicon,pctrl-syscon: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: phandle of syscon used to control usb tcxo. hisilicon,eye-diagram-param: diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml index 3c69aca6c7eb..a1a8a84dfc54 100644 --- a/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml +++ b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml @@ -20,15 +20,15 @@ properties: const: 0 hisilicon,pericrg-syscon: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: phandle of syscon used to control iso refclk. hisilicon,pctrl-syscon: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: phandle of syscon used to control usb tcxo. hisilicon,sctrl-syscon: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: phandle of syscon used to control phy deep sleep. hisilicon,eye-diagram-param: diff --git a/Documentation/devicetree/bindings/phy/intel,phy-thunderbay-emmc.yaml b/Documentation/devicetree/bindings/phy/intel,phy-thunderbay-emmc.yaml deleted file mode 100644 index 361ffc35b16b..000000000000 --- a/Documentation/devicetree/bindings/phy/intel,phy-thunderbay-emmc.yaml +++ /dev/null @@ -1,45 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/phy/intel,phy-thunderbay-emmc.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Intel Thunder Bay eMMC PHY - -maintainers: - - Srikandan Nandhini <nandhini.srikandan@intel.com> - -properties: - compatible: - const: intel,thunderbay-emmc-phy - - "#phy-cells": - const: 0 - - reg: - maxItems: 1 - - clocks: - maxItems: 1 - - clock-names: - items: - - const: emmcclk - -required: - - "#phy-cells" - - compatible - - reg - - clocks - -additionalProperties: false - -examples: - - | - mmc_phy@80440800 { - #phy-cells = <0x0>; - compatible = "intel,thunderbay-emmc-phy"; - reg = <0x80440800 0x100>; - clocks = <&emmc>; - clock-names = "emmcclk"; - }; diff --git a/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml index 632d61c07f40..3aa1a46796dd 100644 --- a/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/marvell,armada-3700-utmi-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/marvell,armada-3700-utmi-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Marvell Armada UTMI/UTMI+ PHY 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..9ce7b4c6d208 100644 --- a/Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/marvell,armada-cp110-utmi-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/marvell,armada-cp110-utmi-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Marvell Armada CP110/CP115 UTMI PHY @@ -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/marvell,mmp3-hsic-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml index ff255aa4cc10..bd3bd2f8b1cd 100644 --- a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml +++ b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Lubomir Rintel <lkundrak@v3.sk> %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/marvell,mmp3-hsic-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/marvell,mmp3-hsic-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Marvell MMP3 HSIC PHY diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml index 6cfdaadec085..f3a8b0b745d1 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml @@ -28,6 +28,7 @@ properties: - const: mediatek,mt2701-hdmi-phy - const: mediatek,mt2701-hdmi-phy - const: mediatek,mt8173-hdmi-phy + - const: mediatek,mt8195-hdmi-phy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml index c2f4cb0b254a..b35c4d256e40 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/mediatek,mt7621-pci-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/mediatek,mt7621-pci-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Mediatek Mt7621 PCIe PHY diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml index 6a09472740ed..37f028f7a095 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/phy-cadence-sierra.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/phy-cadence-sierra.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence Sierra PHY @@ -61,14 +61,6 @@ properties: - const: pll0_refclk - const: pll1_refclk - assigned-clocks: - minItems: 1 - maxItems: 2 - - assigned-clock-parents: - minItems: 1 - maxItems: 2 - cdns,autoconf: type: boolean description: diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml index 2ad1faadda2a..dfb31314face 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/phy-cadence-torrent.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/phy-cadence-torrent.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence Torrent SD0801 PHY @@ -44,12 +44,6 @@ properties: - const: refclk - const: phy_en_refclk - assigned-clocks: - maxItems: 3 - - assigned-clock-parents: - maxItems: 3 - reg: minItems: 1 items: diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml index 8d8698412de0..9ae514fa7533 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml @@ -13,6 +13,7 @@ properties: compatible: enum: - rockchip,rk3568-naneng-combphy + - rockchip,rk3588-naneng-combphy reg: maxItems: 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/phy-tegra194-p2u.yaml b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml index 445b2467f4f6..4790c6238a40 100644 --- a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml +++ b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/phy-tegra194-p2u.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/phy-tegra194-p2u.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra194 & Tegra234 P2U diff --git a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml index 1e104ae76ee6..c4f8e6ffa5c3 100644 --- a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/qcom,edp-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/qcom,edp-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm eDP PHY diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index 7f403e77f320..543c1a2811a5 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/qcom,qusb2-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/qcom,qusb2-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm QUSB2 phy controller 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/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml index ef49efbd0a20..a0407fc79563 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml @@ -19,6 +19,7 @@ properties: - qcom,sc8280xp-qmp-gen3x1-pcie-phy - qcom,sc8280xp-qmp-gen3x2-pcie-phy - qcom,sc8280xp-qmp-gen3x4-pcie-phy + - qcom,sdx65-qmp-gen4x2-pcie-phy - qcom,sm8350-qmp-gen3x1-pcie-phy - qcom,sm8550-qmp-gen3x2-pcie-phy - qcom,sm8550-qmp-gen4x2-pcie-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml index 64ed331880f6..94c0fab065a8 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml @@ -16,20 +16,25 @@ description: properties: compatible: enum: + - qcom,sa8775p-qmp-ufs-phy - qcom,sc8280xp-qmp-ufs-phy - qcom,sm6125-qmp-ufs-phy + - qcom,sm7150-qmp-ufs-phy - qcom,sm8550-qmp-ufs-phy reg: maxItems: 1 clocks: - maxItems: 2 + minItems: 2 + maxItems: 3 clock-names: + minItems: 2 items: - const: ref - const: ref_aux + - const: qref power-domains: maxItems: 1 @@ -63,6 +68,26 @@ required: - vdda-pll-supply - "#phy-cells" +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,sa8775p-qmp-ufs-phy + then: + properties: + clocks: + maxItems: 3 + clock-names: + maxItems: 3 + else: + properties: + clocks: + maxItems: 2 + clock-names: + maxItems: 2 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml index ca6a0836b53c..6c99e02b2b4f 100644 --- a/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/qcom,usb-hs-28nm.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/qcom,usb-hs-28nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Synopsys DesignWare Core 28nm High-Speed PHY diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml index 85d405e028b9..a26524b7e7b7 100644 --- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/qcom,usb-snps-femto-v2.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/qcom,usb-snps-femto-v2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Synopsys Femto High-Speed USB PHY V2 diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-ss.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-ss.yaml index bd1388d62ce0..6e4254ff1cd7 100644 --- a/Documentation/devicetree/bindings/phy/qcom,usb-ss.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,usb-ss.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/qcom,usb-ss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/qcom,usb-ss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Synopsys 1.0.0 SuperSpeed USB PHY diff --git a/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml b/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml index 3e7191b168fb..09c614952fea 100644 --- a/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom-usb-ipq4019-phy.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/qcom-usb-ipq4019-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/qcom-usb-ipq4019-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcom IPQ40xx Dakota HS/SS USB PHY diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml index 28e299a9609d..41df8bb08ff7 100644 --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml @@ -21,12 +21,12 @@ properties: maxItems: 1 samsung,pmu-syscon: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: phandle for PMU system controller interface, used to control PMU registers bits for PCIe PHY samsung,fsys-sysreg: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: phandle for FSYS sysreg interface, used to control sysreg registers bits for PCIe PHY diff --git a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml index c5dbb91ac402..782f975b43ae 100644 --- a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml @@ -35,7 +35,7 @@ properties: maxItems: 4 samsung,pmu-syscon: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 items: minItems: 1 diff --git a/Documentation/devicetree/bindings/phy/sunplus,sp7021-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/sunplus,sp7021-usb2-phy.yaml index 069d422775bb..57914f214e06 100644 --- a/Documentation/devicetree/bindings/phy/sunplus,sp7021-usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/sunplus,sp7021-usb2-phy.yaml @@ -2,8 +2,8 @@ # Copyright (C) Sunplus Co., Ltd. 2021 %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/sunplus,sp7021-usb2-phy.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/sunplus,sp7021-usb2-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Sunplus SP7021 USB 2.0 PHY Controller diff --git a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml index 738c92bb7518..854e554eae67 100644 --- a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml +++ b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml @@ -34,11 +34,6 @@ properties: Three input clocks referring to left input reference clock, refclk and right input reference clock. - assigned-clocks: - $ref: "/schemas/types.yaml#/definitions/phandle-array" - assigned-clock-parents: - $ref: "/schemas/types.yaml#/definitions/phandle-array" - '#phy-cells': const: 2 description: diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml index 6d46f57fa1b4..be41b4547ec6 100644 --- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml +++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/ti,phy-gmii-sel.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/ti,phy-gmii-sel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: CPSW Port's Interface Mode Selection PHY @@ -55,6 +55,7 @@ properties: - ti,am654-phy-gmii-sel - ti,j7200-cpsw5g-phy-gmii-sel - ti,j721e-cpsw9g-phy-gmii-sel + - ti,j784s4-cpsw9g-phy-gmii-sel reg: maxItems: 1 @@ -87,6 +88,7 @@ allOf: - ti,am654-phy-gmii-sel - ti,j7200-cpsw5g-phy-gmii-sel - ti,j721e-cpsw9g-phy-gmii-sel + - ti,j784s4-cpsw9g-phy-gmii-sel then: properties: '#phy-cells': @@ -113,6 +115,7 @@ allOf: contains: enum: - ti,j721e-cpsw9g-phy-gmii-sel + - ti,j784s4-cpsw9g-phy-gmii-sel then: properties: ti,qsgmii-main-ports: @@ -130,6 +133,7 @@ allOf: enum: - ti,j7200-cpsw5g-phy-gmii-sel - ti,j721e-cpsw9g-phy-gmii-sel + - ti,j784s4-cpsw9g-phy-gmii-sel then: properties: ti,qsgmii-main-ports: false diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml index c54b36c104ab..9ea30eaba314 100644 --- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml +++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml @@ -2,8 +2,8 @@ # Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/ti,phy-j721e-wiz.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/ti,phy-j721e-wiz.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TI J721E WIZ (SERDES Wrapper) @@ -54,18 +54,6 @@ properties: ranges: true - assigned-clocks: - minItems: 1 - maxItems: 2 - - assigned-clock-parents: - minItems: 1 - maxItems: 2 - - assigned-clock-rates: - minItems: 1 - maxItems: 2 - typec-dir-gpios: maxItems: 1 description: @@ -101,6 +89,9 @@ properties: "#clock-cells": const: 0 + clock-output-names: + maxItems: 1 + assigned-clocks: maxItems: 1 @@ -134,6 +125,9 @@ patternProperties: "#clock-cells": const: 0 + clock-output-names: + maxItems: 1 + assigned-clocks: maxItems: 1 @@ -162,6 +156,9 @@ patternProperties: "#clock-cells": const: 0 + clock-output-names: + maxItems: 1 + required: - clocks - "#clock-cells" diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml index 237295b2b5a8..79dad3e89aa6 100644 --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: TCAN104x CAN TRANSCEIVER PHY diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml index fb0f69ce9c16..7cb8a747feee 100644 --- a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml @@ -185,7 +185,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml index 1e3c8de6cae1..467016cbb037 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml @@ -142,7 +142,7 @@ allOf: # boards are defining it at the moment so it would generate a lot of # warnings. - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# - if: not: properties: diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml new file mode 100644 index 000000000000..99080c9eaac3 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-a1.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/amlogic,meson-pinctrl-a1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson A1 pinmux controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +allOf: + - $ref: amlogic,meson-pinctrl-common.yaml# + +properties: + compatible: + enum: + - amlogic,meson-a1-periphs-pinctrl + - amlogic,meson-s4-periphs-pinctrl + +required: + - compatible + +patternProperties: + "^bank@[0-9a-z]+$": + $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio + + unevaluatedProperties: false + + properties: + reg: + maxItems: 2 + + reg-names: + items: + - const: mux + - const: gpio + +unevaluatedProperties: + type: object + $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins + +examples: + - | + periphs_pinctrl: pinctrl { + compatible = "amlogic,meson-a1-periphs-pinctrl"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + bank@400 { + reg = <0x0400 0x003c>, + <0x0480 0x0118>; + reg-names = "mux", "gpio"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&periphs_pinctrl 0 0 62>; + }; + + cec_ao_a_h_pins: cec_ao_a_h { + mux { + groups = "cec_ao_a_h"; + function = "cec_ao_a_h"; + bias-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml new file mode 100644 index 000000000000..a7b29ef0bab6 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-common.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/amlogic,meson-pinctrl-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson pinmux controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +allOf: + - $ref: pinctrl.yaml# + +properties: + ranges: true + + "#address-cells": + enum: [1, 2] + + "#size-cells": + enum: [1, 2] + +required: + - ranges + - "#address-cells" + - "#size-cells" + +additionalProperties: true + +$defs: + meson-gpio: + type: object + + properties: + gpio-controller: true + + "#gpio-cells": + const: 2 + + gpio-ranges: + maxItems: 1 + + required: + - reg + - reg-names + - gpio-controller + - "#gpio-cells" + - gpio-ranges + + meson-pins: + type: object + additionalProperties: + type: object + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml new file mode 100644 index 000000000000..7c9c94ec5b7b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/amlogic,meson-pinctrl-g12a-aobus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson G12 AOBUS pinmux controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +allOf: + - $ref: amlogic,meson-pinctrl-common.yaml# + +properties: + compatible: + enum: + - amlogic,meson-g12a-aobus-pinctrl + +required: + - compatible + +patternProperties: + "^bank@[0-9a-z]+$": + $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio + + unevaluatedProperties: false + + properties: + reg: + maxItems: 3 + + reg-names: + items: + - const: mux + - const: ds + - const: gpio + +unevaluatedProperties: + type: object + $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins + +examples: + - | + ao_pinctrl: pinctrl { + compatible = "amlogic,meson-g12a-aobus-pinctrl"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + bank@14 { + reg = <0x14 0x8>, + <0x1c 0x8>, + <0x24 0x14>; + reg-names = "mux", "ds", "gpio"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&ao_pinctrl 0 0 15>; + }; + + cec_ao_a_h_pins: cec_ao_a_h { + mux { + groups = "cec_ao_a_h"; + function = "cec_ao_a_h"; + bias-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml new file mode 100644 index 000000000000..4bcb8b60420f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/amlogic,meson-pinctrl-g12a-periphs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson G12 PERIPHS pinmux controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +allOf: + - $ref: amlogic,meson-pinctrl-common.yaml# + +properties: + compatible: + enum: + - amlogic,meson-g12a-periphs-pinctrl + +required: + - compatible + +patternProperties: + "^bank@[0-9a-z]+$": + $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio + + unevaluatedProperties: false + + properties: + reg: + maxItems: 5 + + reg-names: + items: + - const: gpio + - const: pull + - const: pull-enable + - const: mux + - const: ds + +unevaluatedProperties: + type: object + $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins + +examples: + - | + periphs_pinctrl: pinctrl { + compatible = "amlogic,meson-g12a-periphs-pinctrl"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + bank@40 { + reg = <0x40 0x4c>, + <0xe8 0x18>, + <0x120 0x18>, + <0x2c0 0x40>, + <0x340 0x1c>; + reg-names = "gpio", "pull", "pull-enable", "mux", "ds"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&periphs_pinctrl 0 0 86>; + }; + + cec_ao_a_h_pins: cec_ao_a_h { + mux { + groups = "cec_ao_a_h"; + function = "cec_ao_a_h"; + bias-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml new file mode 100644 index 000000000000..32d99c9b6afc --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-aobus.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/amlogic,meson8-pinctrl-aobus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson8 AOBUS pinmux controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +allOf: + - $ref: amlogic,meson-pinctrl-common.yaml# + +properties: + compatible: + oneOf: + - enum: + - amlogic,meson8-aobus-pinctrl + - amlogic,meson8b-aobus-pinctrl + - amlogic,meson-gxbb-aobus-pinctrl + - amlogic,meson-gxl-aobus-pinctrl + - amlogic,meson-axg-aobus-pinctrl + - items: + - const: amlogic,meson8m2-aobus-pinctrl + - const: amlogic,meson8-aobus-pinctrl + +required: + - compatible + +patternProperties: + "^bank@[0-9a-z]+$": + $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio + + unevaluatedProperties: false + + properties: + reg: + maxItems: 3 + + reg-names: + items: + - const: mux + - const: pull + - const: gpio + +unevaluatedProperties: + type: object + $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins + +examples: + - | + pinctrl_aobus: pinctrl { + compatible = "amlogic,meson8-aobus-pinctrl"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + bank@14 { + reg = <0x14 0x4>, + <0x2c 0x4>, + <0x24 0x8>; + reg-names = "mux", "pull", "gpio"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl_aobus 0 0 16>; + }; + + cec_ao_a_h_pins: cec_ao_a_h { + mux { + groups = "cec_ao_a_h"; + function = "cec_ao_a_h"; + bias-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml new file mode 100644 index 000000000000..d0441051f34a --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,meson8-pinctrl-cbus.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/amlogic,meson8-pinctrl-cbus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson8 CBUS pinmux controller + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +allOf: + - $ref: amlogic,meson-pinctrl-common.yaml# + +properties: + compatible: + oneOf: + - enum: + - amlogic,meson8-cbus-pinctrl + - amlogic,meson8b-cbus-pinctrl + - amlogic,meson-gxbb-periphs-pinctrl + - amlogic,meson-gxl-periphs-pinctrl + - amlogic,meson-axg-periphs-pinctrl + - items: + - const: amlogic,meson8m2-cbus-pinctrl + - const: amlogic,meson8-cbus-pinctrl + +required: + - compatible + +patternProperties: + "^bank@[0-9a-z]+$": + $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-gpio + + unevaluatedProperties: false + + properties: + reg: + maxItems: 4 + + reg-names: + items: + - const: mux + - const: pull + - const: pull-enable + - const: gpio + +unevaluatedProperties: + type: object + $ref: amlogic,meson-pinctrl-common.yaml#/$defs/meson-pins + +examples: + - | + pinctrl_cbus: pinctrl { + compatible = "amlogic,meson8-cbus-pinctrl"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + bank@80b0 { + reg = <0x80b0 0x28>, + <0x80e8 0x18>, + <0x8120 0x18>, + <0x8030 0x30>; + reg-names = "mux", "pull", "pull-enable", "gpio"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl_cbus 0 0 120>; + }; + + cec_ao_a_h_pins: cec_ao_a_h { + mux { + groups = "cec_ao_a_h"; + function = "cec_ao_a_h"; + bias-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml index 684c03a6bd40..9c07935919ea 100644 --- a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml @@ -74,7 +74,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml index f4f1ee6b116e..bef85c25cdef 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml @@ -32,7 +32,7 @@ patternProperties: then: patternProperties: "^function|groups$": - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT, EXTRST, FLACK, FLBUSY, FLWP, GPID, GPID0, GPID2, GPID4, GPID6, GPIE0, @@ -51,7 +51,7 @@ patternProperties: VGAHS, VGAVS, VPI18, VPI24, VPI30, VPO12, VPO24, WDTRST1, WDTRST2] allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml index 8168f0088471..14c391f16899 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml @@ -44,7 +44,7 @@ patternProperties: then: patternProperties: "^function|groups$": - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: [ ACPI, ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, DDCCLK, DDCDAT, ESPI, FWSPICS1, FWSPICS2, GPID0, GPID2, GPID4, GPID6, GPIE0, GPIE2, @@ -65,7 +65,7 @@ patternProperties: VGAVS, VPI24, VPO, WDTRST1, WDTRST2] allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index 62424c42c981..859a1889dc1e 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -30,7 +30,7 @@ patternProperties: then: properties: function: - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMC, ESPI, ESPIALT, FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1, GPIT2, GPIT3, @@ -55,7 +55,7 @@ patternProperties: USB2BD, USB2BH, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, WDTRST4 ] groups: - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15, ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, EMMCG1, EMMCG4, EMMCG8, ESPI, ESPIALT, FSI1, FSI2, FWQSPI, FWSPIABR, FWSPID, FWSPIWP, @@ -84,7 +84,7 @@ patternProperties: WDTRST3, WDTRST4] allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml index ab019a1998e8..4478a76171f7 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml @@ -38,7 +38,7 @@ patternProperties: gpio8, gpio9, gpio10, gpio11, gpio12, gpio13, gpio40 ] allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml index 8c9d4668c8c4..73e1caa7c011 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml @@ -42,7 +42,7 @@ patternProperties: vdsl_phy_override_3_grp, dsl_gpio8, dsl_gpio9 ] allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml index a8e22ec02215..2750ba42aeb8 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml @@ -37,7 +37,7 @@ patternProperties: usb_port1 ] allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml index 35867355a47a..2f6c540498bc 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml @@ -35,7 +35,7 @@ patternProperties: led_grp, spi_cs_grp, utopia_grp, pwm_syn_clk, sys_irq_grp ] allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml index b584d4b27223..b3044f805753 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml @@ -42,7 +42,7 @@ patternProperties: gpio22, gpio23, gpio24, gpio25, gpio26, gpio27, nand_grp ] allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml index 229323d9237d..3236871827df 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml @@ -43,7 +43,7 @@ patternProperties: gpio31, uart1_grp ] allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml index 8d1e5b1cdd5f..0a39dd26ee1a 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml @@ -53,7 +53,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml index a78cb2796001..7f4f36a58e56 100644 --- a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml +++ b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml @@ -144,7 +144,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml index 5cd512b7d5ba..5e000b3fadde 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml @@ -173,7 +173,7 @@ properties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml index 6bd42e43cdab..bb61a30321a1 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml @@ -40,8 +40,8 @@ properties: '-pins$': type: object allOf: - - $ref: "pincfg-node.yaml#" - - $ref: "pinmux-node.yaml#" + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# properties: groups: description: diff --git a/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml b/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml index 915cbbcc3555..222d57541b65 100644 --- a/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml @@ -109,7 +109,7 @@ required: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# examples: - | diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml index 621038662188..7bd723ab1281 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml @@ -68,7 +68,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml index 7ae084397258..6068be11dfe2 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8m-pinctrl.yaml @@ -65,7 +65,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml index 693398d88223..7dcf681271d3 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml @@ -57,7 +57,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml index 66baa6082a4f..2f2405102996 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml @@ -14,7 +14,7 @@ description: for common binding part and usage. allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml index a4397930e0e8..35723966b70a 100644 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml @@ -119,7 +119,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml b/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml index ca0fef6e535e..1144ca2896e3 100644 --- a/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml +++ b/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml @@ -48,7 +48,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-thunderbay.yaml b/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-thunderbay.yaml deleted file mode 100644 index f001add16814..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-thunderbay.yaml +++ /dev/null @@ -1,120 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/pinctrl/intel,pinctrl-thunderbay.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Intel Thunder Bay pin controller - -maintainers: - - Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com> - -description: | - Intel Thunder Bay SoC integrates a pin controller which enables control - of pin directions, input/output values and configuration - for a total of 67 pins. - -properties: - compatible: - const: intel,thunderbay-pinctrl - - reg: - maxItems: 1 - - gpio-controller: true - - '#gpio-cells': - const: 2 - - gpio-ranges: - maxItems: 1 - - interrupts: - description: - Specifies the interrupt lines to be used by the controller. - maxItems: 2 - - interrupt-controller: true - - '#interrupt-cells': - const: 2 - -patternProperties: - '^gpio@[0-9a-f]*$': - type: object - additionalProperties: false - - description: - Child nodes can be specified to contain pin configuration information, - which can then be utilized by pinctrl client devices. - The following properties are supported. - - properties: - pins: - description: | - The name(s) of the pins to be configured in the child node. - Supported pin names are "GPIO0" up to "GPIO66". - - bias-disable: true - - bias-pull-down: true - - bias-pull-up: true - - drive-strength: - description: Drive strength for the pad. - enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] - - bias-bus-hold: - type: boolean - - input-schmitt-enable: - type: boolean - - slew-rate: - description: GPIO slew rate control. - 0 - Slow - 1 - Fast - enum: [0, 1] - -additionalProperties: false - -required: - - compatible - - reg - - gpio-controller - - '#gpio-cells' - - gpio-ranges - - interrupts - - interrupt-controller - - '#interrupt-cells' - -examples: - - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/interrupt-controller/irq.h> - // Example 1 - pinctrl0: gpio@0 { - compatible = "intel,thunderbay-pinctrl"; - reg = <0x600b0000 0x88>; - gpio-controller; - #gpio-cells = <0x2>; - gpio-ranges = <&pinctrl0 0 0 67>; - interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; - interrupt-controller; - #interrupt-cells = <2>; - }; - - // Example 2 - pinctrl1: gpio@1 { - compatible = "intel,thunderbay-pinctrl"; - reg = <0x600c0000 0x88>; - gpio-controller; - #gpio-cells = <0x2>; - gpio-ranges = <&pinctrl1 0 0 53>; - interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; - interrupt-controller; - #interrupt-cells = <2>; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt b/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt index 4658f105fa09..6bd9bc61becb 100644 --- a/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt +++ b/Documentation/devicetree/bindings/pinctrl/lantiq,pinctrl-xway.txt @@ -1,11 +1,7 @@ Lantiq XWAY pinmux controller Required properties: -- compatible: "lantiq,pinctrl-xway", (DEPRECATED: Use "lantiq,pinctrl-danube") - "lantiq,pinctrl-xr9", (DEPRECATED: Use "lantiq,xrx100-pinctrl" or - "lantiq,xrx200-pinctrl") - "lantiq,pinctrl-ase", (DEPRECATED: Use "lantiq,ase-pinctrl") - "lantiq,<chip>-pinctrl", where <chip> is: +- compatible: "lantiq,<chip>-pinctrl", where <chip> is: "ase" (XWAY AMAZON Family) "danube" (XWAY DANUBE Family) "xrx100" (XWAY xRX100 Family) @@ -45,29 +41,6 @@ Required subnode-properties: Valid values for group and function names: -XWAY: (DEPRECATED: Use DANUBE) - mux groups: - exin0, exin1, exin2, jtag, ebu a23, ebu a24, ebu a25, ebu clk, ebu cs1, - ebu wait, nand ale, nand cs1, nand cle, spi, spi_cs1, spi_cs2, spi_cs3, - spi_cs4, spi_cs5, spi_cs6, asc0, asc0 cts rts, stp, nmi, gpt1, gpt2, - gpt3, clkout0, clkout1, clkout2, clkout3, gnt1, gnt2, gnt3, req1, req2, - req3 - - functions: - spi, asc, cgu, jtag, exin, stp, gpt, nmi, pci, ebu - -XR9: ( DEPRECATED: Use xRX100/xRX200) - mux groups: - exin0, exin1, exin2, exin3, exin4, jtag, ebu a23, ebu a24, ebu a25, - ebu clk, ebu cs1, ebu wait, nand ale, nand cs1, nand cle, nand rdy, - nand rd, spi, spi_cs1, spi_cs2, spi_cs3, spi_cs4, spi_cs5, spi_cs6, - asc0, asc0 cts rts, stp, nmi, gpt1, gpt2, gpt3, clkout0, clkout1, - clkout2, clkout3, gnt1, gnt2, gnt3, gnt4, req1, req2, req3, req4, mdio, - gphy0 led0, gphy0 led1, gphy0 led2, gphy1 led0, gphy1 led1, gphy1 led2 - - functions: - spi, asc, cgu, jtag, exin, stp, gpt, nmi, pci, ebu, mdio, gphy - AMAZON: mux groups: exin0, exin1, exin2, jtag, spi_di, spi_do, spi_clk, spi_cs1, spi_cs2, @@ -139,12 +112,6 @@ Optional subnode-properties: 0: none, 1: down, 2: up. - lantiq,open-drain: Boolean, enables open-drain on the defined pin. -Valid values for XWAY pin names: (DEPRECATED: Use DANUBE) - Pinconf pins can be referenced via the names io0-io31. - -Valid values for XR9 pin names: (DEPRECATED: Use xrX100/xRX200) - Pinconf pins can be referenced via the names io0-io55. - Valid values for AMAZON pin names: Pinconf pins can be referenced via the names io0-io31. diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml index 491f67e7cc4f..afea9424c7e1 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml @@ -28,7 +28,7 @@ patternProperties: properties: marvell,function: - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string description: Indicates the function to select. enum: [ dev_init_done, ge, gpio, i2c0, i2c1, int_out, led, nand, pcie, ptp, sdio, @@ -47,7 +47,7 @@ patternProperties: mpp40, mpp41, mpp42, mpp43, mpp44, mpp45 ] allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml index a55c8e4ff26e..bccff08a5ba3 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml @@ -4,13 +4,13 @@ $id: http://devicetree.org/schemas/pinctrl/mediatek,mt65xx-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT65xx Pin Controller +title: MediaTek MT65xx Pin Controller maintainers: - Sean Wang <sean.wang@kernel.org> -description: |+ - The Mediatek's Pin controller is used to control SoC pins. +description: + The MediaTek's MT65xx Pin controller is used to control SoC pins. properties: compatible: @@ -30,7 +30,7 @@ properties: pins-are-numbered: $ref: /schemas/types.yaml#/definitions/flag - description: | + description: Specify the subnodes are using numbered pinmux to specify pins. (UNUSED) deprecated: true @@ -38,10 +38,10 @@ properties: "#gpio-cells": const: 2 - description: | - Number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. + description: + Number of cells in GPIO specifier. Since the generic GPIO binding is used, + the amount of cells must be specified as 2. See the below mentioned gpio + binding representation for description of particular cells. mediatek,pctl-regmap: $ref: /schemas/types.yaml#/definitions/phandle-array @@ -49,7 +49,7 @@ properties: maxItems: 1 minItems: 1 maxItems: 2 - description: | + description: Should be phandles of the syscfg node. interrupt-controller: true @@ -67,7 +67,7 @@ required: - "#gpio-cells" allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# patternProperties: 'pins$': @@ -77,25 +77,25 @@ patternProperties: '(^pins|pins?$)': type: object additionalProperties: false - description: | + description: A pinctrl node should contain at least one subnodes representing the pinctrl groups available on the machine. Each subnode will list the pins it needs, and how they should be configured, with regard to muxer configuration, pullups, drive strength, input enable/disable and input schmitt. - $ref: "/schemas/pinctrl/pincfg-node.yaml" + $ref: /schemas/pinctrl/pincfg-node.yaml properties: pinmux: description: - integer array, represents gpio pin number and mux setting. + Integer array, represents gpio pin number and mux setting. Supported pin number and mux varies for different SoCs, and are - defined as macros in <soc>-pinfunc.h directly. + defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. bias-disable: true bias-pull-up: - description: | + description: Besides generic pinconfig options, it can be used as the pull up settings for 2 pull resistors, R0 and R1. User can configure those special pins. Some macros have been defined for this usage, such @@ -117,7 +117,7 @@ patternProperties: input-schmitt-disable: true drive-strength: - description: | + description: Can support some arguments, such as MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h for valid arguments. diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml index a2141eb0854e..7f0e2d6cd6d9 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml @@ -4,15 +4,15 @@ $id: http://devicetree.org/schemas/pinctrl/mediatek,mt6779-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT6779 Pin Controller +title: MediaTek MT6779 Pin Controller maintainers: - Andy Teng <andy.teng@mediatek.com> - Sean Wang <sean.wang@kernel.org> description: - The MediaTek pin controller on MT6779 is used to control pin - functions, pull up/down resistance and drive strength options. + The MediaTek pin controller on MT6779 is used to control pin functions, pull + up/down resistance and drive strength options. properties: compatible: @@ -29,22 +29,22 @@ properties: "#gpio-cells": const: 2 - description: | - Number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. + description: + Number of cells in GPIO specifier. Since the generic GPIO binding is used, + the amount of cells must be specified as 2. See the below mentioned gpio + binding representation for description of particular cells. gpio-ranges: minItems: 1 maxItems: 5 - description: | + description: GPIO valid number range. interrupt-controller: true interrupts: maxItems: 1 - description: | + description: Specifies the summary IRQ. "#interrupt-cells": @@ -58,7 +58,7 @@ required: - "#gpio-cells" allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# - if: properties: compatible: @@ -118,19 +118,20 @@ patternProperties: patternProperties: '-pins*$': type: object - description: | + description: A pinctrl node should contain at least one subnodes representing the pinctrl groups available on the machine. Each subnode will list the pins it needs, and how they should be configured, with regard to muxer - configuration, pullups, drive strength, input enable/disable and input schmitt. - $ref: "/schemas/pinctrl/pincfg-node.yaml" + configuration, pullups, drive strength, input enable/disable and input + schmitt. + $ref: /schemas/pinctrl/pincfg-node.yaml properties: pinmux: description: - integer array, represents gpio pin number and mux setting. - Supported pin number and mux varies for different SoCs, and are defined - as macros in boot/dts/<soc>-pinfunc.h directly. + Integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are + defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. bias-disable: true @@ -159,7 +160,8 @@ patternProperties: mediatek,pull-up-adv: description: | Pull up setings for 2 pull resistors, R0 and R1. User can - configure those special pins. Valid arguments are described as below: + configure those special pins. Valid arguments are described as + below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. @@ -170,7 +172,8 @@ patternProperties: mediatek,pull-down-adv: description: | Pull down settings for 2 pull resistors, R0 and R1. User can - configure those special pins. Valid arguments are described as below: + configure those special pins. Valid arguments are described as + below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,pinctrl-mt6795.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml index 9399e0215526..601d86aecdd4 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,pinctrl-mt6795.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6795-pinctrl.yaml @@ -1,17 +1,17 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/pinctrl/mediatek,pinctrl-mt6795.yaml# +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt6795-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT6795 Pin Controller +title: MediaTek MT6795 Pin Controller maintainers: - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> - Sean Wang <sean.wang@kernel.org> -description: | - The Mediatek's Pin controller is used to control SoC pins. +description: + The MediaTek's MT6795 Pin controller is used to control SoC pins. properties: compatible: @@ -20,10 +20,10 @@ properties: gpio-controller: true '#gpio-cells': - description: | + description: Number of cells in GPIO specifier. Since the generic GPIO binding is used, - the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. + the amount of cells must be specified as 2. See the below mentioned gpio + binding representation for description of particular cells. const: 2 gpio-ranges: @@ -32,7 +32,7 @@ properties: reg: description: - Physical address base for gpio base and eint registers. + Physical address base for GPIO base and eint registers. minItems: 2 reg-names: @@ -65,8 +65,8 @@ patternProperties: A pinctrl node should contain at least one subnodes representing the pinctrl groups available on the machine. Each subnode will list the pins it needs, and how they should be configured, with regard to muxer - configuration, pullups, drive strength, input enable/disable and - input schmitt. + configuration, pullups, drive strength, input enable/disable and input + schmitt. An example of using macro: pincontroller { /* GPIO0 set as multifunction GPIO0 */ @@ -82,15 +82,14 @@ patternProperties: } }; }; - $ref: "pinmux-node.yaml" + $ref: pinmux-node.yaml properties: pinmux: - description: | + description: Integer array, represents gpio pin number and mux setting. Supported pin number and mux varies for different SoCs, and are - defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h - directly. + defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] @@ -100,20 +99,20 @@ patternProperties: - type: boolean - enum: [100, 101, 102, 103] description: mt6795 pull down PUPD/R0/R1 type define value. - description: | - For normal pull down type, it is not necessary to specify R1R0 - values; When pull down type is PUPD/R0/R1, adding R1R0 defines - will set different resistance values. + description: + For normal pull down type, it is not necessary to specify R1R0 + values; When pull down type is PUPD/R0/R1, adding R1R0 defines + will set different resistance values. bias-pull-up: oneOf: - type: boolean - enum: [100, 101, 102, 103] description: mt6795 pull up PUPD/R0/R1 type define value. - description: | - For normal pull up type, it is not necessary to specify R1R0 - values; When pull up type is PUPD/R0/R1, adding R1R0 defines - will set different resistance values. + description: + For normal pull up type, it is not necessary to specify R1R0 + values; When pull up type is PUPD/R0/R1, adding R1R0 defines will + set different resistance values. bias-disable: true @@ -132,7 +131,8 @@ patternProperties: mediatek,pull-up-adv: description: | Pull up setings for 2 pull resistors, R0 and R1. User can - configure those special pins. Valid arguments are described as below: + configure those special pins. Valid arguments are described as + below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. @@ -143,7 +143,8 @@ patternProperties: mediatek,pull-down-adv: description: | Pull down settings for 2 pull resistors, R0 and R1. User can - configure those special pins. Valid arguments are described as below: + configure those special pins. Valid arguments are described as + below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. @@ -155,7 +156,7 @@ patternProperties: - pinmux allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7620-pinctrl.yaml new file mode 100644 index 000000000000..591bc0664ec6 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7620-pinctrl.yaml @@ -0,0 +1,298 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7620-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek MT7620 Pin Controller + +maintainers: + - Arınç ÜNAL <arinc.unal@arinc9.com> + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: | + MediaTek MT7620 pin controller for MT7620 SoC. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,mt7620-pinctrl + +patternProperties: + '-pins$': + type: object + additionalProperties: false + + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + additionalProperties: false + + properties: + function: + description: + A string containing the name of the function to mux to the group. + enum: [ephy, gpio, gpio i2s, gpio uartf, i2c, i2s uartf, mdio, nand, + pa, pcie refclk, pcie rst, pcm gpio, pcm i2s, pcm uartf, + refclk, rgmii1, rgmii2, sd, spi, spi refclk, uartf, uartlite, + wdt refclk, wdt rst, wled] + + groups: + description: + An array of strings. Each string contains the name of a group. + maxItems: 1 + + required: + - groups + - function + + allOf: + - if: + properties: + function: + const: ephy + then: + properties: + groups: + enum: [ephy] + + - if: + properties: + function: + const: gpio + then: + properties: + groups: + enum: [ephy, i2c, mdio, nd_sd, pa, pcie, rgmii1, rgmii2, spi, + spi refclk, uartf, uartlite, wdt, wled] + + - if: + properties: + function: + const: gpio i2s + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: gpio uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: i2c + then: + properties: + groups: + enum: [i2c] + + - if: + properties: + function: + const: i2s uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: mdio + then: + properties: + groups: + enum: [mdio] + + - if: + properties: + function: + const: nand + then: + properties: + groups: + enum: [nd_sd] + + - if: + properties: + function: + const: pa + then: + properties: + groups: + enum: [pa] + + - if: + properties: + function: + const: pcie refclk + then: + properties: + groups: + enum: [pcie] + + - if: + properties: + function: + const: pcie rst + then: + properties: + groups: + enum: [pcie] + + - if: + properties: + function: + const: pcm gpio + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: pcm i2s + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: pcm uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: refclk + then: + properties: + groups: + enum: [mdio] + + - if: + properties: + function: + const: rgmii1 + then: + properties: + groups: + enum: [rgmii1] + + - if: + properties: + function: + const: rgmii2 + then: + properties: + groups: + enum: [rgmii2] + + - if: + properties: + function: + const: sd + then: + properties: + groups: + enum: [nd_sd] + + - if: + properties: + function: + const: spi + then: + properties: + groups: + enum: [spi] + + - if: + properties: + function: + const: spi refclk + then: + properties: + groups: + enum: [spi refclk] + + - if: + properties: + function: + const: uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: uartlite + then: + properties: + groups: + enum: [uartlite] + + - if: + properties: + function: + const: wdt refclk + then: + properties: + groups: + enum: [wdt] + + - if: + properties: + function: + const: wdt rst + then: + properties: + groups: + enum: [wdt] + + - if: + properties: + function: + const: wled + then: + properties: + groups: + enum: [wled] + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + +additionalProperties: false + +examples: + - | + pinctrl { + compatible = "ralink,mt7620-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7621-pinctrl.yaml index 1b1d37b981d9..e568b9c13727 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7621-pinctrl.yaml @@ -1,17 +1,17 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/pinctrl/ralink,mt7621-pinctrl.yaml# +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7621-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Ralink MT7621 Pin Controller +title: MediaTek MT7621 Pin Controller maintainers: - Arınç ÜNAL <arinc.unal@arinc9.com> - Sergio Paracuellos <sergio.paracuellos@gmail.com> -description: - Ralink MT7621 pin controller for MT7621 SoC. +description: | + MediaTek MT7621 pin controller for MT7621 SoC. The pin controller can only set the muxing of pin groups. Muxing individual pins is not supported. There is no pinconf support. @@ -22,11 +22,14 @@ properties: patternProperties: '-pins$': type: object + additionalProperties: false + patternProperties: '^(.*-)?pinmux$': type: object description: node for pinctrl. $ref: pinmux-node.yaml# + additionalProperties: false properties: function: @@ -236,12 +239,8 @@ patternProperties: groups: enum: [wdt] - additionalProperties: false - - additionalProperties: false - allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml index ac93eb8f01a6..bd72a326e6e0 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml @@ -4,12 +4,12 @@ $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT7622 Pin Controller +title: MediaTek MT7622 Pin Controller maintainers: - Sean Wang <sean.wang@kernel.org> -description: |+ +description: The MediaTek's MT7622 Pin controller is used to control SoC pins. properties: @@ -29,10 +29,10 @@ properties: "#gpio-cells": const: 2 - description: | - Number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. + description: + Number of cells in GPIO specifier. Since the generic GPIO binding is used, + the amount of cells must be specified as 2. See the below mentioned gpio + binding representation for description of particular cells. interrupt-controller: true @@ -43,7 +43,7 @@ properties: const: 2 allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible @@ -68,18 +68,18 @@ patternProperties: '^mux(-|$)': type: object additionalProperties: false - description: | + description: pinmux configuration nodes. - $ref: "/schemas/pinctrl/pinmux-node.yaml" + $ref: /schemas/pinctrl/pinmux-node.yaml properties: function: - description: | + description: A string containing the name of the function to mux to the group. enum: [emmc, eth, i2c, i2s, ir, led, flash, pcie, pmic, pwm, sd, spi, tdm, uart, watchdog, wifi] groups: - description: | + description: An array of strings. Each string contains the name of a group. drive-strength: @@ -247,18 +247,18 @@ patternProperties: '^conf(-|$)': type: object additionalProperties: false - description: | + description: pinconf configuration nodes. - $ref: "/schemas/pinctrl/pincfg-node.yaml" + $ref: /schemas/pinctrl/pincfg-node.yaml properties: groups: - description: | + description: An array of strings. Each string contains the name of a group. Valid values are the same as the pinmux node. pins: - description: | + description: An array of strings. Each string contains the name of a pin. enum: [GPIO_A, I2S1_IN, I2S1_OUT, I2S_BCLK, I2S_WS, I2S_MCLK, TXD0, RXD0, SPI_WP, SPI_HOLD, SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS, @@ -315,14 +315,14 @@ patternProperties: enum: [0, 1] mediatek,tdsel: - description: | + description: An integer describing the steps for output level shifter duty cycle when asserted (high pulse width adjustment). Valid arguments are from 0 to 15. $ref: /schemas/types.yaml#/definitions/uint32 mediatek,rdsel: - description: | + description: An integer describing the steps for input level shifter duty cycle when asserted (high pulse width adjustment). Valid arguments are from 0 to 63. diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt76x8-pinctrl.yaml index 1e63ea34146a..31849dd5940b 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt76x8-pinctrl.yaml @@ -1,50 +1,46 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/pinctrl/ralink,mt7620-pinctrl.yaml# +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt76x8-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Ralink MT7620 Pin Controller +title: MediaTek MT76X8 Pin Controller maintainers: - Arınç ÜNAL <arinc.unal@arinc9.com> - Sergio Paracuellos <sergio.paracuellos@gmail.com> -description: - Ralink MT7620 pin controller for MT7620, MT7628 and MT7688 SoCs. +description: | + MediaTek MT76X8 pin controller for MT7628 and MT7688 SoCs. The pin controller can only set the muxing of pin groups. Muxing individual pins is not supported. There is no pinconf support. properties: compatible: - const: ralink,mt7620-pinctrl + const: ralink,mt76x8-pinctrl patternProperties: '-pins$': type: object + additionalProperties: false + patternProperties: '^(.*-)?pinmux$': type: object description: node for pinctrl. $ref: pinmux-node.yaml# + additionalProperties: false properties: function: description: A string containing the name of the function to mux to the group. - anyOf: - - description: For MT7620 SoC - enum: [ephy, gpio, gpio i2s, gpio uartf, i2c, i2s uartf, mdio, nand, pa, - pcie refclk, pcie rst, pcm gpio, pcm i2s, pcm uartf, refclk, - rgmii1, rgmii2, sd, spi, spi refclk, uartf, uartlite, wdt refclk, - wdt rst, wled] - - - description: For MT7628 and MT7688 SoCs - enum: [antenna, debug, gpio, i2c, i2s, jtag, p0led_an, p0led_kn, - p1led_an, p1led_kn, p2led_an, p2led_kn, p3led_an, p3led_kn, - p4led_an, p4led_kn, pcie, pcm, perst, pwm, pwm0, pwm1, pwm_uart2, - refclk, rsvd, sdxc, sdxc d5 d4, sdxc d6, sdxc d7, spi, spi cs1, - spis, sw_r, uart0, uart1, uart2, utif, wdt, wled_an, wled_kn, -] + enum: [antenna, debug, gpio, i2c, i2s, jtag, p0led_an, p0led_kn, + p1led_an, p1led_kn, p2led_an, p2led_kn, p3led_an, p3led_kn, + p4led_an, p4led_kn, pcie, pcm, perst, pwm, pwm0, pwm1, + pwm_uart2, refclk, rsvd, sdxc, sdxc d5 d4, sdxc d6, sdxc d7, + spi, spi cs1, spis, sw_r, uart0, uart1, uart2, utif, wdt, + wled_an, wled_kn, -] groups: description: @@ -77,48 +73,15 @@ patternProperties: - if: properties: function: - const: ephy - then: - properties: - groups: - enum: [ephy] - - - if: - properties: - function: const: gpio then: properties: groups: - anyOf: - - description: For MT7620 SoC - enum: [ephy, i2c, mdio, nd_sd, pa, pcie, rgmii1, rgmii2, - spi, spi refclk, uartf, uartlite, wdt, wled] - - - description: For MT7628 and MT7688 SoCs - enum: [gpio, i2c, i2s, p0led_an, p0led_kn, p1led_an, - p1led_kn, p2led_an, p2led_kn, p3led_an, p3led_kn, - p4led_an, p4led_kn, perst, pwm0, pwm1, refclk, - sdmode, spi, spi cs1, spis, uart0, uart1, uart2, - wdt, wled_an, wled_kn] - - - if: - properties: - function: - const: gpio i2s - then: - properties: - groups: - enum: [uartf] - - - if: - properties: - function: - const: gpio uartf - then: - properties: - groups: - enum: [uartf] + enum: [gpio, i2c, i2s, p0led_an, p0led_kn, p1led_an, p1led_kn, + p2led_an, p2led_kn, p3led_an, p3led_kn, p4led_an, + p4led_kn, perst, pwm0, pwm1, refclk, sdmode, spi, + spi cs1, spis, uart0, uart1, uart2, wdt, wled_an, + wled_kn] - if: properties: @@ -141,15 +104,6 @@ patternProperties: - if: properties: function: - const: i2s uartf - then: - properties: - groups: - enum: [uartf] - - - if: - properties: - function: const: jtag then: properties: @@ -161,24 +115,6 @@ patternProperties: - if: properties: function: - const: mdio - then: - properties: - groups: - enum: [mdio] - - - if: - properties: - function: - const: nand - then: - properties: - groups: - enum: [nd_sd] - - - if: - properties: - function: const: p0led_an then: properties: @@ -269,15 +205,6 @@ patternProperties: - if: properties: function: - const: pa - then: - properties: - groups: - enum: [pa] - - - if: - properties: - function: const: pcie then: properties: @@ -287,24 +214,6 @@ patternProperties: - if: properties: function: - const: pcie refclk - then: - properties: - groups: - enum: [pcie] - - - if: - properties: - function: - const: pcie rst - then: - properties: - groups: - enum: [pcie] - - - if: - properties: - function: const: pcm then: properties: @@ -314,33 +223,6 @@ patternProperties: - if: properties: function: - const: pcm gpio - then: - properties: - groups: - enum: [uartf] - - - if: - properties: - function: - const: pcm i2s - then: - properties: - groups: - enum: [uartf] - - - if: - properties: - function: - const: pcm uartf - then: - properties: - groups: - enum: [uartf] - - - if: - properties: - function: const: perst then: properties: @@ -390,30 +272,7 @@ patternProperties: then: properties: groups: - anyOf: - - description: For MT7620 SoC - enum: [mdio] - - - description: For MT7628 and MT7688 SoCs - enum: [gpio, refclk, spi cs1] - - - if: - properties: - function: - const: rgmii1 - then: - properties: - groups: - enum: [rgmii1] - - - if: - properties: - function: - const: rgmii2 - then: - properties: - groups: - enum: [rgmii2] + enum: [gpio, refclk, spi cs1] - if: properties: @@ -427,15 +286,6 @@ patternProperties: - if: properties: function: - const: sd - then: - properties: - groups: - enum: [nd_sd] - - - if: - properties: - function: const: sdxc then: properties: @@ -490,15 +340,6 @@ patternProperties: - if: properties: function: - const: spi refclk - then: - properties: - groups: - enum: [spi refclk] - - - if: - properties: - function: const: spis then: properties: @@ -544,24 +385,6 @@ patternProperties: - if: properties: function: - const: uartf - then: - properties: - groups: - enum: [uartf] - - - if: - properties: - function: - const: uartlite - then: - properties: - groups: - enum: [uartlite] - - - if: - properties: - function: const: utif then: properties: @@ -581,33 +404,6 @@ patternProperties: - if: properties: function: - const: wdt refclk - then: - properties: - groups: - enum: [wdt] - - - if: - properties: - function: - const: wdt rst - then: - properties: - groups: - enum: [wdt] - - - if: - properties: - function: - const: wled - then: - properties: - groups: - enum: [wled] - - - if: - properties: - function: const: wled_an then: properties: @@ -632,12 +428,8 @@ patternProperties: groups: enum: [i2c, spi cs1, uart0] - additionalProperties: false - - additionalProperties: false - allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible @@ -647,7 +439,7 @@ additionalProperties: false examples: - | pinctrl { - compatible = "ralink,mt7620-pinctrl"; + compatible = "ralink,mt76x8-pinctrl"; i2c_pins: i2c0-pins { pinmux { diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml index 74c66fbcb2ae..10717cee9058 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7981-pinctrl.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7981-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT7981 Pin Controller +title: MediaTek MT7981 Pin Controller maintainers: - Daniel Golle <daniel@makrotopia.org> @@ -37,7 +37,7 @@ properties: "#gpio-cells": const: 2 - description: > + description: Number of cells in GPIO specifier. Since the generic GPIO binding is used, the amount of cells must be specified as 2. See the below mentioned gpio binding representation for description of particular cells. @@ -111,7 +111,9 @@ patternProperties: "watchdog1" "watchdog" 13 "udi" "udi" 9, 10, 11, 12, 13 "drv_vbus" "usb" 14 - "emmc_45" "flash" 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25 + "emmc_45" "flash" 15, 16, 17, 18, 19, 20, 21, 22, 23, + 24, 25 + "snfi" "flash" 16, 17, 18, 19, 20, 21 "spi0" "spi" 16, 17, 18, 19 "spi0_wp_hold" "spi" 20, 21 @@ -148,7 +150,7 @@ patternProperties: "wf5g_led0" "led" 31 "wf5g_led1" "led" 35 "mt7531_int" "eth" 38 - "ant_sel" "ant" 14, 15, 16, 17, 18, 19, 20, 21, 22 + "ant_sel" "ant" 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 34, 35 $ref: /schemas/pinctrl/pinmux-node.yaml @@ -256,7 +258,8 @@ patternProperties: then: properties: groups: - enum: [gbe_led0, gbe_led1, wf2g_led0, wf2g_led1, wf5g_led0, wf5g_led1] + enum: [gbe_led0, gbe_led1, wf2g_led0, wf2g_led1, wf5g_led0, + wf5g_led1] - if: properties: function: @@ -275,7 +278,8 @@ patternProperties: properties: groups: items: - enum: [spi1_0, spi0, spi0_wp_hold, spi1_1, spi2, spi2_wp_hold] + enum: [spi1_0, spi0, spi0_wp_hold, spi1_1, spi2, + spi2_wp_hold] maxItems: 4 - if: properties: @@ -332,13 +336,14 @@ patternProperties: JTAG_JTDO, JTAG_JTDI, JTAG_JTMS, JTAG_JTCLK, JTAG_JTRST_N, WO_JTAG_JTDO, WO_JTAG_JTDI, WO_JTAG_JTMS, WO_JTAG_JTCLK, WO_JTAG_JTRST_N, USB_VBUS, PWM0, SPI0_CLK, SPI0_MOSI, - SPI0_MISO, SPI0_CS, SPI0_HOLD, SPI0_WP, SPI1_CLK, SPI1_MOSI, - SPI1_MISO, SPI1_CS, SPI2_CLK, SPI2_MOSI, SPI2_MISO, SPI2_CS, - SPI2_HOLD, SPI2_WP, UART0_RXD, UART0_TXD, PCIE_CLK_REQ, - PCIE_WAKE_N, SMI_MDC, SMI_MDIO, GBE_INT, GBE_RESET, - WF_DIG_RESETB, WF_CBA_RESETB, WF_XO_REQ, WF_TOP_CLK, - WF_TOP_DATA, WF_HB1, WF_HB2, WF_HB3, WF_HB4, WF_HB0, - WF_HB0_B, WF_HB5, WF_HB6, WF_HB7, WF_HB8, WF_HB9, WF_HB10] + SPI0_MISO, SPI0_CS, SPI0_HOLD, SPI0_WP, SPI1_CLK, + SPI1_MOSI, SPI1_MISO, SPI1_CS, SPI2_CLK, SPI2_MOSI, + SPI2_MISO, SPI2_CS, SPI2_HOLD, SPI2_WP, UART0_RXD, + UART0_TXD, PCIE_CLK_REQ, PCIE_WAKE_N, SMI_MDC, SMI_MDIO, + GBE_INT, GBE_RESET, WF_DIG_RESETB, WF_CBA_RESETB, + WF_XO_REQ, WF_TOP_CLK, WF_TOP_DATA, WF_HB1, WF_HB2, WF_HB3, + WF_HB4, WF_HB0, WF_HB0_B, WF_HB5, WF_HB6, WF_HB7, WF_HB8, + WF_HB9, WF_HB10] maxItems: 57 bias-disable: true @@ -348,7 +353,7 @@ patternProperties: - type: boolean description: normal pull up. - enum: [100, 101, 102, 103] - description: > + description: PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in dt-bindings/pinctrl/mt65xx.h. @@ -357,7 +362,7 @@ patternProperties: - type: boolean description: normal pull down. - enum: [100, 101, 102, 103] - description: > + description: PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in dt-bindings/pinctrl/mt65xx.h. diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml index 216b356cd519..0f615ada290a 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml @@ -4,12 +4,12 @@ $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7986-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT7986 Pin Controller +title: MediaTek MT7986 Pin Controller maintainers: - Sean Wang <sean.wang@kernel.org> -description: |+ +description: The MediaTek's MT7986 Pin controller is used to control SoC pins. properties: @@ -37,15 +37,15 @@ properties: "#gpio-cells": const: 2 - description: | - Number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. + description: + Number of cells in GPIO specifier. Since the generic GPIO binding is used, + the amount of cells must be specified as 2. See the below mentioned gpio + binding representation for description of particular cells. gpio-ranges: minItems: 1 maxItems: 5 - description: | + description: GPIO valid number range. interrupt-controller: true @@ -57,7 +57,7 @@ properties: const: 2 allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible @@ -72,7 +72,7 @@ patternProperties: additionalProperties: false patternProperties: - '.*mux.*': + '^.*mux.*$': type: object additionalProperties: false description: | @@ -81,7 +81,7 @@ patternProperties: The following table shows the effective values of "group", "function" properties and chip pinout pins - groups function pins (in pin#) + groups function pins (in pin#) --------------------------------------------------------------------- "watchdog" "watchdog" 0 "wifi_led" "led" 1, 2 @@ -97,8 +97,9 @@ patternProperties: "pwm1_0" "pwm" 22, "snfi" "flash" 23, 24, 25, 26, 27, 28 "spi1_2" "spi" 29, 30, 31, 32 - "emmc_45" "emmc" 22, 23, 24, 25, 26, 27, 28, 29, 30, - 31, 32 + "emmc_45" "emmc" 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, + 32 + "spi1_1" "spi" 23, 24, 25, 26 "uart1_2_rx_tx" "uart" 29, 30 "uart1_2_cts_rts" "uart" 31, 32 @@ -115,8 +116,9 @@ patternProperties: "pcie_pereset" "pcie" 41 "uart1" "uart" 42, 43, 44, 45 "uart2" "uart" 46, 47, 48, 49 - "emmc_51" "emmc" 50, 51, 52, 53, 54, 55, 56, 57, 57, - 59, 60, 61 + "emmc_51" "emmc" 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, + 60, 61 + "pcm" "audio" 62, 63, 64, 65 "i2s" "audio" 62, 63, 64, 65 "switch_int" "eth" 66 @@ -126,21 +128,20 @@ patternProperties: "wf_dbdc" "wifi" 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85 - $ref: "/schemas/pinctrl/pinmux-node.yaml" + $ref: /schemas/pinctrl/pinmux-node.yaml properties: function: - description: | + description: A string containing the name of the function to mux to the group. There is no "audio", "pcie" functions on mt7986b, you can only use those functions on mt7986a. enum: [audio, emmc, eth, i2c, led, flash, pcie, pwm, spi, uart, watchdog, wifi] groups: - description: | + description: An array of strings. Each string contains the name of a group. - There is no "pcie_pereset", "uart1", "uart2" "emmc_51", "pcm", - and "i2s" groups on mt7986b, you can only use those groups on - mt7986a. + There is no "pcie_pereset", "uart1", "uart2" "emmc_51", "pcm", and + "i2s" groups on mt7986b, you can only use those groups on mt7986a. required: - function - groups @@ -255,32 +256,33 @@ patternProperties: items: enum: [wf_2g, wf_5g, wf_dbdc] maxItems: 3 - '.*conf.*': + '^.*conf.*$': type: object additionalProperties: false - description: | + description: pinconf configuration nodes. - $ref: "/schemas/pinctrl/pincfg-node.yaml" + $ref: /schemas/pinctrl/pincfg-node.yaml properties: pins: - description: | - An array of strings. Each string contains the name of a pin. - There is no PIN 41 to PIN 65 above on mt7686b, you can only use - those pins on mt7986a. + description: + An array of strings. Each string contains the name of a pin. There + is no PIN 41 to PIN 65 above on mt7686b, you can only use those + pins on mt7986a. items: enum: [SYS_WATCHDOG, WF2G_LED, WF5G_LED, I2C_SCL, I2C_SDA, GPIO_0, GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5, GPIO_6, GPIO_7, - GPIO_8, GPIO_9, GPIO_10, GPIO_11, GPIO_12, GPIO_13, GPIO_14, - GPIO_15, PWM0, PWM1, SPI0_CLK, SPI0_MOSI, SPI0_MISO, SPI0_CS, - SPI0_HOLD, SPI0_WP, SPI1_CLK, SPI1_MOSI, SPI1_MISO, SPI1_CS, - SPI2_CLK, SPI2_MOSI, SPI2_MISO, SPI2_CS, SPI2_HOLD, SPI2_WP, - UART0_RXD, UART0_TXD, PCIE_PERESET_N, UART1_RXD, UART1_TXD, - UART1_CTS, UART1_RTS, UART2_RXD, UART2_TXD, UART2_CTS, - UART2_RTS, EMMC_DATA_0, EMMC_DATA_1, EMMC_DATA_2, - EMMC_DATA_3, EMMC_DATA_4, EMMC_DATA_5, EMMC_DATA_6, - EMMC_DATA_7, EMMC_CMD, EMMC_CK, EMMC_DSL, EMMC_RSTB, PCM_DTX, - PCM_DRX, PCM_CLK, PCM_FS, MT7531_INT, SMI_MDC, SMI_MDIO, + GPIO_8, GPIO_9, GPIO_10, GPIO_11, GPIO_12, GPIO_13, + GPIO_14, GPIO_15, PWM0, PWM1, SPI0_CLK, SPI0_MOSI, + SPI0_MISO, SPI0_CS, SPI0_HOLD, SPI0_WP, SPI1_CLK, + SPI1_MOSI, SPI1_MISO, SPI1_CS, SPI2_CLK, SPI2_MOSI, + SPI2_MISO, SPI2_CS, SPI2_HOLD, SPI2_WP, UART0_RXD, + UART0_TXD, PCIE_PERESET_N, UART1_RXD, UART1_TXD, UART1_CTS, + UART1_RTS, UART2_RXD, UART2_TXD, UART2_CTS, UART2_RTS, + EMMC_DATA_0, EMMC_DATA_1, EMMC_DATA_2, EMMC_DATA_3, + EMMC_DATA_4, EMMC_DATA_5, EMMC_DATA_6, EMMC_DATA_7, + EMMC_CMD, EMMC_CK, EMMC_DSL, EMMC_RSTB, PCM_DTX, PCM_DRX, + PCM_CLK, PCM_FS, MT7531_INT, SMI_MDC, SMI_MDIO, WF0_DIG_RESETB, WF0_CBA_RESETB, WF0_XO_REQ, WF0_TOP_CLK, WF0_TOP_DATA, WF0_HB1, WF0_HB2, WF0_HB3, WF0_HB4, WF0_HB0, WF0_HB0_B, WF0_HB5, WF0_HB6, WF0_HB7, WF0_HB8, WF0_HB9, @@ -297,7 +299,7 @@ patternProperties: - type: boolean description: normal pull up. - enum: [100, 101, 102, 103] - description: | + description: PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in dt-bindings/pinctrl/mt65xx.h. @@ -306,7 +308,7 @@ patternProperties: - type: boolean description: normal pull down. - enum: [100, 101, 102, 103] - description: | + description: PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0 defines in dt-bindings/pinctrl/mt65xx.h. diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml index c30cd0d010dd..ff24cf29eea7 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml @@ -4,12 +4,12 @@ $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT8183 Pin Controller +title: MediaTek MT8183 Pin Controller maintainers: - Sean Wang <sean.wang@kernel.org> -description: |+ +description: The MediaTek's MT8183 Pin controller is used to control SoC pins. properties: @@ -37,15 +37,15 @@ properties: "#gpio-cells": const: 2 - description: | - Number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. + description: + Number of cells in GPIO specifier. Since the generic GPIO binding is used, + the amount of cells must be specified as 2. See the below mentioned gpio + binding representation for description of particular cells. gpio-ranges: minItems: 1 maxItems: 5 - description: | + description: GPIO valid number range. interrupt-controller: true @@ -57,7 +57,7 @@ properties: const: 2 allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible @@ -74,18 +74,18 @@ patternProperties: '^pins': type: object additionalProperties: false - description: | + description: A pinctrl node should contain at least one subnodes representing the pinctrl groups available on the machine. Each subnode will list the pins it needs, and how they should be configured, with regard to muxer configuration, pullups, drive strength, input enable/disable and input schmitt. - $ref: "/schemas/pinctrl/pincfg-node.yaml" + $ref: /schemas/pinctrl/pincfg-node.yaml properties: pinmux: description: - integer array, represents gpio pin number and mux setting. + Integer array, represents gpio pin number and mux setting. Supported pin number and mux varies for different SoCs, and are defined as macros in <soc>-pinfunc.h directly. @@ -110,8 +110,13 @@ patternProperties: drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] + drive-strength-microamp: + enum: [125, 250, 500, 1000] + mediatek,drive-strength-adv: + deprecated: true description: | + DEPRECATED: Please use drive-strength-microamp instead. Describe the specific driving setup property. For I2C pins, the existing generic driving setup can only support 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they @@ -139,7 +144,8 @@ patternProperties: mediatek,pull-up-adv: description: | Pull up setings for 2 pull resistors, R0 and R1. User can - configure those special pins. Valid arguments are described as below: + configure those special pins. Valid arguments are described as + below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. @@ -150,7 +156,8 @@ patternProperties: mediatek,pull-down-adv: description: | Pull down settings for 2 pull resistors, R0 and R1. User can - configure those special pins. Valid arguments are described as below: + configure those special pins. Valid arguments are described as + below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. @@ -159,14 +166,14 @@ patternProperties: enum: [0, 1, 2, 3] mediatek,tdsel: - description: | + description: An integer describing the steps for output level shifter duty cycle when asserted (high pulse width adjustment). Valid arguments are from 0 to 15. $ref: /schemas/types.yaml#/definitions/uint32 mediatek,rdsel: - description: | + description: An integer describing the steps for input level shifter duty cycle when asserted (high pulse width adjustment). Valid arguments are from 0 to 63. @@ -215,7 +222,7 @@ examples: pinmux = <PINMUX_GPIO48__FUNC_SCL5>, <PINMUX_GPIO49__FUNC_SDA5>; mediatek,pull-up-adv = <3>; - mediatek,drive-strength-adv = <7>; + drive-strength-microamp = <1000>; }; }; @@ -224,7 +231,6 @@ examples: pinmux = <PINMUX_GPIO50__FUNC_SCL3>, <PINMUX_GPIO51__FUNC_SDA3>; mediatek,pull-down-adv = <2>; - mediatek,drive-strength-adv = <4>; }; }; }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8186-pinctrl.yaml index 26573a793b57..69136ddd0bbc 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8186-pinctrl.yaml @@ -1,16 +1,16 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8186.yaml# +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8186-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT8186 Pin Controller +title: MediaTek MT8186 Pin Controller maintainers: - Sean Wang <sean.wang@mediatek.com> -description: | - The Mediatek's Pin controller is used to control SoC pins. +description: + The MediaTek's MT8186 Pin controller is used to control SoC pins. properties: compatible: @@ -19,10 +19,10 @@ properties: gpio-controller: true '#gpio-cells': - description: | + description: Number of cells in GPIO specifier. Since the generic GPIO binding is used, - the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. + the amount of cells must be specified as 2. See the below mentioned gpio + binding representation for description of particular cells. const: 2 gpio-ranges: @@ -31,14 +31,14 @@ properties: gpio-line-names: true reg: - description: | - Physical address base for gpio base registers. There are 8 different GPIO + description: + Physical address base for GPIO base registers. There are 8 different GPIO physical address base in mt8186. maxItems: 8 reg-names: - description: | - Gpio base register names. + description: + GPIO base register names. items: - const: iocfg0 - const: iocfg_lt @@ -60,9 +60,9 @@ properties: mediatek,rsel-resistance-in-si-unit: type: boolean - description: | - Identifying i2c pins pull up/down type which is RSEL. It can support - RSEL define or si unit value(ohm) to set different resistance. + description: + Identifying i2c pins pull up/down type which is RSEL. It can support RSEL + define or si unit value(ohm) to set different resistance. # PIN CONFIGURATION NODES patternProperties: @@ -77,8 +77,8 @@ patternProperties: A pinctrl node should contain at least one subnodes representing the pinctrl groups available on the machine. Each subnode will list the pins it needs, and how they should be configured, with regard to muxer - configuration, pullups, drive strength, input enable/disable and - input schmitt. + configuration, pullups, drive strength, input enable/disable and input + schmitt. An example of using macro: pincontroller { /* GPIO0 set as multifunction GPIO0 */ @@ -94,15 +94,14 @@ patternProperties: } }; }; - $ref: "pinmux-node.yaml" + $ref: pinmux-node.yaml properties: pinmux: - description: | + description: Integer array, represents gpio pin number and mux setting. Supported pin number and mux varies for different SoCs, and are - defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h - directly. + defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] @@ -129,10 +128,10 @@ patternProperties: For pull down type is RSEL, it can add RSEL define & resistance value(ohm) to set different resistance by identifying property "mediatek,rsel-resistance-in-si-unit". - It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" - & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" - define in mt8186. It can also support resistance value(ohm) - "75000" & "5000" in mt8186. + It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" & + "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" define in + mt8186. It can also support resistance value(ohm) "75000" & "5000" + in mt8186. An example of using RSEL define: pincontroller { i2c0_pin { @@ -174,10 +173,10 @@ patternProperties: For pull up type is RSEL, it can add RSEL define & resistance value(ohm) to set different resistance by identifying property "mediatek,rsel-resistance-in-si-unit". - It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" - & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" - define in mt8186. It can also support resistance value(ohm) - "1000" & "5000" & "10000" & "75000" in mt8186. + It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" & + "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" define in + mt8186. It can also support resistance value(ohm) "1000" & "5000" + & "10000" & "75000" in mt8186. An example of using si unit resistance value(ohm): &pio { mediatek,rsel-resistance-in-si-unit; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8188-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8188-pinctrl.yaml index 7e750f1e643d..e994b0c70dbf 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8188-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8188-pinctrl.yaml @@ -9,7 +9,7 @@ title: MediaTek MT8188 Pin Controller maintainers: - Hui Liu <hui.liu@mediatek.com> -description: | +description: The MediaTek's MT8188 Pin controller is used to control SoC pins. properties: @@ -19,10 +19,10 @@ properties: gpio-controller: true '#gpio-cells': - description: | - Number of cells in GPIO specifier, should be two. The first cell - is the pin number, the second cell is used to specify optional - parameters which are defined in <dt-bindings/gpio/gpio.h>. + description: + Number of cells in GPIO specifier, should be two. The first cell is the + pin number, the second cell is used to specify optional parameters which + are defined in <dt-bindings/gpio/gpio.h>. const: 2 gpio-ranges: @@ -59,10 +59,11 @@ properties: mediatek,rsel-resistance-in-si-unit: type: boolean - description: | - We provide two methods to select the resistance for I2C when pull up or pull down. - The first is by RSEL definition value, another one is by resistance value(ohm). - This flag is used to identify if the method is resistance(si unit) value. + description: + We provide two methods to select the resistance for I2C when pull up or + pull down. The first is by RSEL definition value, another one is by + resistance value(ohm). This flag is used to identify if the method is + resistance(si unit) value. # PIN CONFIGURATION NODES patternProperties: @@ -73,22 +74,22 @@ patternProperties: patternProperties: '^pins': type: object - $ref: "/schemas/pinctrl/pincfg-node.yaml" + $ref: /schemas/pinctrl/pincfg-node.yaml additionalProperties: false - description: | + description: A pinctrl node should contain at least one subnode representing the pinctrl groups available on the machine. Each subnode will list the pins it needs, and how they should be configured, with regard to muxer - configuration, pullups, drive strength, input enable/disable and - input schmitt. + configuration, pullups, drive strength, input enable/disable and input + schmitt. properties: pinmux: - description: | + description: Integer array, represents gpio pin number and mux setting. Supported pin number and mux varies for different SoCs, and are - defined as macros in dt-bindings/pinctrl/mediatek,<soc>-pinfunc.h - directly. + defined as macros in dt-bindings/pinctrl/mediatek,mt8188-pinfunc.h + directly, for this SoC. drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] @@ -106,18 +107,21 @@ patternProperties: - enum: [75000, 5000] description: mt8188 pull down RSEL type si unit value(ohm). description: | - For pull down type is normal, it doesn't need add RSEL & R1R0 define - and resistance value. + For pull down type is normal, it doesn't need add RSEL & R1R0 + define and resistance value. For pull down type is PUPD/R0/R1 type, it can add R1R0 define to set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & - "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & "MTK_PUPD_SET_R1R0_11" - define in mt8188. - For pull down type is RSEL, it can add RSEL define & resistance value(ohm) - to set different resistance by identifying property "mediatek,rsel-resistance-in-si-unit". - It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" - & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" - & "MTK_PULL_SET_RSEL_101" & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" - define in mt8188. It can also support resistance value(ohm) "75000" & "5000" in mt8188. + "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & + "MTK_PUPD_SET_R1R0_11" define in mt8188. + For pull down type is RSEL, it can add RSEL define & resistance + value(ohm) to set different resistance by identifying property + "mediatek,rsel-resistance-in-si-unit". It can support + "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" & + "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & + "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" & + "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" define in + mt8188. It can also support resistance value(ohm) "75000" & "5000" + in mt8188. bias-pull-up: oneOf: @@ -131,17 +135,19 @@ patternProperties: description: | For pull up type is normal, it don't need add RSEL & R1R0 define and resistance value. - For pull up type is PUPD/R0/R1 type, it can add R1R0 define to - set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & - "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & "MTK_PUPD_SET_R1R0_11" - define in mt8188. - For pull up type is RSEL, it can add RSEL define & resistance value(ohm) - to set different resistance by identifying property "mediatek,rsel-resistance-in-si-unit". - It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" - & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" - & "MTK_PULL_SET_RSEL_101" & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" - define in mt8188. It can also support resistance value(ohm) - "1000" & "1500" & "2000" & "3000" & "4000" & "5000" & "10000" & "75000" in mt8188. + For pull up type is PUPD/R0/R1 type, it can add R1R0 define to set + different resistance. It can support "MTK_PUPD_SET_R1R0_00" & + "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & + "MTK_PUPD_SET_R1R0_11" define in mt8188. + For pull up type is RSEL, it can add RSEL define & resistance + value(ohm) to set different resistance by identifying property + "mediatek,rsel-resistance-in-si-unit". It can support + "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" & + "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & + "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" & + "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" define in + mt8188. It can also support resistance value(ohm) "1000" & "1500" + & "2000" & "3000" & "4000" & "5000" & "10000" & "75000" in mt8188. bias-disable: true diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8192-pinctrl.yaml index e0e943e5b874..1686427eb854 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8192-pinctrl.yaml @@ -1,16 +1,16 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8192.yaml# +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8192-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT8192 Pin Controller +title: MediaTek MT8192 Pin Controller maintainers: - Sean Wang <sean.wang@mediatek.com> -description: | - The Mediatek's Pin controller is used to control SoC pins. +description: + The MediaTek's MT8192 Pin controller is used to control SoC pins. properties: compatible: @@ -19,27 +19,27 @@ properties: gpio-controller: true '#gpio-cells': - description: | + description: Number of cells in GPIO specifier. Since the generic GPIO binding is used, - the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. + the amount of cells must be specified as 2. See the below mentioned gpio + binding representation for description of particular cells. const: 2 gpio-ranges: - description: gpio valid number range. + description: GPIO valid number range. maxItems: 1 gpio-line-names: true reg: - description: | - Physical address base for gpio base registers. There are 11 GPIO - physical address base in mt8192. + description: + Physical address base for GPIO base registers. There are 11 GPIO physical + address base in mt8192. maxItems: 11 reg-names: - description: | - Gpio base register names. + description: + GPIO base register names. maxItems: 11 interrupt-controller: true @@ -51,7 +51,7 @@ properties: description: The interrupt outputs to sysirq. maxItems: 1 -#PIN CONFIGURATION NODES +# PIN CONFIGURATION NODES patternProperties: '-pins$': type: object @@ -59,25 +59,26 @@ patternProperties: patternProperties: '^pins': type: object - description: | + description: A pinctrl node should contain at least one subnodes representing the pinctrl groups available on the machine. Each subnode will list the pins it needs, and how they should be configured, with regard to muxer - configuration, pullups, drive strength, input enable/disable and - input schmitt. - $ref: "pinmux-node.yaml" + configuration, pullups, drive strength, input enable/disable and input + schmitt. + $ref: pinmux-node.yaml properties: pinmux: - description: | + description: Integer array, represents gpio pin number and mux setting. - Supported pin number and mux varies for different SoCs, and are defined - as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. + Supported pin number and mux varies for different SoCs, and are + defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. drive-strength: - description: | - It can support some arguments, such as MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See - dt-bindings/pinctrl/mt65xx.h. It can only support 2/4/6/8/10/12/14/16mA in mt8192. + description: + It can support some arguments, such as MTK_DRIVE_4mA, + MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h. It can only + support 2/4/6/8/10/12/14/16mA in mt8192. enum: [2, 4, 6, 8, 10, 12, 14, 16] drive-strength-microamp: @@ -91,8 +92,8 @@ patternProperties: description: PUPD/R1/R0 pull down type. See MTK_PUPD_SET_R1R0_ defines in dt-bindings/pinctrl/mt65xx.h. - enum: [200, 201, 202, 203] - description: RSEL pull down type. See MTK_PULL_SET_RSEL_ - defines in dt-bindings/pinctrl/mt65xx.h. + description: RSEL pull down type. See MTK_PULL_SET_RSEL_ defines + in dt-bindings/pinctrl/mt65xx.h. bias-pull-up: oneOf: @@ -102,8 +103,8 @@ patternProperties: description: PUPD/R1/R0 pull up type. See MTK_PUPD_SET_R1R0_ defines in dt-bindings/pinctrl/mt65xx.h. - enum: [200, 201, 202, 203] - description: RSEL pull up type. See MTK_PULL_SET_RSEL_ - defines in dt-bindings/pinctrl/mt65xx.h. + description: RSEL pull up type. See MTK_PULL_SET_RSEL_ defines + in dt-bindings/pinctrl/mt65xx.h. bias-disable: true @@ -125,7 +126,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8195-pinctrl.yaml index 66fe17e9e4d3..33cb71775db9 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8195-pinctrl.yaml @@ -1,16 +1,16 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8195.yaml# +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8195-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT8195 Pin Controller +title: MediaTek MT8195 Pin Controller maintainers: - Sean Wang <sean.wang@mediatek.com> -description: | - The Mediatek's Pin controller is used to control SoC pins. +description: + The MediaTek's MT8195 Pin controller is used to control SoC pins. properties: compatible: @@ -19,27 +19,27 @@ properties: gpio-controller: true '#gpio-cells': - description: | + description: Number of cells in GPIO specifier. Since the generic GPIO binding is used, - the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. + the amount of cells must be specified as 2. See the below mentioned gpio + binding representation for description of particular cells. const: 2 gpio-ranges: - description: gpio valid number range. + description: GPIO valid number range. maxItems: 1 gpio-line-names: true reg: - description: | - Physical address base for gpio base registers. There are 8 GPIO - physical address base in mt8195. + description: + Physical address base for GPIO base registers. There are 8 GPIO physical + address base in mt8195. maxItems: 8 reg-names: - description: | - Gpio base register names. + description: + GPIO base register names. maxItems: 8 interrupt-controller: true @@ -53,9 +53,9 @@ properties: mediatek,rsel-resistance-in-si-unit: type: boolean - description: | - Identifying i2c pins pull up/down type which is RSEL. It can support - RSEL define or si unit value(ohm) to set different resistance. + description: + Identifying i2c pins pull up/down type which is RSEL. It can support RSEL + define or si unit value(ohm) to set different resistance. # PIN CONFIGURATION NODES patternProperties: @@ -70,8 +70,8 @@ patternProperties: A pinctrl node should contain at least one subnodes representing the pinctrl groups available on the machine. Each subnode will list the pins it needs, and how they should be configured, with regard to muxer - configuration, pullups, drive strength, input enable/disable and - input schmitt. + configuration, pullups, drive strength, input enable/disable and input + schmitt. An example of using macro: pincontroller { /* GPIO0 set as multifunction GPIO0 */ @@ -87,15 +87,14 @@ patternProperties: } }; }; - $ref: "pinmux-node.yaml" + $ref: pinmux-node.yaml properties: pinmux: - description: | + description: Integer array, represents gpio pin number and mux setting. Supported pin number and mux varies for different SoCs, and are - defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h - directly. + defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] @@ -174,9 +173,9 @@ patternProperties: & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" - define in mt8195. It can also support resistance value(ohm) - "1000" & "1500" & "2000" & "3000" & "4000" & "5000" & "10000" & - "75000" in mt8195. + define in mt8195. It can also support resistance value(ohm) "1000" + & "1500" & "2000" & "3000" & "4000" & "5000" & "10000" & "75000" + in mt8195. An example of using RSEL define: pincontroller { i2c0-pins { @@ -217,7 +216,7 @@ patternProperties: - pinmux allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml index 4b96884a1afc..61b33b5416f5 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8365-pinctrl.yaml @@ -4,13 +4,13 @@ $id: http://devicetree.org/schemas/pinctrl/mediatek,mt8365-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek MT8365 Pin Controller +title: MediaTek MT8365 Pin Controller maintainers: - Zhiyong Tao <zhiyong.tao@mediatek.com> - Bernhard Rosenkränzer <bero@baylibre.com> -description: | +description: The MediaTek's MT8365 Pin controller is used to control SoC pins. properties: @@ -26,17 +26,17 @@ properties: maxItems: 1 minItems: 1 maxItems: 2 - description: | + description: Should be phandles of the syscfg node. gpio-controller: true "#gpio-cells": const: 2 - description: | - Number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. + description: + Number of cells in GPIO specifier. Since the generic GPIO binding is used, + the amount of cells must be specified as 2. See the below mentioned gpio + binding representation for description of particular cells. interrupt-controller: true @@ -54,7 +54,7 @@ patternProperties: "pins$": type: object additionalProperties: false - description: | + description: A pinctrl node should contain at least one subnode representing the pinctrl groups available on the machine. Each subnode will list the pins it needs, and how they should be configured, with regard to muxer @@ -65,19 +65,42 @@ patternProperties: properties: pinmux: description: - integer array, represents gpio pin number and mux setting. + Integer array, represents gpio pin number and mux setting. Supported pin number and mux varies for different SoCs, and are defined as macros in <soc>-pinfunc.h directly. bias-disable: true bias-pull-up: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: Pull up R1/R0 type define value. description: | - Besides generic pinconfig options, it can be used as the pull up - settings for 2 pull resistors, R0 and R1. User can configure those - special pins. + For pull up type is normal, it don't need add R1/R0 define. + For pull up type is R1/R0 type, it can add value to set different + resistance. Valid arguments are described as below: + 100: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 101: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 102: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 103: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + + bias-pull-down: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: Pull down R1/R0 type define value. + description: | + For pull down type is normal, it don't need add R1/R0 define. + For pull down type is R1/R0 type, it can add value to set + different resistance. Valid arguments are described as below: + 100: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 101: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 102: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 103: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. - bias-pull-down: true + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] input-enable: true @@ -91,8 +114,13 @@ patternProperties: input-schmitt-disable: true + drive-strength-microamp: + enum: [125, 250, 500, 1000] + mediatek,drive-strength-adv: + deprecated: true description: | + DEPRECATED: Please use drive-strength-microamp instead. Describe the specific driving setup property. For I2C pins, the existing generic driving setup can only support 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they @@ -118,9 +146,12 @@ patternProperties: enum: [0, 1, 2, 3, 4, 5, 6, 7] mediatek,pull-up-adv: + deprecated: true description: | + DEPRECATED: Please use bias-pull-up instead. Pull up setings for 2 pull resistors, R0 and R1. User can - configure those special pins. Valid arguments are described as below: + configure those special pins. Valid arguments are described as + below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. @@ -129,9 +160,12 @@ patternProperties: enum: [0, 1, 2, 3] mediatek,pull-down-adv: + deprecated: true description: | + DEPRECATED: Please use bias-pull-down instead. Pull down settings for 2 pull resistors, R0 and R1. User can - configure those special pins. Valid arguments are described as below: + configure those special pins. Valid arguments are described as + below: 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. @@ -140,14 +174,14 @@ patternProperties: enum: [0, 1, 2, 3] mediatek,tdsel: - description: | + description: An integer describing the steps for output level shifter duty cycle when asserted (high pulse width adjustment). Valid arguments are from 0 to 15. $ref: /schemas/types.yaml#/definitions/uint32 mediatek,rdsel: - description: | + description: An integer describing the steps for input level shifter duty cycle when asserted (high pulse width adjustment). Valid arguments are from 0 to 63. @@ -189,7 +223,6 @@ examples: pins { pinmux = <MT8365_PIN_59_SDA1__FUNC_SDA1_0>, <MT8365_PIN_60_SCL1__FUNC_SCL1_0>; mediatek,pull-up-adv = <3>; - mediatek,drive-strength-adv = <00>; bias-pull-up; }; }; diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt deleted file mode 100644 index 8146193bd8ac..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt +++ /dev/null @@ -1,94 +0,0 @@ -== Amlogic Meson pinmux controller == - -Required properties for the root node: - - compatible: one of "amlogic,meson8-cbus-pinctrl" - "amlogic,meson8b-cbus-pinctrl" - "amlogic,meson8m2-cbus-pinctrl" - "amlogic,meson8-aobus-pinctrl" - "amlogic,meson8b-aobus-pinctrl" - "amlogic,meson8m2-aobus-pinctrl" - "amlogic,meson-gxbb-periphs-pinctrl" - "amlogic,meson-gxbb-aobus-pinctrl" - "amlogic,meson-gxl-periphs-pinctrl" - "amlogic,meson-gxl-aobus-pinctrl" - "amlogic,meson-axg-periphs-pinctrl" - "amlogic,meson-axg-aobus-pinctrl" - "amlogic,meson-g12a-periphs-pinctrl" - "amlogic,meson-g12a-aobus-pinctrl" - "amlogic,meson-a1-periphs-pinctrl" - "amlogic,meson-s4-periphs-pinctrl" - - reg: address and size of registers controlling irq functionality - -=== GPIO sub-nodes === - -The GPIO bank for the controller is represented as a sub-node and it acts as a -GPIO controller. - -Required properties for sub-nodes are: - - reg: should contain a list of address and size, one tuple for each entry - in reg-names. - - reg-names: an array of strings describing the "reg" entries. - Must contain "mux" and "gpio". - May contain "pull", "pull-enable" and "ds" when appropriate. - - gpio-controller: identifies the node as a gpio controller - - #gpio-cells: must be 2 - -=== Other sub-nodes === - -Child nodes without the "gpio-controller" represent some desired -configuration for a pin or a group. Those nodes can be pinmux nodes or -configuration nodes. - -Required properties for pinmux nodes are: - - groups: a list of pinmux groups. The list of all available groups - depends on the SoC and can be found in driver sources. - - function: the name of a function to activate for the specified set - of groups. The list of all available functions depends on the SoC - and can be found in driver sources. - -Required properties for configuration nodes: - - pins: a list of pin names - -Configuration nodes support the following generic properties, as -described in file pinctrl-bindings.txt: - - "bias-disable" - - "bias-pull-up" - - "bias-pull-down" - - "output-enable" - - "output-disable" - - "output-low" - - "output-high" - -Optional properties : - - drive-strength-microamp: Drive strength for the specified pins in uA. - This property is only valid for G12A and newer. - -=== Example === - - pinctrl: pinctrl@c1109880 { - compatible = "amlogic,meson8-cbus-pinctrl"; - reg = <0xc1109880 0x10>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - gpio: banks@c11080b0 { - reg = <0xc11080b0 0x28>, - <0xc11080e8 0x18>, - <0xc1108120 0x18>, - <0xc1108030 0x30>; - reg-names = "mux", "pull", "pull-enable", "gpio"; - gpio-controller; - #gpio-cells = <2>; - }; - - nand { - mux { - groups = "nand_io", "nand_io_ce0", "nand_io_ce1", - "nand_io_rb0", "nand_ale", "nand_cle", - "nand_wen_clk", "nand_ren_clk", "nand_dqs", - "nand_ce2", "nand_ce3"; - function = "nand"; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml index 98d547c34ef3..dbb3e1bd58c1 100644 --- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml @@ -54,8 +54,8 @@ patternProperties: '-pins$': type: object allOf: - - $ref: "pinmux-node.yaml" - - $ref: "pincfg-node.yaml" + - $ref: pinmux-node.yaml + - $ref: pincfg-node.yaml properties: function: true @@ -78,7 +78,7 @@ required: - gpio-ranges allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml new file mode 100644 index 000000000000..d49aafd8c5f4 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml @@ -0,0 +1,123 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2022 NXP +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nxp,s32g2-siul2-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP S32G2 pin controller + +maintainers: + - Ghennadi Procopciuc <Ghennadi.Procopciuc@oss.nxp.com> + - Chester Lin <clin@suse.com> + +description: | + S32G2 pinmux is implemented in SIUL2 (System Integration Unit Lite2), + whose memory map is split into two regions: + SIUL2_0 @ 0x4009c000 + SIUL2_1 @ 0x44010000 + + Every SIUL2 region has multiple register types, and here only MSCR and + IMCR registers need to be revealed for kernel to configure pinmux. + + Please note that some register indexes are reserved in S32G2, such as + MSCR102-MSCR111, MSCR123-MSCR143, IMCR84-IMCR118 and IMCR398-IMCR429. + +properties: + compatible: + enum: + - nxp,s32g2-siul2-pinctrl + + reg: + description: | + A list of MSCR/IMCR register regions to be reserved. + - MSCR (Multiplexed Signal Configuration Register) + An MSCR register can configure the associated pin as either a GPIO pin + or a function output pin depends on the selected signal source. + - IMCR (Input Multiplexed Signal Configuration Register) + An IMCR register can configure the associated pin as function input + pin depends on the selected signal source. + items: + - description: MSCR registers group 0 in SIUL2_0 + - description: MSCR registers group 1 in SIUL2_1 + - description: MSCR registers group 2 in SIUL2_1 + - description: IMCR registers group 0 in SIUL2_0 + - description: IMCR registers group 1 in SIUL2_1 + - description: IMCR registers group 2 in SIUL2_1 + +patternProperties: + '-pins$': + type: object + additionalProperties: false + + patternProperties: + '-grp[0-9]$': + type: object + allOf: + - $ref: pinmux-node.yaml# + - $ref: pincfg-node.yaml# + description: | + Pinctrl node's client devices specify pin muxes using subnodes, + which in turn use the standard properties below. + + properties: + bias-disable: true + bias-high-impedance: true + bias-pull-up: true + bias-pull-down: true + drive-open-drain: true + input-enable: true + output-enable: true + + pinmux: + description: | + An integer array for representing pinmux configurations of + a device. Each integer consists of a PIN_ID and a 4-bit + selected signal source(SSS) as IOMUX setting, which is + calculated as: pinmux = (PIN_ID << 4 | SSS) + + slew-rate: + description: Supported slew rate based on Fmax values (MHz) + enum: [83, 133, 150, 166, 208] + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pinctrl@4009c240 { + compatible = "nxp,s32g2-siul2-pinctrl"; + + /* MSCR0-MSCR101 registers on siul2_0 */ + reg = <0x4009c240 0x198>, + /* MSCR112-MSCR122 registers on siul2_1 */ + <0x44010400 0x2c>, + /* MSCR144-MSCR190 registers on siul2_1 */ + <0x44010480 0xbc>, + /* IMCR0-IMCR83 registers on siul2_0 */ + <0x4009ca40 0x150>, + /* IMCR119-IMCR397 registers on siul2_1 */ + <0x44010c1c 0x45c>, + /* IMCR430-IMCR495 registers on siul2_1 */ + <0x440110f8 0x108>; + + llce-can0-pins { + llce-can0-grp0 { + pinmux = <0x2b0>; + input-enable; + slew-rate = <208>; + }; + + llce-can0-grp1 { + pinmux = <0x2c2>; + output-enable; + slew-rate = <208>; + }; + }; + }; +... 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,ipq5332-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5332-tlmm.yaml index 300747252a7b..3d3086ae1ba6 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5332-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5332-tlmm.yaml @@ -56,6 +56,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -92,19 +93,9 @@ $defs: rx1, sdc_data, sdc_clk, sdc_cmd, tsens_max, wci_txd, wci_rxd, wsi_clk, wsi_clk3, wsi_data, wsi_data3, wsis_reset, xfem ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml index 28f1b6a07b70..7c3e5e043f07 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml @@ -43,6 +43,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -89,18 +90,9 @@ $defs: sd_write, sec_mi2s, smb_int, ssbi_wtr0, ssbi_wtr1, uim1, uim2, uim3, uim_batt, wcss_bt, wcss_fm, wcss_wlan, webcam1_rst ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml index 3137db927fc0..e053fbd588b5 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.yaml @@ -53,6 +53,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -92,19 +93,9 @@ $defs: qdss_tracedata_b, qpic, rx0, rx1, rx2, sd_card, sd_write, tsens_max, wci2a, wci2b, wci2c, wci2d ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml new file mode 100644 index 000000000000..673713debac2 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq9574-tlmm.yaml @@ -0,0 +1,130 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,ipq9574-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. IPQ9574 TLMM block + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + +description: + Top Level Mode Multiplexer pin controller in Qualcomm IPQ9574 SoC. + +properties: + compatible: + const: qcom,ipq9574-tlmm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + "#interrupt-cells": true + gpio-controller: true + "#gpio-cells": true + gpio-ranges: true + wakeup-parent: true + + gpio-reserved-ranges: + minItems: 1 + maxItems: 33 + + gpio-line-names: + maxItems: 65 + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-ipq9574-tlmm-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-ipq9574-tlmm-state" + additionalProperties: false + +$defs: + qcom-ipq9574-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + pattern: "^gpio([0-9]|[1-5][0-9]|6[0-4])$" + minItems: 1 + maxItems: 8 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ atest_char, atest_char0, atest_char1, atest_char2, atest_char3, + audio_pdm0, audio_pdm1, audio_pri, audio_sec, blsp0_spi, blsp0_uart, + blsp1_i2c, blsp1_spi, blsp1_uart, blsp2_i2c, blsp2_spi, + blsp2_uart, blsp3_i2c, blsp3_spi, blsp3_uart, blsp4_i2c, + blsp4_spi, blsp4_uart, blsp5_i2c, blsp5_uart, cri_trng0, + cri_trng1, cri_trng2, cri_trng3, cxc0, cxc1, dbg_out, dwc_ddrphy, + gcc_plltest, gcc_tlmm, gpio, mac, mdc, mdio, pcie0_clk, pcie0_wake, + pcie1_clk, pcie1_wake, pcie2_clk, pcie2_wake, pcie3_clk, pcie3_wake, + prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3, pta, pwm, + qdss_cti_trig_in_a0, qdss_cti_trig_in_a1, qdss_cti_trig_in_b0, + qdss_cti_trig_in_b1, qdss_cti_trig_out_a0, qdss_cti_trig_out_a1, + qdss_cti_trig_out_b0, qdss_cti_trig_out_b1, qdss_traceclk_a, + qdss_traceclk_b, qdss_tracectl_a, qdss_tracectl_b, qdss_tracedata_a, + qdss_tracedata_b, qspi_clk, qspi_cs, qspi_data, + rx0, rx1, sdc_clk, sdc_cmd, sdc_data, sdc_rclk, tsens_max, + wci20, wci21, wsa_swrm ] + + bias-pull-down: true + bias-pull-up: true + bias-disable: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + + additionalProperties: false + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + tlmm: pinctrl@1000000 { + compatible = "qcom,ipq9574-tlmm"; + reg = <0x01000000 0x300000>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-ranges = <&tlmm 0 0 65>; + + uart2-state { + pins = "gpio34", "gpio35"; + function = "blsp2_uart"; + drive-strength = <8>; + bias-pull-down; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml index 96b598bf9a76..2aedb7e7bc8b 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-tlmm.yaml @@ -54,6 +54,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -105,19 +106,9 @@ $defs: uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset, uim_batt, wlan_en1, ] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml index c7c94d742ed2..5885aee95c98 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.yaml @@ -51,6 +51,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -70,19 +71,9 @@ $defs: enum: [ gpio, gsbi2_i2c, gsbi3, gsbi4, gsbi5_i2c, gsbi5_uart, sdc2, ebi2_lcdc, ps_hold, prim_audio, sec_audio, cdc_mclk, ] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - output-high: true - output-low: true - input-enable: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml index 6cb667fa8665..9efb76509580 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml @@ -48,6 +48,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -71,19 +72,9 @@ $defs: blsp_uart3, blsp_uart4, blsp_uart5, cam_mclk0, cam_mclk1, gp0_clk, gp1_clk, sdc3, wlan ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml index 348d84c3cd21..a05971611780 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.yaml @@ -53,6 +53,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -81,20 +82,9 @@ $defs: sdc5, tsif1, tsif2, usb_fs1, usb_fs1_oe_n, usb_fs2, usb_fs2_oe_n, vfe, vsens_alarm, ebi2, ebi2cs ] - - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml index 85082adc1811..5095e86fe9a2 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8909-tlmm.yaml @@ -55,6 +55,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -104,19 +105,9 @@ $defs: uim3_clk, uim3_data, uim3_present, uim3_reset, uim_batt, wcss_bt, wcss_fm, wcss_wlan ] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml index 633c9e5ed49e..063d004967bb 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.yaml @@ -53,6 +53,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -103,19 +104,9 @@ $defs: uim1, uim2, uim3, uim_batt, wcss_bt, wcss_fm, wcss_wlan, webcam1_rst ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml index ce219827ccc8..798aac9e6e31 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml @@ -45,6 +45,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -106,18 +107,9 @@ $defs: uim_batt, us_emitter, us_euro, wcss_bt, wcss_fm, wcss_wlan, wcss_wlan0, wcss_wlan1, wcss_wlan2, wsa_en, wsa_io, wsa_irq ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml index cf386f644ccb..9172b50f7a98 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.yaml @@ -53,6 +53,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -97,19 +98,9 @@ $defs: vfe_camif_timer7_a, vfe_camif_timer7_b, vfe_camif_timer7_c, wlan ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml index afe4a80f0b79..8a3be65c51ed 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.yaml @@ -53,6 +53,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -93,14 +94,6 @@ $defs: tsif1, tsif2, hsic, grfc, audio_ref_clk, qua_mi2s, pri_mi2s, spkr_mi2s, ter_mi2s, sec_mi2s, bt, fm, wlan, slimbus, hsic_ctl ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins @@ -124,8 +117,6 @@ $defs: output-high: false output-low: false - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml index 5dfcc3eadbb0..ca95de0b87a6 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8976-pinctrl.yaml @@ -53,6 +53,7 @@ $defs: Desired pin configuration for a device or its specific state (like sleep or active). $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -93,19 +94,9 @@ $defs: wsa_irq, blsp_i2c8, pa_indicator, modem_tsync, ssbi_wtr1, gsm1_tx, gsm0_tx, sdcard_det, sec_mi2s, ss_switch ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml index 0c4936fc35ef..41525ecfa8e3 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.yaml @@ -55,6 +55,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -103,19 +104,9 @@ $defs: pri_mi2s, sdc4, sec_mi2s, slimbus, spkr_i2s, ter_mi2s, tsif1, tsif2, uim_batt_alarm, uim1, uim2, uim3, uim4 ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml index 047b4584e3c0..59d406b60957 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.yaml @@ -53,6 +53,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -122,19 +123,9 @@ $defs: modem_tsync, nav_dr, nav_pps, pci_e1, gsm_tx, qspi_cs, ssbi2, ssbi1, mss_lte, qspi_clk, qspi0, qspi1, qspi2, qspi3 ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml index c07ee9868046..bd6d7caf499a 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8998-pinctrl.yaml @@ -53,6 +53,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -107,19 +108,9 @@ $defs: vsense_clkout, vsense_data0, vsense_data1, vsense_mode, wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1 ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index db505fdeac86..eaadd5a9a445 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -52,12 +52,14 @@ properties: - qcom,pm8994-gpio - qcom,pm8998-gpio - qcom,pma8084-gpio + - qcom,pmi632-gpio - qcom,pmi8950-gpio - qcom,pmi8994-gpio - qcom,pmi8998-gpio - qcom,pmk8350-gpio - qcom,pmk8550-gpio - qcom,pmm8155au-gpio + - qcom,pmm8654au-gpio - qcom,pmp8074-gpio - qcom,pmr735a-gpio - qcom,pmr735b-gpio @@ -173,6 +175,7 @@ allOf: - qcom,pm8350b-gpio - qcom,pm8550ve-gpio - qcom,pm8950-gpio + - qcom,pmi632-gpio then: properties: gpio-line-names: @@ -395,8 +398,8 @@ $defs: qcom-pmic-gpio-state: type: object allOf: - - $ref: "pinmux-node.yaml" - - $ref: "pincfg-node.yaml" + - $ref: pinmux-node.yaml + - $ref: pincfg-node.yaml properties: pins: description: @@ -434,11 +437,13 @@ $defs: - gpio1-gpio22 for pm8994 - gpio1-gpio26 for pm8998 - gpio1-gpio22 for pma8084 + - gpio1-gpio8 for pmi632 - gpio1-gpio2 for pmi8950 - gpio1-gpio10 for pmi8994 - gpio1-gpio4 for pmk8350 - gpio1-gpio6 for pmk8550 - gpio1-gpio10 for pmm8155au + - gpio1-gpio12 for pmm8654au - gpio1-gpio12 for pmp8074 (holes on gpio1 and gpio12) - gpio1-gpio4 for pmr735a - gpio1-gpio4 for pmr735b diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml index 9412b9362328..c91d3e3a094b 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml @@ -82,8 +82,8 @@ $defs: qcom-pmic-mpp-state: type: object allOf: - - $ref: "pinmux-node.yaml" - - $ref: "pincfg-node.yaml" + - $ref: pinmux-node.yaml + - $ref: pincfg-node.yaml properties: pins: description: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml index 6271fd15e0b6..032763649336 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-tlmm.yaml @@ -85,6 +85,7 @@ $defs: bias-pull-up: true bias-disable: true drive-strength: true + input-enable: true output-high: true output-low: true diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml index 20bc967a17b5..b1b9cd319e50 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcs404-pinctrl.yaml @@ -59,6 +59,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -119,19 +120,9 @@ $defs: spdifrx_opt, spi_lcd, spkr_dac0, wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_en ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml index 7e5fb9a6e7d3..237cac4f6ce1 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,qdu1000-tlmm.yaml @@ -55,6 +55,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -93,19 +94,9 @@ $defs: usb2phy_ac, usb_con_det, usb_dfp_en, usb_phy, vfr_0, vfr_1, vsense_trigger ] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml index 70d9106ad83d..e608a4f1bcae 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml @@ -58,6 +58,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -103,19 +104,9 @@ $defs: tgu_ch2, tgu_ch3, tgu_ch4, tgu_ch5, tsense_pwm1, tsense_pwm2, tsense_pwm3, tsense_pwm4, usb2phy_ac, vsense_trigger ] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml index f33792a1af6c..573e459b1c44 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.yaml @@ -59,6 +59,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -100,19 +101,9 @@ $defs: _V_GPIO, _V_PPS_IN, _V_PPS_OUT, vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1 ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml index e51feb4c0700..fa51fa9536f7 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml @@ -50,7 +50,7 @@ $defs: description: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. - $ref: "/schemas/pinctrl/pincfg-node.yaml" + $ref: /schemas/pinctrl/pincfg-node.yaml properties: pins: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml index 36502173cb79..368d44ff5468 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml @@ -62,6 +62,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -110,20 +111,9 @@ $defs: uim1_clk, uim1_data, uim1_present, uim1_reset, usb2phy_ac, usb_phy, vfr_0, vfr_1, vsense_trigger ] - bias-pull-down: true - bias-pull-up: true - bias-bus-hold: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml index 0ace55c9868e..b086a5184235 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-tlmm.yaml @@ -62,6 +62,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -102,19 +103,9 @@ $defs: usb0_phy, usb1_phy, usb2phy_ac, vfr_1, vsense_trigger, wlan1_adc, wlan2_adc, wmss_reset ] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml index 200b3b6ccd87..a9167dac9ab5 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-lpass-lpi-pinctrl.yaml @@ -20,7 +20,7 @@ properties: reg: items: - description: LPASS LPI TLMM Control and Status registers - - description: LPASS LPI pins SLEW registers + - description: LPASS LPI MCC registers clocks: items: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml index 97b27d6835e9..4ae39fc7894a 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-tlmm.yaml @@ -104,6 +104,7 @@ $defs: usb1_phy, usb1_sbrx, usb1_sbtx, usb1_usb4, usb2phy_ac, vsense_trigger ] + bias-bus-hold: true bias-disable: true bias-pull-down: true bias-pull-up: true diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml index ea6bd0b44f56..508e0633b253 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm630-pinctrl.yaml @@ -65,6 +65,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -122,19 +123,9 @@ $defs: vsense_data0, vsense_data1, vsense_mode, wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1 ] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml index f586b3aa138e..84a15f77e710 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-tlmm.yaml @@ -58,6 +58,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -94,20 +95,9 @@ $defs: uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset, uim_batt, usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk, wsa_data, ] - - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml index 23d7c030fec0..d301881ddfa8 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm845-pinctrl.yaml @@ -61,6 +61,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -102,19 +103,9 @@ $defs: uim_batt, usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml index a40175258495..67af99dd8f14 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml @@ -48,6 +48,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -91,18 +92,9 @@ $defs: uim1_present, uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset, usb2phy_ac, vsense_trigger ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml index 89c5562583d1..2ef793ae4038 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-tlmm.yaml @@ -47,6 +47,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -111,18 +112,9 @@ $defs: qspi_cs, ssbi2, ssbi1, mss_lte, qspi_clk, qspi0, qspi1, qspi2, qspi3, gpio ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml index 29325483cd2b..871df54f69a2 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-tlmm.yaml @@ -53,6 +53,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -85,18 +86,9 @@ $defs: uim2_present, uim2_reset, usb_phy, vfr_1, vsense_trigger, wlan1_adc0, elan1_adc1 ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml index c9bc4893e8e8..8d77707b02b9 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-tlmm.yaml @@ -61,6 +61,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -101,19 +102,9 @@ $defs: wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk, wsa_data ] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml index d95935fcc8b5..27af379cf791 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-tlmm.yaml @@ -63,6 +63,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -108,20 +109,9 @@ $defs: uim2_present, uim2_reset, usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, ] - - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml index 66cef48ed59b..6e02ba24825f 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6375-tlmm.yaml @@ -55,6 +55,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -109,20 +110,9 @@ $defs: usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1 ] - - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml new file mode 100644 index 000000000000..a57d44efe5bd --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm7150-tlmm.yaml @@ -0,0 +1,162 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm7150-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM7150 TLMM pin controller + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + - Danila Tikhonov <danila@jiaxyga.com> + +description: + Top Level Mode Multiplexer pin controller in Qualcomm SM7150 SoC. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sm7150-tlmm + + reg: + maxItems: 3 + + reg-names: + items: + - const: west + - const: north + - const: south + + interrupts: + maxItems: 1 + + interrupt-controller: true + "#interrupt-cells": true + gpio-controller: true + "#gpio-cells": true + gpio-ranges: true + wakeup-parent: true + + gpio-reserved-ranges: + minItems: 1 + maxItems: 60 + + gpio-line-names: + maxItems: 119 + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-sm7150-tlmm-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-sm7150-tlmm-state" + additionalProperties: false + +$defs: + qcom-sm7150-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-9]|11[0-8])$" + - enum: [ sdc1_rclk, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, + sdc2_cmd, sdc2_data, ufs_reset ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ gpio, adsp_ext, agera_pll, aoss_cti, atest_char, atest_tsens, + atest_tsens2, atest_usb1, atest_usb2, cam_mclk, cci_async, + cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3, + cci_timer4, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, ddr_pxi2, + ddr_pxi3, edp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, gp_pdm0, + gp_pdm1, gp_pdm2, gps_tx, jitter_bist, ldo_en, ldo_update, + m_voc, mdp_vsync, mdp_vsync0, mdp_vsync1, mdp_vsync2, + mdp_vsync3, mss_lte, nav_pps_in, nav_pps_out, pa_indicator, + pci_e, phase_flag, pll_bist, pll_bypassnl, pll_reset, pri_mi2s, + pri_mi2s_ws, prng_rosc, qdss, qdss_cti, qlink_enable, + qlink_request, qua_mi2s, qup00, qup01, qup02, qup03, qup04, + qup10, qup11, qup12, qup13, qup14, qup15, sd_write, sdc40, + sdc41, sdc42, sdc43, sdc4_clk, sdc4_cmd, sec_mi2s, ter_mi2s, + tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsif1_clk, tsif1_data, + tsif1_en, tsif1_error, tsif1_sync, tsif2_clk, tsif2_data, + tsif2_en, tsif2_error, tsif2_sync, uim1_clk, uim1_data, + uim1_present, uim1_reset, uim2_clk, uim2_data, uim2_present, + uim2_reset, uim_batt, usb_phy, vfr_1, vsense_trigger, + wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk, + wsa_data ] + + bias-pull-down: true + bias-pull-up: true + bias-disable: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + + additionalProperties: false + +required: + - compatible + - reg + - reg-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + tlmm: pinctrl@3500000 { + compatible = "qcom,sm7150-tlmm"; + reg = <0x03500000 0x300000>, + <0x03900000 0x300000>, + <0x03d00000 0x300000>; + reg-names = "west", "north", "south"; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + gpio-ranges = <&tlmm 0 0 120>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + wakeup-parent = <&pdc>; + + gpio-wo-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-state { + rx-pins { + pins = "gpio44"; + function = "qup12"; + bias-pull-up; + }; + + tx-pins { + pins = "gpio45"; + function = "qup12"; + bias-disable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml index 4376a9bd4d70..c6439626464e 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl.yaml @@ -60,6 +60,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -81,7 +82,7 @@ $defs: enum: [ adsp_ext, agera_pll, aoss_cti, ddr_pxi2, atest_char, atest_char0, atest_char1, atest_char2, atest_char3, audio_ref, atest_usb1, atest_usb2, atest_usb10, atest_usb11, atest_usb12, - atest_usb13, atest_usb20, atest_usb21, atest_usb22, atest_usb2, + atest_usb13, atest_usb20, atest_usb21, atest_usb22, atest_usb23, btfm_slimbus, cam_mclk, cci_async, cci_i2c, cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4, cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, @@ -101,19 +102,9 @@ $defs: usb_phy, vfr_1, vsense_trigger, wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wmss_reset ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml index de9d8854c690..4b4be7efc150 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml @@ -55,7 +55,7 @@ $defs: description: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. - $ref: "/schemas/pinctrl/pincfg-node.yaml" + $ref: /schemas/pinctrl/pincfg-node.yaml properties: pins: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml index cf561dff8893..021c54708524 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml @@ -58,6 +58,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -94,19 +95,9 @@ $defs: tsif0_en, tsif0_error, tsif0_sync, tsif1_clk, tsif1_data, tsif1_en, tsif1_error, tsif1_sync, usb2phy_ac, usb_phy, vsense_trigger ] - bias-pull-down: true - bias-pull-up: true - bias-disable: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - allOf: - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml index 797242f68b1c..6e8f41ff0a76 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-tlmm.yaml @@ -62,6 +62,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -104,21 +105,9 @@ $defs: uim0_present, uim0_reset, uim1_clk, uim1_data, uim1_present, uim1_reset, usb2phy_ac, usb_phy, vfr_0, vfr_1, vsense_trigger ] - - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-disable: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml index 8bf51df0b231..1eefa9aa6a86 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml @@ -20,7 +20,7 @@ properties: reg: items: - description: LPASS LPI TLMM Control and Status registers - - description: LPASS LPI pins SLEW registers + - description: LPASS LPI MCC registers clocks: items: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml index 56c8046f1be0..5163fe3f5365 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-tlmm.yaml @@ -62,6 +62,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -103,19 +104,9 @@ $defs: uim0_reset, uim1_clk, uim1_data, uim1_present, uim1_reset, usb2phy_ac, usb_phy, vfr_0, vfr_1, vsense_trigger ] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> 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 8f60a9113e7a..ef9743246849 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml @@ -21,7 +21,7 @@ properties: reg: items: - description: LPASS LPI TLMM Control and Status registers - - description: LPASS LPI pins SLEW registers + - description: LPASS LPI MCC registers clocks: items: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml index a457425ba112..f789c7753a92 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-tlmm.yaml @@ -54,6 +54,7 @@ $defs: Pinctrl node's client devices use subnodes for desired pin configuration. Client device subnodes use below standard properties. $ref: qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false properties: pins: @@ -109,19 +110,9 @@ $defs: uim1_clk, uim1_data, uim1_present, uim1_reset, usb1_hs, usb_phy, vfr_0, vfr_1, vsense_trigger_mirnat ] - bias-disable: true - bias-pull-down: true - bias-pull-up: true - drive-strength: true - input-enable: true - output-high: true - output-low: true - required: - pins - additionalProperties: false - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml index 90b7d75840c1..aae3dcf6cac8 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml @@ -52,7 +52,7 @@ properties: information. allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - interrupts diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml index 7fd0df880a76..43b33dbf115b 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml @@ -10,7 +10,7 @@ maintainers: - Arınç ÜNAL <arinc.unal@arinc9.com> - Sergio Paracuellos <sergio.paracuellos@gmail.com> -description: +description: | Ralink RT2880 pin controller for RT2880 SoC. The pin controller can only set the muxing of pin groups. Muxing individual pins is not supported. There is no pinconf support. @@ -22,11 +22,14 @@ properties: patternProperties: '-pins$': type: object + additionalProperties: false + patternProperties: '^(.*-)?pinmux$': type: object description: node for pinctrl. $ref: pinmux-node.yaml# + additionalProperties: false properties: function: @@ -116,12 +119,8 @@ patternProperties: groups: enum: [pci] - additionalProperties: false - - additionalProperties: false - allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml index 4d66ca752a30..95a904273009 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml @@ -10,9 +10,8 @@ maintainers: - Arınç ÜNAL <arinc.unal@arinc9.com> - Sergio Paracuellos <sergio.paracuellos@gmail.com> -description: - Ralink RT305X pin controller for RT3050, RT3052, RT3350, RT3352 and RT5350 - SoCs. +description: | + Ralink RT305X pin controller for RT3050, RT3052, and RT3350 SoCs. The pin controller can only set the muxing of pin groups. Muxing individual pins is not supported. There is no pinconf support. @@ -23,31 +22,22 @@ properties: patternProperties: '-pins$': type: object + additionalProperties: false + patternProperties: '^(.*-)?pinmux$': type: object description: node for pinctrl. $ref: pinmux-node.yaml# + additionalProperties: false properties: function: description: A string containing the name of the function to mux to the group. - anyOf: - - description: For RT3050, RT3052 and RT3350 SoCs - enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, mdio, - pcm gpio, pcm i2s, pcm uartf, rgmii, sdram, spi, uartf, - uartlite] - - - description: For RT3352 SoC - enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, - lna, mdio, pa, pcm gpio, pcm i2s, pcm uartf, rgmii, spi, - spi_cs1, uartf, uartlite, wdg_cs1] - - - description: For RT5350 SoC - enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, - pcm gpio, pcm i2s, pcm uartf, spi, spi_cs1, uartf, - uartlite, wdg_cs1] + enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, mdio, + pcm gpio, pcm i2s, pcm uartf, rgmii, sdram, spi, uartf, + uartlite] groups: description: @@ -66,17 +56,7 @@ patternProperties: then: properties: groups: - anyOf: - - description: For RT3050, RT3052 and RT3350 SoCs - enum: [i2c, jtag, mdio, rgmii, sdram, spi, uartf, - uartlite] - - - description: For RT3352 SoC - enum: [i2c, jtag, led, lna, mdio, pa, rgmii, spi, spi_cs1, - uartf, uartlite] - - - description: For RT5350 SoC - enum: [i2c, jtag, led, spi, spi_cs1, uartf, uartlite] + enum: [i2c, jtag, mdio, rgmii, sdram, spi, uartf, uartlite] - if: properties: @@ -126,24 +106,6 @@ patternProperties: - if: properties: function: - const: led - then: - properties: - groups: - enum: [led] - - - if: - properties: - function: - const: lna - then: - properties: - groups: - enum: [lna] - - - if: - properties: - function: const: mdio then: properties: @@ -153,15 +115,6 @@ patternProperties: - if: properties: function: - const: pa - then: - properties: - groups: - enum: [pa] - - - if: - properties: - function: const: pcm gpio then: properties: @@ -216,15 +169,6 @@ patternProperties: - if: properties: function: - const: spi_cs1 - then: - properties: - groups: - enum: [spi_cs1] - - - if: - properties: - function: const: uartf then: properties: @@ -240,21 +184,8 @@ patternProperties: groups: enum: [uartlite] - - if: - properties: - function: - const: wdg_cs1 - then: - properties: - groups: - enum: [spi_cs1] - - additionalProperties: false - - additionalProperties: false - allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt3352-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt3352-pinctrl.yaml new file mode 100644 index 000000000000..c9bc6cfd834c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt3352-pinctrl.yaml @@ -0,0 +1,243 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,rt3352-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink RT3352 Pin Controller + +maintainers: + - Arınç ÜNAL <arinc.unal@arinc9.com> + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: | + Ralink RT3352 pin controller for RT3352 SoC. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,rt3352-pinctrl + +patternProperties: + '-pins$': + type: object + additionalProperties: false + + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + additionalProperties: false + + properties: + function: + description: + A string containing the name of the function to mux to the group. + enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, lna, + mdio, pa, pcm gpio, pcm i2s, pcm uartf, rgmii, spi, spi_cs1, + uartf, uartlite, wdg_cs1] + + groups: + description: + An array of strings. Each string contains the name of a group. + maxItems: 1 + + required: + - groups + - function + + allOf: + - if: + properties: + function: + const: gpio + then: + properties: + groups: + enum: [i2c, jtag, led, lna, mdio, pa, rgmii, spi, spi_cs1, + uartf, uartlite] + + - if: + properties: + function: + const: gpio i2s + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: gpio uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: i2c + then: + properties: + groups: + enum: [i2c] + + - if: + properties: + function: + const: i2s uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: jtag + then: + properties: + groups: + enum: [jtag] + + - if: + properties: + function: + const: led + then: + properties: + groups: + enum: [led] + + - if: + properties: + function: + const: lna + then: + properties: + groups: + enum: [lna] + + - if: + properties: + function: + const: mdio + then: + properties: + groups: + enum: [mdio] + + - if: + properties: + function: + const: pa + then: + properties: + groups: + enum: [pa] + + - if: + properties: + function: + const: pcm gpio + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: pcm i2s + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: pcm uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: rgmii + then: + properties: + groups: + enum: [rgmii] + + - if: + properties: + function: + const: spi + then: + properties: + groups: + enum: [spi] + + - if: + properties: + function: + const: spi_cs1 + then: + properties: + groups: + enum: [spi_cs1] + + - if: + properties: + function: + const: uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: uartlite + then: + properties: + groups: + enum: [uartlite] + + - if: + properties: + function: + const: wdg_cs1 + then: + properties: + groups: + enum: [spi_cs1] + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + +additionalProperties: false + +examples: + - | + pinctrl { + compatible = "ralink,rt3352-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml index 008d93181aea..8d14e525b25e 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml @@ -10,7 +10,7 @@ maintainers: - Arınç ÜNAL <arinc.unal@arinc9.com> - Sergio Paracuellos <sergio.paracuellos@gmail.com> -description: +description: | Ralink RT3883 pin controller for RT3883 SoC. The pin controller can only set the muxing of pin groups. Muxing individual pins is not supported. There is no pinconf support. @@ -22,11 +22,14 @@ properties: patternProperties: '-pins$': type: object + additionalProperties: false + patternProperties: '^(.*-)?pinmux$': type: object description: node for pinctrl. $ref: pinmux-node.yaml# + additionalProperties: false properties: function: @@ -236,12 +239,8 @@ patternProperties: groups: enum: [uartlite] - additionalProperties: false - - additionalProperties: false - allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt5350-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt5350-pinctrl.yaml new file mode 100644 index 000000000000..f248202ce866 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt5350-pinctrl.yaml @@ -0,0 +1,206 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,rt5350-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink RT5350 Pin Controller + +maintainers: + - Arınç ÜNAL <arinc.unal@arinc9.com> + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: | + Ralink RT5350 pin controller for RT5350 SoC. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,rt5350-pinctrl + +patternProperties: + '-pins$': + type: object + additionalProperties: false + + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + additionalProperties: false + + properties: + function: + description: + A string containing the name of the function to mux to the group. + enum: [gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, + pcm gpio, pcm i2s, pcm uartf, spi, spi_cs1, uartf, uartlite, + wdg_cs1] + + groups: + description: + An array of strings. Each string contains the name of a group. + maxItems: 1 + + required: + - groups + - function + + allOf: + - if: + properties: + function: + const: gpio + then: + properties: + groups: + enum: [i2c, jtag, led, spi, spi_cs1, uartf, uartlite] + + - if: + properties: + function: + const: gpio i2s + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: gpio uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: i2c + then: + properties: + groups: + enum: [i2c] + + - if: + properties: + function: + const: i2s uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: jtag + then: + properties: + groups: + enum: [jtag] + + - if: + properties: + function: + const: led + then: + properties: + groups: + enum: [led] + + - if: + properties: + function: + const: pcm gpio + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: pcm i2s + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: pcm uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: spi + then: + properties: + groups: + enum: [spi] + + - if: + properties: + function: + const: spi_cs1 + then: + properties: + groups: + enum: [spi_cs1] + + - if: + properties: + function: + const: uartf + then: + properties: + groups: + enum: [uartf] + + - if: + properties: + function: + const: uartlite + then: + properties: + groups: + enum: [uartlite] + + - if: + properties: + function: + const: wdg_cs1 + then: + properties: + groups: + enum: [spi_cs1] + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + +additionalProperties: false + +examples: + - | + pinctrl { + compatible = "ralink,rt5350-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml index 4fc758fea7e6..0fc3c0f52c19 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml @@ -73,7 +73,7 @@ properties: maxItems: 1 allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml index 9083040c996a..83800fcf0ce4 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml @@ -32,7 +32,7 @@ properties: maxItems: 1 allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml index d761fddc2206..37173a64fed2 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml @@ -73,7 +73,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index f081acb7ba04..9ce1a07fc015 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -113,7 +113,7 @@ additionalProperties: $ref: "#/additionalProperties/anyOf/0" allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml index 70b1788ab594..f3b85b7eae31 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml @@ -32,7 +32,7 @@ properties: The bus clock, sometimes described as pclk, for register accesses. allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml index eac6245db7dc..03f084292d68 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzv2m-pinctrl.yaml @@ -94,7 +94,7 @@ additionalProperties: $ref: "#/additionalProperties/anyOf/0" allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml index 45b767986a87..10c335efe619 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml @@ -50,12 +50,12 @@ properties: - rockchip,rv1126-pinctrl rockchip,grf: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the syscon node for the GRF registers. rockchip,pmu: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the syscon node for the PMU registers, as some SoCs carry parts of the iomux controller registers there. @@ -71,7 +71,7 @@ properties: ranges: true allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible @@ -81,7 +81,7 @@ patternProperties: "gpio@[0-9a-f]+$": type: object - $ref: "/schemas/gpio/rockchip,gpio-bank.yaml#" + $ref: /schemas/gpio/rockchip,gpio-bank.yaml# deprecated: true unevaluatedProperties: false @@ -117,7 +117,7 @@ additionalProperties: type: object properties: rockchip,pins: - $ref: "/schemas/types.yaml#/definitions/uint32-matrix" + $ref: /schemas/types.yaml#/definitions/uint32-matrix minItems: 1 items: items: diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml index eb2b2692607d..26614621774a 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml @@ -117,7 +117,7 @@ required: - reg allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/pinctrl/semtech,sx1501q.yaml b/Documentation/devicetree/bindings/pinctrl/semtech,sx1501q.yaml index 0719c03d6f4b..4214d7311f6b 100644 --- a/Documentation/devicetree/bindings/pinctrl/semtech,sx1501q.yaml +++ b/Documentation/devicetree/bindings/pinctrl/semtech,sx1501q.yaml @@ -62,8 +62,8 @@ patternProperties: - pins allOf: - - $ref: "pincfg-node.yaml#" - - $ref: "pinmux-node.yaml#" + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# - if: properties: pins: @@ -86,7 +86,7 @@ required: - gpio-controller allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# - if: not: properties: diff --git a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml index bc34e2c872bc..a6f34df82e90 100644 --- a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml @@ -61,7 +61,7 @@ additionalProperties: unevaluatedProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index eeb29b4ad4d1..1ab0f8dde477 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -44,7 +44,7 @@ properties: st,syscfg: description: Phandle+args to the syscon node which includes IRQ mux selection. - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: syscon node which includes IRQ mux selection @@ -89,7 +89,7 @@ patternProperties: st,bank-name: description: Should be a name string for this bank as specified in the datasheet. - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: - GPIOA - GPIOB @@ -108,7 +108,7 @@ patternProperties: description: Should correspond to the EXTI IOport selection (EXTI line used to select GPIOs as interrupts). - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 11 @@ -140,7 +140,7 @@ patternProperties: configuration, pullups, drive, output high/low and output speed. properties: pinmux: - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array description: | Integer array, represents gpio pin number and mux setting. Supported pin number and mux varies for different SoCs, and are @@ -201,7 +201,7 @@ patternProperties: - pinmux allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml index 69c0dd9998ea..f3258f2fd3a4 100644 --- a/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml @@ -111,7 +111,7 @@ patternProperties: pins it needs, and how they should be configured, with regard to muxer configuration, bias, input enable/disable, input schmitt trigger enable/disable, slew-rate and drive strength. - $ref: "/schemas/pinctrl/pincfg-node.yaml" + $ref: /schemas/pinctrl/pincfg-node.yaml properties: pins: @@ -120,14 +120,14 @@ patternProperties: This should be set using either the PAD_GPIO or PAD_FUNC_SHARE macros. Either this or "pinmux" has to be specified, but not both. - $ref: "/schemas/pinctrl/pinmux-node.yaml#/properties/pins" + $ref: /schemas/pinctrl/pinmux-node.yaml#/properties/pins pinmux: description: | The list of GPIOs and their mux settings that properties in the node apply to. This should be set using the GPIOMUX macro. Either this or "pins" has to be specified, but not both. - $ref: "/schemas/pinctrl/pinmux-node.yaml#/properties/pinmux" + $ref: /schemas/pinctrl/pinmux-node.yaml#/properties/pinmux bias-disable: true @@ -293,7 +293,7 @@ examples: pinctrl-names = "default"; }; - i2c0 { + i2c { pinctrl-0 = <&i2c0_pins_default>; pinctrl-names = "default"; }; diff --git a/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml index 347061eece9e..94b868c7ceb1 100644 --- a/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml @@ -138,7 +138,7 @@ patternProperties: description: | Define pin-function which is used by pinctrl node's client device. The name should be one of string in the following enumeration. - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: [ SPI_FLASH, SPI_FLASH_4BIT, SPI_NAND, CARD0_EMMC, SD_CARD, UA0, FPGA_IFX, HDMI_TX, LCDIF, USB0_OTG, USB1_OTG ] @@ -146,7 +146,7 @@ patternProperties: description: | Define pin-group in a specified pin-function. The name should be one of string in the following enumeration. - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: [ SPI_FLASH1, SPI_FLASH2, SPI_FLASH_4BIT1, SPI_FLASH_4BIT2, SPI_NAND, CARD0_EMMC, SD_CARD, UA0, FPGA_IFX, HDMI_TX1, HDMI_TX2, HDMI_TX3, LCDIF, USB0_OTG, USB1_OTG ] @@ -289,7 +289,7 @@ required: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# examples: - | diff --git a/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml index 98b4663f9766..19d47fd414bc 100644 --- a/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml @@ -21,7 +21,7 @@ properties: maxItems: 1 allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible @@ -35,14 +35,14 @@ patternProperties: pinctrl groups available on the machine. Each subnode will list the pins it needs, and how they should be configured, with regard to muxer configuration, pullups, drive strength. - $ref: "pinmux-node.yaml" + $ref: pinmux-node.yaml additionalProperties: false properties: function: description: Function to mux. - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: [i2c0, i2c1, i2c2, i2c3, i2c4, i2c5, i2c6, i2c7, i2c8, spi0, spi1, spi2, spi3, spi4, spi5, spi6, uart0, uart1, uart2, uart3, pwm, pcmif_out, pcmif_in] @@ -50,7 +50,7 @@ patternProperties: groups: description: Name of the pin group to use for the functions. - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string enum: [i2c0_grp, i2c1_grp, i2c2_grp, i2c3_grp, i2c4_grp, i2c5_grp, i2c6_grp, i2c7_grp, i2c8_grp, spi0_grp, spi0_cs0_grp, spi0_cs1_grp, spi0_cs2_grp, diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml index cfd0cc549a7b..598a042850b8 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml @@ -168,7 +168,7 @@ patternProperties: additionalProperties: false allOf: - - $ref: "pinctrl.yaml#" + - $ref: pinctrl.yaml# required: - compatible 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/pwm/apple,s5l-fpwm.yaml b/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml new file mode 100644 index 000000000000..142157bff0cd --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/apple,s5l-fpwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple FPWM controller + +maintainers: + - asahi@lists.linux.dev + - Sasha Finkelstein <fnkl.kernel@gmail.com> + +description: PWM controller used for keyboard backlight on ARM Macs + +properties: + compatible: + items: + - enum: + - apple,t8103-fpwm + - apple,t6000-fpwm + - apple,t8112-fpwm + - const: apple,s5l-fpwm + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + "#pwm-cells": + const: 2 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + pwm@235044000 { + compatible = "apple,t8103-fpwm", "apple,s5l-fpwm"; + reg = <0x35044000 0x4000>; + power-domains = <&ps_fpwm1>; + clocks = <&clkref>; + #pwm-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml index dbc974bff9e9..8e176ba7a525 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,mt2712-pwm.yaml @@ -22,6 +22,7 @@ properties: - mediatek,mt7623-pwm - mediatek,mt7628-pwm - mediatek,mt7629-pwm + - mediatek,mt7986-pwm - mediatek,mt8183-pwm - mediatek,mt8365-pwm - mediatek,mt8516-pwm diff --git a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml new file mode 100644 index 000000000000..527864a4d855 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/pwm-amlogic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic PWM + +maintainers: + - Heiner Kallweit <hkallweit1@gmail.com> + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + oneOf: + - enum: + - amlogic,meson8b-pwm + - amlogic,meson-gxbb-pwm + - amlogic,meson-gxbb-ao-pwm + - amlogic,meson-axg-ee-pwm + - amlogic,meson-axg-ao-pwm + - amlogic,meson-g12a-ee-pwm + - amlogic,meson-g12a-ao-pwm-ab + - amlogic,meson-g12a-ao-pwm-cd + - amlogic,meson-s4-pwm + - items: + - const: amlogic,meson-gx-pwm + - const: amlogic,meson-gxbb-pwm + - items: + - const: amlogic,meson-gx-ao-pwm + - const: amlogic,meson-gxbb-ao-pwm + - items: + - const: amlogic,meson8-pwm + - const: amlogic,meson8b-pwm + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + oneOf: + - items: + - enum: [clkin0, clkin1] + - items: + - const: clkin0 + - const: clkin1 + + "#pwm-cells": + const: 3 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pwm@8550 { + compatible = "amlogic,meson-gxbb-pwm"; + reg = <0x08550 0x10>; + clocks = <&xtal>, <&xtal>; + clock-names = "clkin0", "clkin1"; + #pwm-cells = <3>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-meson.txt b/Documentation/devicetree/bindings/pwm/pwm-meson.txt deleted file mode 100644 index bd02b0a1496f..000000000000 --- a/Documentation/devicetree/bindings/pwm/pwm-meson.txt +++ /dev/null @@ -1,29 +0,0 @@ -Amlogic Meson PWM Controller -============================ - -Required properties: -- compatible: Shall contain "amlogic,meson8b-pwm" - or "amlogic,meson-gxbb-pwm" - or "amlogic,meson-gxbb-ao-pwm" - or "amlogic,meson-axg-ee-pwm" - or "amlogic,meson-axg-ao-pwm" - or "amlogic,meson-g12a-ee-pwm" - or "amlogic,meson-g12a-ao-pwm-ab" - or "amlogic,meson-g12a-ao-pwm-cd" -- #pwm-cells: Should be 3. See pwm.yaml in this directory for a description of - the cells format. - -Optional properties: -- clocks: Could contain one or two parents clocks phandle for each of the two - PWM channels. -- clock-names: Could contain at least the "clkin0" and/or "clkin1" names. - -Example: - - pwm_ab: pwm@8550 { - compatible = "amlogic,meson-gxbb-pwm"; - reg = <0x0 0x08550 0x0 0x10>; - #pwm-cells = <3>; - clocks = <&xtal>, <&xtal>; - clock-names = "clkin0", "clkin1"; - } 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/google,cros-ec-regulator.yaml b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml index e0ff5012b763..5a6491a81fda 100644 --- a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml @@ -32,7 +32,7 @@ unevaluatedProperties: false examples: - | - spi0 { + spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml index d2383e523875..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: diff --git a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml index 6b1c6a176dbe..894bdbca78a2 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml @@ -92,7 +92,7 @@ additionalProperties: false examples: - | - i2c1 { + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml index 19b253c09e97..d898800d6bca 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml @@ -82,20 +82,20 @@ patternProperties: # 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 6e693fee3493..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]$": diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml index 1d3dcfba58b0..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]$": 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/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 14b5b7ea0ce0..25d6e8dbffb8 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -66,6 +66,7 @@ properties: - riscv,sv32 - riscv,sv39 - riscv,sv48 + - riscv,sv57 - riscv,none riscv,cbom-block-size: @@ -73,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/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 54e4f41be9b4..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) 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/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,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/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,apr.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml index 4502458b0669..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) 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,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index 94765fbc868e..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 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 60190d84d9b3..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) 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,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/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/renesas,rz-mtu3.yaml b/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml new file mode 100644 index 000000000000..bffdab0b0185 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml @@ -0,0 +1,302 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/renesas,rz-mtu3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/G2L Multi-Function Timer Pulse Unit 3 (MTU3a) + +maintainers: + - Biju Das <biju.das.jz@bp.renesas.com> + +description: | + This hardware block consists of eight 16-bit timer channels and one + 32- bit timer channel. It supports the following specifications: + - Pulse input/output: 28 lines max. + - Pulse input 3 lines + - Count clock 11 clocks for each channel (14 clocks for MTU0, 12 clocks + for MTU2, and 10 clocks for MTU5, four clocks for MTU1-MTU2 combination + (when LWA = 1)) + - Operating frequency Up to 100 MHz + - Available operations [MTU0 to MTU4, MTU6, MTU7, and MTU8] + - Waveform output on compare match + - Input capture function (noise filter setting available) + - Counter-clearing operation + - Simultaneous writing to multiple timer counters (TCNT) + (excluding MTU8). + - Simultaneous clearing on compare match or input capture + (excluding MTU8). + - Simultaneous input and output to registers in synchronization with + counter operations (excluding MTU8). + - Up to 12-phase PWM output in combination with synchronous operation + (excluding MTU8) + - [MTU0 MTU3, MTU4, MTU6, MTU7, and MTU8] + - Buffer operation specifiable + - [MTU1, MTU2] + - Phase counting mode can be specified independently + - 32-bit phase counting mode can be specified for interlocked operation + of MTU1 and MTU2 (when TMDR3.LWA = 1) + - Cascade connection operation available + - [MTU3, MTU4, MTU6, and MTU7] + - Through interlocked operation of MTU3/4 and MTU6/7, the positive and + negative signals in six phases (12 phases in total) can be output in + complementary PWM and reset-synchronized PWM operation. + - In complementary PWM mode, values can be transferred from buffer + registers to temporary registers at crests and troughs of the timer- + counter values or when the buffer registers (TGRD registers in MTU4 + and MTU7) are written to. + - Double-buffering selectable in complementary PWM mode. + - [MTU3 and MTU4] + - Through interlocking with MTU0, a mode for driving AC synchronous + motors (brushless DC motors) by using complementary PWM output and + reset-synchronized PWM output is settable and allows the selection + of two types of waveform output (chopping or level). + - [MTU5] + - Capable of operation as a dead-time compensation counter. + - [MTU0/MTU5, MTU1, MTU2, and MTU8] + - 32-bit phase counting mode specifiable by combining MTU1 and MTU2 and + through interlocked operation with MTU0/MTU5 and MTU8. + - Interrupt-skipping function + - In complementary PWM mode, interrupts on crests and troughs of counter + values and triggers to start conversion by the A/D converter can be + skipped. + - Interrupt sources: 43 sources. + - Buffer operation: + - Automatic transfer of register data (transfer from the buffer + register to the timer register). + - Trigger generation + - A/D converter start triggers can be generated + - A/D converter start request delaying function enables A/D converter + to be started with any desired timing and to be synchronized with + PWM output. + - Low power consumption function + - The MTU3a can be placed in the module-stop state. + + There are two phase counting modes. 16-bit phase counting mode in which + MTU1 and MTU2 operate independently, and cascade connection 32-bit phase + counting mode in which MTU1 and MTU2 are cascaded. + + In phase counting mode, the phase difference between two external input + clocks is detected and the corresponding TCNT is incremented or + decremented. + The below counters are supported + count0 - MTU1 16-bit phase counting + count1 - MTU2 16-bit phase counting + count2 - MTU1+ MTU2 32-bit phase counting + + The module supports PWM mode{1,2}, Reset-synchronized PWM mode and + complementary PWM mode{1,2,3}. + + In complementary PWM mode, six positive-phase and six negative-phase PWM + waveforms (12 phases in total) with dead time can be output by + combining MTU{3,4} and MTU{6,7}. + + The below pwm channels are supported in pwm mode 1. + pwm0 - MTU0.MTIOC0A PWM mode 1 + pwm1 - MTU0.MTIOC0C PWM mode 1 + pwm2 - MTU1.MTIOC1A PWM mode 1 + pwm3 - MTU2.MTIOC2A PWM mode 1 + pwm4 - MTU3.MTIOC3A PWM mode 1 + pwm5 - MTU3.MTIOC3C PWM mode 1 + pwm6 - MTU4.MTIOC4A PWM mode 1 + pwm7 - MTU4.MTIOC4C PWM mode 1 + pwm8 - MTU6.MTIOC6A PWM mode 1 + pwm9 - MTU6.MTIOC6C PWM mode 1 + pwm10 - MTU7.MTIOC7A PWM mode 1 + pwm11 - MTU7.MTIOC7C PWM mode 1 + +properties: + compatible: + items: + - enum: + - renesas,r9a07g044-mtu3 # RZ/G2{L,LC} + - renesas,r9a07g054-mtu3 # RZ/V2L + - const: renesas,rz-mtu3 + + reg: + maxItems: 1 + + interrupts: + items: + - description: MTU0.TGRA input capture/compare match + - description: MTU0.TGRB input capture/compare match + - description: MTU0.TGRC input capture/compare match + - description: MTU0.TGRD input capture/compare match + - description: MTU0.TCNT overflow + - description: MTU0.TGRE compare match + - description: MTU0.TGRF compare match + - description: MTU1.TGRA input capture/compare match + - description: MTU1.TGRB input capture/compare match + - description: MTU1.TCNT overflow + - description: MTU1.TCNT underflow + - description: MTU2.TGRA input capture/compare match + - description: MTU2.TGRB input capture/compare match + - description: MTU2.TCNT overflow + - description: MTU2.TCNT underflow + - description: MTU3.TGRA input capture/compare match + - description: MTU3.TGRB input capture/compare match + - description: MTU3.TGRC input capture/compare match + - description: MTU3.TGRD input capture/compare match + - description: MTU3.TCNT overflow + - description: MTU4.TGRA input capture/compare match + - description: MTU4.TGRB input capture/compare match + - description: MTU4.TGRC input capture/compare match + - description: MTU4.TGRD input capture/compare match + - description: MTU4.TCNT overflow/underflow + - description: MTU5.TGRU input capture/compare match + - description: MTU5.TGRV input capture/compare match + - description: MTU5.TGRW input capture/compare match + - description: MTU6.TGRA input capture/compare match + - description: MTU6.TGRB input capture/compare match + - description: MTU6.TGRC input capture/compare match + - description: MTU6.TGRD input capture/compare match + - description: MTU6.TCNT overflow + - description: MTU7.TGRA input capture/compare match + - description: MTU7.TGRB input capture/compare match + - description: MTU7.TGRC input capture/compare match + - description: MTU7.TGRD input capture/compare match + - description: MTU7.TCNT overflow/underflow + - description: MTU8.TGRA input capture/compare match + - description: MTU8.TGRB input capture/compare match + - description: MTU8.TGRC input capture/compare match + - description: MTU8.TGRD input capture/compare match + - description: MTU8.TCNT overflow + - description: MTU8.TCNT underflow + + interrupt-names: + items: + - const: tgia0 + - const: tgib0 + - const: tgic0 + - const: tgid0 + - const: tgiv0 + - const: tgie0 + - const: tgif0 + - const: tgia1 + - const: tgib1 + - const: tgiv1 + - const: tgiu1 + - const: tgia2 + - const: tgib2 + - const: tgiv2 + - const: tgiu2 + - const: tgia3 + - const: tgib3 + - const: tgic3 + - const: tgid3 + - const: tgiv3 + - const: tgia4 + - const: tgib4 + - const: tgic4 + - const: tgid4 + - const: tgiv4 + - const: tgiu5 + - const: tgiv5 + - const: tgiw5 + - const: tgia6 + - const: tgib6 + - const: tgic6 + - const: tgid6 + - const: tgiv6 + - const: tgia7 + - const: tgib7 + - const: tgic7 + - const: tgid7 + - const: tgiv7 + - const: tgia8 + - const: tgib8 + - const: tgic8 + - const: tgid8 + - const: tgiv8 + - const: tgiu8 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + "#pwm-cells": + const: 2 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r9a07g044-cpg.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mtu3: timer@10001200 { + compatible = "renesas,r9a07g044-mtu3", "renesas,rz-mtu3"; + reg = <0x10001200 0xb00>; + interrupts = <GIC_SPI 170 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 171 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 172 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 173 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 174 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 175 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 176 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 178 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 179 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 180 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 181 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 182 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 183 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 184 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 185 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 186 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 187 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 188 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 189 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 190 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 191 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 192 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 193 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 194 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 195 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 196 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 198 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 199 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 200 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 201 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 202 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 203 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 204 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 205 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 206 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 207 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 208 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 209 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 210 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 211 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 212 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 213 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "tgia0", "tgib0", "tgic0", "tgid0", "tgiv0", "tgie0", + "tgif0", + "tgia1", "tgib1", "tgiv1", "tgiu1", + "tgia2", "tgib2", "tgiv2", "tgiu2", + "tgia3", "tgib3", "tgic3", "tgid3", "tgiv3", + "tgia4", "tgib4", "tgic4", "tgid4", "tgiv4", + "tgiu5", "tgiv5", "tgiw5", + "tgia6", "tgib6", "tgic6", "tgid6", "tgiv6", + "tgia7", "tgib7", "tgic7", "tgid7", "tgiv7", + "tgia8", "tgib8", "tgic8", "tgid8", "tgiv8", "tgiu8"; + clocks = <&cpg CPG_MOD R9A07G044_MTU_X_MCK_MTU3>; + power-domains = <&cpg>; + resets = <&cpg R9A07G044_MTU_X_PRESET_MTU3>; + #pwm-cells = <2>; + }; 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/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/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml index c31e207d1652..456797967adc 100644 --- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml +++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/timestamp/nvidia,tegra194-hte.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Tegra194 on chip generic hardware timestamping engine (HTE) +title: Tegra on chip generic hardware timestamping engine (HTE) provider maintainers: - Dipen Patel <dipenp@nvidia.com> @@ -23,6 +23,8 @@ properties: enum: - nvidia,tegra194-gte-aon - nvidia,tegra194-gte-lic + - nvidia,tegra234-gte-aon + - nvidia,tegra234-gte-lic reg: maxItems: 1 @@ -40,12 +42,20 @@ properties: nvidia,slices: $ref: /schemas/types.yaml#/definitions/uint32 + deprecated: true description: HTE lines are arranged in 32 bit slice where each bit represents different line/signal that it can enable/configure for the timestamp. It is u32 - property and depends on the HTE instance in the chip. The value 3 is for - GPIO GTE and 11 for IRQ GTE. - enum: [3, 11] + property and the value depends on the HTE instance in the chip. The AON + GTE instances for both Tegra194 and Tegra234 has 3 slices. The Tegra194 + LIC instance has 11 slices and Tegra234 LIC has 17 slices. + enum: [3, 11, 17] + + nvidia,gpio-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle to AON gpio controller instance. This is required to handle + namespace conversion between GPIO and GTE. '#timestamp-cells': description: @@ -59,9 +69,53 @@ required: - compatible - reg - interrupts - - nvidia,slices - "#timestamp-cells" +allOf: + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra194-gte-aon + - nvidia,tegra234-gte-aon + then: + properties: + nvidia,slices: + const: 3 + + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra194-gte-lic + then: + properties: + nvidia,slices: + const: 11 + + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra234-gte-lic + then: + properties: + nvidia,slices: + const: 17 + + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra234-gte-aon + then: + required: + - nvidia,gpio-controller + additionalProperties: false examples: @@ -71,7 +125,6 @@ examples: reg = <0xc1e0000 0x10000>; interrupts = <0 13 0x4>; nvidia,int-threshold = <1>; - nvidia,slices = <3>; #timestamp-cells = <1>; }; @@ -81,7 +134,6 @@ examples: reg = <0x3aa0000 0x10000>; interrupts = <0 11 0x4>; nvidia,int-threshold = <1>; - nvidia,slices = <11>; #timestamp-cells = <1>; }; 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 3e29fbd53b6d..82d39ab0231b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -777,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,.*": @@ -941,6 +943,8 @@ patternProperties: description: Nokia "^nordic,.*": description: Nordic Semiconductor + "^novatek,.*": + description: Novatek "^novtech,.*": description: NovTech, Inc. "^nutsboard,.*": 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 3d7e2a2bf1f1..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> 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 e7a87ce94772..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> 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/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_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/hte/index.rst b/Documentation/driver-api/hte/index.rst index 9f43301c05dc..29011de9a4b8 100644 --- a/Documentation/driver-api/hte/index.rst +++ b/Documentation/driver-api/hte/index.rst @@ -18,5 +18,5 @@ HTE Tegra Provider .. toctree:: :maxdepth: 1 - tegra194-hte + tegra-hte diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra-hte.rst index f2d617265546..85e654772782 100644 --- a/Documentation/driver-api/hte/tegra194-hte.rst +++ b/Documentation/driver-api/hte/tegra-hte.rst @@ -5,25 +5,25 @@ HTE Kernel provider driver Description ----------- -The Nvidia tegra194 HTE provider driver implements two GTE -(Generic Timestamping Engine) instances: 1) GPIO GTE and 2) LIC -(Legacy Interrupt Controller) IRQ GTE. Both GTE instances get the -timestamp from the system counter TSC which has 31.25MHz clock rate, and the -driver converts clock tick rate to nanoseconds before storing it as timestamp -value. +The Nvidia tegra HTE provider also known as GTE (Generic Timestamping Engine) +driver implements two GTE instances: 1) GPIO GTE and 2) LIC +(Legacy Interrupt Controller) IRQ GTE. Both GTE instances get the timestamp +from the system counter TSC which has 31.25MHz clock rate, and the driver +converts clock tick rate to nanoseconds before storing it as timestamp value. GPIO GTE -------- This GTE instance timestamps GPIO in real time. For that to happen GPIO -needs to be configured as input. The always on (AON) GPIO controller instance -supports timestamping GPIOs in real time and it has 39 GPIO lines. The GPIO GTE -and AON GPIO controller are tightly coupled as it requires very specific bits -to be set in GPIO config register before GPIO GTE can be used, for that GPIOLIB -adds two optional APIs as below. The GPIO GTE code supports both kernel -and userspace consumers. The kernel space consumers can directly talk to HTE -subsystem while userspace consumers timestamp requests go through GPIOLIB CDEV -framework to HTE subsystem. +needs to be configured as input. Only the always on (AON) GPIO controller +instance supports timestamping GPIOs in real time as it is tightly coupled with +the GPIO GTE. To support this, GPIOLIB adds two optional APIs as mentioned +below. The GPIO GTE code supports both kernel and userspace consumers. The +kernel space consumers can directly talk to HTE subsystem while userspace +consumers timestamp requests go through GPIOLIB CDEV framework to HTE +subsystem. The hte devicetree binding described at +``Documentation/devicetree/bindings/timestamp`` provides an example of how a +consumer can request an GPIO line. See gpiod_enable_hw_timestamp_ns() and gpiod_disable_hw_timestamp_ns(). @@ -34,9 +34,8 @@ returns the timestamp in nanoseconds. LIC (Legacy Interrupt Controller) IRQ GTE ----------------------------------------- -This GTE instance timestamps LIC IRQ lines in real time. There are 352 IRQ -lines which this instance can add timestamps to in real time. The hte -devicetree binding described at ``Documentation/devicetree/bindings/timestamp`` +This GTE instance timestamps LIC IRQ lines in real time. The hte devicetree +binding described at ``Documentation/devicetree/bindings/timestamp`` provides an example of how a consumer can request an IRQ line. Since it is a one-to-one mapping with IRQ GTE provider, consumers can simply specify the IRQ number that they are interested in. There is no userspace consumer support for 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/pwm.rst b/Documentation/driver-api/pwm.rst index 8c71a2055d27..3fdc95f7a1d1 100644 --- a/Documentation/driver-api/pwm.rst +++ b/Documentation/driver-api/pwm.rst @@ -35,12 +35,9 @@ consumers to providers, as given in the following example:: Using PWMs ---------- -Legacy users can request a PWM device using pwm_request() and free it -after usage with pwm_free(). - -New users should use the pwm_get() function and pass to it the consumer -device or a consumer name. pwm_put() is used to free the PWM device. Managed -variants of the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also exist. +Consumers use the pwm_get() function and pass to it the consumer device or a +consumer name. pwm_put() is used to free the PWM device. Managed variants of +the getter, devm_pwm_get() and devm_fwnode_pwm_get(), also exist. After being requested, a PWM has to be configured using:: @@ -165,8 +162,8 @@ consumers should implement it as described in the "Using PWMs" section. Locking ------- -The PWM core list manipulations are protected by a mutex, so pwm_request() -and pwm_free() may not be called from an atomic context. Currently the +The PWM core list manipulations are protected by a mutex, so pwm_get() +and pwm_put() may not be called from an atomic context. Currently the PWM core does not enforce any locking to pwm_enable(), pwm_disable() and pwm_config(), so the calling context is currently driver specific. This is an issue derived from the former barebone API and should be fixed soon. 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/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/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/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/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 59db0bed35e1..7897a7dafcbc 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -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 @@ -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 @@ -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. 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/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/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/leds/index.rst b/Documentation/leds/index.rst index b9ca081fac71..ce57254cb871 100644 --- a/Documentation/leds/index.rst +++ b/Documentation/leds/index.rst @@ -25,5 +25,6 @@ LEDs leds-lp5562 leds-lp55xx leds-mlxcpld + leds-mt6370-rgb leds-sc27xx leds-qcom-lpg diff --git a/Documentation/leds/leds-mt6370-rgb.rst b/Documentation/leds/leds-mt6370-rgb.rst new file mode 100644 index 000000000000..152a2e592172 --- /dev/null +++ b/Documentation/leds/leds-mt6370-rgb.rst @@ -0,0 +1,64 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================= +The device for Mediatek MT6370 RGB LED +========================================= + +Description +----------- + +The MT6370 integrates a four-channel RGB LED driver, designed to provide a +variety of lighting effect for mobile device applications. The RGB LED devices +includes a smart LED string controller and it can drive 3 channels of LEDs with +a sink current up to 24mA and a CHG_VIN power good indicator LED with sink +current up to 6mA. It provides three operation modes for RGB LEDs: +PWM Dimming mode, breath pattern mode, and constant current mode. The device +can increase or decrease the brightness of the RGB LED via an I2C interface. + +The breath pattern for a channel can be programmed using the "pattern" trigger, +using the hw_pattern attribute. + +/sys/class/leds/<led>/hw_pattern +-------------------------------- + +Specify a hardware breath pattern for a MT6370 RGB LED. + +The breath pattern is a series of timing pairs, with the hold-time expressed in +milliseconds. And the brightness is controlled by +'/sys/class/leds/<led>/brightness'. The pattern doesn't include the brightness +setting. Hardware pattern only controls the timing for each pattern stage +depending on the current brightness setting. + +Pattern diagram:: + + "0 Tr1 0 Tr2 0 Tf1 0 Tf2 0 Ton 0 Toff" --> '0' for dummy brightness code + + ^ + | ============ + | / \ / + Icurr | / \ / + | / \ / + | / \ / .....repeat + | / \ / + | --- --- --- + |--- --- --- + +----------------------------------============------------> Time + < Tr1><Tr2>< Ton ><Tf1><Tf2 >< Toff >< Tr1><Tr2> + +Timing description: + + * Tr1: First rising time for 0% - 30% load. + * Tr2: Second rising time for 31% - 100% load. + * Ton: On time for 100% load. + * Tf1: First falling time for 100% - 31% load. + * Tf2: Second falling time for 30% to 0% load. + * Toff: Off time for 0% load. + + * Tr1/Tr2/Tf1/Tf2/Ton: 125ms to 3125ms, 200ms per step. + * Toff: 250ms to 6250ms, 400ms per step. + +Pattern example:: + + "0 125 0 125 0 125 0 125 0 625 0 1050" + +This Will configure Tr1/Tr2/Tf1/Tf2 to 125m, Ton to 625ms, and Toff to 1050ms. diff --git a/Documentation/leds/ledtrig-oneshot.rst b/Documentation/leds/ledtrig-oneshot.rst index 69fa3ea1d554..e044d69e9c0f 100644 --- a/Documentation/leds/ledtrig-oneshot.rst +++ b/Documentation/leds/ledtrig-oneshot.rst @@ -5,7 +5,7 @@ One-shot LED Trigger This is a LED trigger useful for signaling the user of an event where there are no clear trap points to put standard led-on and led-off settings. Using this trigger, the application needs only to signal the trigger when an event has -happened, than the trigger turns the LED on and than keeps it off for a +happened, then the trigger turns the LED on and then keeps it off for a specified amount of time. This trigger is meant to be usable both for sporadic and dense events. In the 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/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/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/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/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/netlink/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml index 5c3642b3f802..8e8c17b0a6c6 100644 --- a/Documentation/netlink/genetlink-c.yaml +++ b/Documentation/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 5e98c6d2b9aa..b33541a51d6b 100644 --- a/Documentation/netlink/genetlink-legacy.yaml +++ b/Documentation/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 d35dcd6f8d82..d8b2cdeba058 100644 --- a/Documentation/netlink/genetlink.yaml +++ b/Documentation/netlink/genetlink.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 4727c067e2ba..129f413ea349 100644 --- a/Documentation/netlink/specs/ethtool.yaml +++ b/Documentation/netlink/specs/ethtool.yaml @@ -6,6 +6,12 @@ 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 @@ -38,6 +44,7 @@ attribute-sets: - name: bit type: nest + multi-attr: true nested-attributes: bitset-bit - name: bitset @@ -54,6 +61,22 @@ 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: - @@ -165,6 +188,12 @@ 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 @@ -228,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 @@ -249,9 +929,188 @@ operations: - 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. @@ -260,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 @@ -277,9 +1134,7 @@ operations: do: request: - attributes: - - header - - flags + attributes: *privflag - name: privflags-ntf doc: Notification for change in device private flags. @@ -296,7 +1151,7 @@ operations: attributes: - header reply: - attributes: + attributes: &ring - header - rx-max - rx-mini-max @@ -311,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 @@ -320,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 @@ -346,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/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/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/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 58a78a316697..6ec06a33688a 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -2721,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/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/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/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 7a5619fecb38..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 @@ -495,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/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/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/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/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 e8bca5fea7cc..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. 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/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/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/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/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/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/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_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/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 index 6d22faceb1a0..62bd81ba3dd1 100644 --- a/Documentation/usb/gadget_uvc.rst +++ b/Documentation/usb/gadget_uvc.rst @@ -275,6 +275,34 @@ out with 0x00, for example: 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 ~~~~~~~~~~~~~~~~~~~~~~ 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/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 a22442ba1d30..2e4acde890b7 100644 --- a/Documentation/userspace-api/netlink/specs.rst +++ b/Documentation/userspace-api/netlink/specs.rst @@ -254,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/kvm/api.rst b/Documentation/virt/kvm/api.rst index 841e9d1987bd..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 diff --git a/Documentation/virt/kvm/devices/vfio.rst b/Documentation/virt/kvm/devices/vfio.rst index 2d20dc561069..08b544212638 100644 --- a/Documentation/virt/kvm/devices/vfio.rst +++ b/Documentation/virt/kvm/devices/vfio.rst @@ -39,3 +39,8 @@ KVM_DEV_VFIO_GROUP attributes: - @groupfd is a file descriptor for a VFIO group; - @tablefd is a file descriptor for a TCE table allocated via KVM_CREATE_SPAPR_TCE. + +The GROUP_ADD operation above should be invoked prior to accessing the +device file descriptor via VFIO_GROUP_GET_DEVICE_FD in order to support +drivers which require a kvm pointer to be set in their .open_device() +callback. 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: |