diff options
Diffstat (limited to 'Documentation')
553 files changed, 20265 insertions, 6582 deletions
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 b/Documentation/ABI/testing/configfs-usb-gadget-uac1 index dc23fd776943..dd647d44d975 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac1 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1 @@ -8,9 +8,19 @@ Description: c_chmask capture channel mask c_srate capture sampling rate c_ssize capture sample size (bytes) + c_mute_present capture mute control enable + c_volume_present capture volume control enable + c_volume_min capture volume control min value (in 1/256 dB) + c_volume_max capture volume control max value (in 1/256 dB) + c_volume_res capture volume control resolution (in 1/256 dB) p_chmask playback channel mask p_srate playback sampling rate p_ssize playback sample size (bytes) + p_mute_present playback mute control enable + p_volume_present playback volume control enable + p_volume_min playback volume control min value (in 1/256 dB) + p_volume_max playback volume control max value (in 1/256 dB) + p_volume_res playback volume control resolution (in 1/256 dB) req_number the number of pre-allocated request for both capture and playback ========== =================================== diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index 26fb8e9b4e61..cfd160ff8b56 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -9,8 +9,18 @@ Description: c_srate capture sampling rate c_ssize capture sample size (bytes) c_sync capture synchronization type (async/adaptive) + c_mute_present capture mute control enable + c_volume_present capture volume control enable + c_volume_min capture volume control min value (in 1/256 dB) + c_volume_max capture volume control max value (in 1/256 dB) + c_volume_res capture volume control resolution (in 1/256 dB) fb_max maximum extra bandwidth in async mode p_chmask playback channel mask p_srate playback sampling rate p_ssize playback sample size (bytes) + p_mute_present playback mute control enable + p_volume_present playback volume control enable + p_volume_min playback volume control min value (in 1/256 dB) + p_volume_max playback volume control max value (in 1/256 dB) + p_volume_res playback volume control resolution (in 1/256 dB) ========= ============================ diff --git a/Documentation/ABI/testing/dell-smbios-wmi b/Documentation/ABI/testing/dell-smbios-wmi index 5f3a0dc67050..f58229084469 100644 --- a/Documentation/ABI/testing/dell-smbios-wmi +++ b/Documentation/ABI/testing/dell-smbios-wmi @@ -1,7 +1,7 @@ What: /dev/wmi/dell-smbios Date: November 2017 KernelVersion: 4.15 -Contact: "Mario Limonciello" <mario.limonciello@dell.com> +Contact: Dell.Client.Kernel@dell.com Description: Perform SMBIOS calls on supported Dell machines. through the Dell ACPI-WMI interface. diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index 070779e8d836..5c2798534950 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -27,12 +27,13 @@ Description: lsm: [[subj_user=] [subj_role=] [subj_type=] [obj_user=] [obj_role=] [obj_type=]] option: [[appraise_type=]] [template=] [permit_directio] - [appraise_flag=] [keyrings=] + [appraise_flag=] [appraise_algos=] [keyrings=] base: func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK] - [FIRMWARE_CHECK] + [FIRMWARE_CHECK] [KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK] [KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA] + [SETXATTR_CHECK] mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND] [[^]MAY_EXEC] fsmagic:= hex value @@ -55,6 +56,10 @@ Description: label:= [selinux]|[kernel_info]|[data_label] data_label:= a unique string used for grouping and limiting critical data. For example, "selinux" to measure critical data for SELinux. + appraise_algos:= comma-separated list of hash algorithms + For example, "sha256,sha512" to only accept to appraise + files where the security.ima xattr was hashed with one + of these two algorithms. default policy: # PROC_SUPER_MAGIC @@ -134,3 +139,9 @@ Description: keys added to .builtin_trusted_keys or .ima keyring: measure func=KEY_CHECK keyrings=.builtin_trusted_keys|.ima + + Example of the special SETXATTR_CHECK appraise rule, that + restricts the hash algorithms allowed when writing to the + security.ima xattr of a file: + + appraise func=SETXATTR_CHECK appraise_algos=sha256,sha384,sha512 diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index e34cdeeeb9d4..a0ed87386639 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block @@ -28,6 +28,18 @@ Description: For more details refer Documentation/admin-guide/iostats.rst +What: /sys/block/<disk>/diskseq +Date: February 2021 +Contact: Matteo Croce <mcroce@microsoft.com> +Description: + The /sys/block/<disk>/diskseq files reports the disk + sequence number, which is a monotonically increasing + number assigned to every drive. + Some devices, like the loop device, refresh such number + every time the backing file is changed. + The value type is 64 bit unsigned. + + What: /sys/block/<disk>/<part>/stat Date: February 2008 Contact: Jerome Marchand <jmarchan@redhat.com> diff --git a/Documentation/ABI/testing/sysfs-block-device b/Documentation/ABI/testing/sysfs-block-device index aa0fb500e3c9..7ac7b19b2f72 100644 --- a/Documentation/ABI/testing/sysfs-block-device +++ b/Documentation/ABI/testing/sysfs-block-device @@ -55,6 +55,43 @@ Date: Oct, 2016 KernelVersion: v4.10 Contact: linux-ide@vger.kernel.org Description: - (RW) Write to the file to turn on or off the SATA ncq (native - command queueing) support. By default this feature is turned - off. + (RW) Write to the file to turn on or off the SATA NCQ (native + command queueing) priority support. By default this feature is + turned off. If the device does not support the SATA NCQ + priority feature, writing "1" to this file results in an error + (see ncq_prio_supported). + + +What: /sys/block/*/device/sas_ncq_prio_enable +Date: Oct, 2016 +KernelVersion: v4.10 +Contact: linux-ide@vger.kernel.org +Description: + (RW) This is the equivalent of the ncq_prio_enable attribute + file for SATA devices connected to a SAS host-bus-adapter + (HBA) implementing support for the SATA NCQ priority feature. + This file does not exist if the HBA driver does not implement + support for the SATA NCQ priority feature, regardless of the + device support for this feature (see sas_ncq_prio_supported). + + +What: /sys/block/*/device/ncq_prio_supported +Date: Aug, 2021 +KernelVersion: v5.15 +Contact: linux-ide@vger.kernel.org +Description: + (RO) Indicates if the device supports the SATA NCQ (native + command queueing) priority feature. + + +What: /sys/block/*/device/sas_ncq_prio_supported +Date: Aug, 2021 +KernelVersion: v5.15 +Contact: linux-ide@vger.kernel.org +Description: + (RO) This is the equivalent of the ncq_prio_supported attribute + file for SATA devices connected to a SAS host-bus-adapter + (HBA) implementing support for the SATA NCQ priority feature. + This file does not exist if the HBA driver does not implement + support for the SATA NCQ priority feature, regardless of the + device support for this feature. diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-uncore b/Documentation/ABI/testing/sysfs-bus-event_source-devices-uncore new file mode 100644 index 000000000000..b56e8f019fd4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-uncore @@ -0,0 +1,13 @@ +What: /sys/bus/event_source/devices/uncore_*/alias +Date: June 2021 +KernelVersion: 5.15 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: Read-only. An attribute to describe the alias name of + the uncore PMU if an alias exists on some platforms. + The 'perf(1)' tool should treat both names the same. + They both can be used to access the uncore PMU. + + Example: + + $ cat /sys/devices/uncore_cha_2/alias + uncore_type_0_2 diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 new file mode 100644 index 000000000000..469a7c00fad4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-sgp40 @@ -0,0 +1,31 @@ +What: /sys/bus/iio/devices/iio:deviceX/out_temp_raw +Date: August 2021 +KernelVersion: 5.15 +Contact: Andreas Klinger <ak@it-klinger.de> +Description: + Set the temperature. This value is sent to the sensor for + temperature compensation. + Default value: 25000 (25 °C) + +What: /sys/bus/iio/devices/iio:deviceX/out_humidityrelative_raw +Date: August 2021 +KernelVersion: 5.15 +Contact: Andreas Klinger <ak@it-klinger.de> +Description: + Set the relative humidity. This value is sent to the sensor for + humidity compensation. + Default value: 50000 (50 % relative humidity) + +What: /sys/bus/iio/devices/iio:deviceX/in_resistance_calibbias +Date: August 2021 +KernelVersion: 5.15 +Contact: Andreas Klinger <ak@it-klinger.de> +Description: + Set the bias value for the resistance which is used for + calculation of in_concentration_input as follows: + + x = (in_resistance_raw - in_resistance_calibbias) * 0.65 + + in_concentration_input = 500 / (1 + e^x) + + Default value: 30000 diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index 793cbb76cd25..d4ae03296861 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -121,6 +121,23 @@ Description: child buses, and re-discover devices removed earlier from this part of the device tree. +What: /sys/bus/pci/devices/.../reset_method +Date: August 2021 +Contact: Amey Narkhede <ameynarkhede03@gmail.com> +Description: + Some devices allow an individual function to be reset + without affecting other functions in the same slot. + + For devices that have this support, a file named + reset_method is present in sysfs. Reading this file + gives names of the supported and enabled reset methods and + their ordering. Writing a space-separated list of names of + reset methods sets the reset methods and ordering to be + used when resetting the device. Writing an empty string + disables the ability to reset the device. Writing + "default" enables all supported reset methods in the + default ordering. + What: /sys/bus/pci/devices/.../reset Date: July 2009 Contact: Michael S. Tsirkin <mst@redhat.com> diff --git a/Documentation/ABI/testing/sysfs-bus-platform b/Documentation/ABI/testing/sysfs-bus-platform index 194ca700e962..ff30728595ef 100644 --- a/Documentation/ABI/testing/sysfs-bus-platform +++ b/Documentation/ABI/testing/sysfs-bus-platform @@ -28,3 +28,17 @@ Description: value comes from an ACPI _PXM method or a similar firmware source. Initial users for this file would be devices like arm smmu which are populated by arm64 acpi_iort. + +What: /sys/bus/platform/devices/.../msi_irqs/ +Date: August 2021 +Contact: Barry Song <song.bao.hua@hisilicon.com> +Description: + The /sys/devices/.../msi_irqs directory contains a variable set + of files, with each file being named after a corresponding msi + irq vector allocated to that device. + +What: /sys/bus/platform/devices/.../msi_irqs/<N> +Date: August 2021 +Contact: Barry Song <song.bao.hua@hisilicon.com> +Description: + This attribute will show "msi" if <N> is a valid msi irq diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index 95c21d6c9a84..b7e87f6c7d47 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -232,7 +232,7 @@ Description: When new NVM image is written to the non-active NVM What: /sys/bus/thunderbolt/devices/.../nvm_authenticate_on_disconnect Date: Oct 2020 KernelVersion: v5.9 -Contact: Mario Limonciello <mario.limonciello@dell.com> +Contact: Mario Limonciello <mario.limonciello@outlook.com> Description: For supported devices, automatically authenticate the new Thunderbolt image when the device is disconnected from the host system. diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 3348bf80a37c..90fdf935aa5e 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -2,8 +2,8 @@ What: /sys/class/firmware-attributes/*/attributes/*/ Date: February 2021 KernelVersion: 5.11 Contact: Divya Bharathi <Divya.Bharathi@Dell.com>, - Mario Limonciello <mario.limonciello@dell.com>, Prasanth KSR <prasanth.ksr@dell.com> + Dell.Client.Kernel@dell.com Description: A sysfs interface for systems management software to enable configuration capability on supported systems. This directory @@ -130,8 +130,8 @@ What: /sys/class/firmware-attributes/*/authentication/ Date: February 2021 KernelVersion: 5.11 Contact: Divya Bharathi <Divya.Bharathi@Dell.com>, - Mario Limonciello <mario.limonciello@dell.com>, Prasanth KSR <prasanth.ksr@dell.com> + Dell.Client.Kernel@dell.com Description: Devices support various authentication mechanisms which can be exposed as a separate configuration object. @@ -220,8 +220,8 @@ What: /sys/class/firmware-attributes/*/attributes/pending_reboot Date: February 2021 KernelVersion: 5.11 Contact: Divya Bharathi <Divya.Bharathi@Dell.com>, - Mario Limonciello <mario.limonciello@dell.com>, Prasanth KSR <prasanth.ksr@dell.com> + Dell.Client.Kernel@dell.com Description: A read-only attribute reads 1 if a reboot is necessary to apply pending BIOS attribute changes. Also, an uevent_KOBJ_CHANGE is @@ -249,8 +249,8 @@ What: /sys/class/firmware-attributes/*/attributes/reset_bios Date: February 2021 KernelVersion: 5.11 Contact: Divya Bharathi <Divya.Bharathi@Dell.com>, - Mario Limonciello <mario.limonciello@dell.com>, Prasanth KSR <prasanth.ksr@dell.com> + Dell.Client.Kernel@dell.com Description: This attribute can be used to reset the BIOS Configuration. Specifically, it tells which type of reset BIOS configuration is being @@ -272,3 +272,14 @@ Description: Note that any changes to this attribute requires a reboot for changes to take effect. + +What: /sys/class/firmware-attributes/*/attributes/debug_cmd +Date: July 2021 +KernelVersion: 5.14 +Contact: Mark Pearson <markpearson@lenovo.com> +Description: + This write only attribute can be used to send debug commands to the BIOS. + This should only be used when recommended by the BIOS vendor. Vendors may + use it to enable extra debug attributes or BIOS features for testing purposes. + + Note that any changes to this attribute requires a reboot for changes to take effect. diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 160b10c029c0..b46ef147616a 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -494,6 +494,15 @@ Description: AArch64 CPU registers 'identification' directory exposes the CPU ID registers for identifying model and revision of the CPU. +What: /sys/devices/system/cpu/aarch32_el0 +Date: May 2021 +Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org> +Description: Identifies the subset of CPUs in the system that can execute + AArch32 (32-bit ARM) applications. If present, the same format as + /sys/devices/system/cpu/{offline,online,possible,present} is used. + If absent, then all or none of the CPUs can execute AArch32 + applications and execve() will behave accordingly. + What: /sys/devices/system/cpu/cpu#/cpu_capacity Date: December 2016 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> @@ -640,3 +649,20 @@ Description: SPURR ticks for cpuX when it was idle. This sysfs interface exposes the number of SPURR ticks for cpuX when it was idle. + +What: /sys/devices/system/cpu/cpuX/mte_tcf_preferred +Date: July 2021 +Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org> +Description: Preferred MTE tag checking mode + + When a user program specifies more than one MTE tag checking + mode, this sysfs node is used to specify which mode should + be preferred when scheduling a task on that CPU. Possible + values: + + ================ ============================================== + "sync" Prefer synchronous mode + "async" Prefer asynchronous mode + ================ ============================================== + + See also: Documentation/arm64/memory-tagging-extension.rst diff --git a/Documentation/ABI/testing/sysfs-driver-ge-achc b/Documentation/ABI/testing/sysfs-driver-ge-achc new file mode 100644 index 000000000000..a9e7a079190c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-ge-achc @@ -0,0 +1,15 @@ +What: /sys/bus/spi/<dev>/update_firmware +Date: Jul 2021 +Contact: sebastian.reichel@collabora.com +Description: Write 1 to this file to update the ACHC microcontroller + firmware via the EzPort interface. For this the kernel + will load "achc.bin" via the firmware API (so usually + from /lib/firmware). The write will block until the FW + has either been flashed successfully or an error occured. + +What: /sys/bus/spi/<dev>/reset +Date: Jul 2021 +Contact: sebastian.reichel@collabora.com +Description: This file represents the microcontroller's reset line. + 1 means the reset line is asserted, 0 means it's not + asserted. The file is read and writable. diff --git a/Documentation/ABI/testing/sysfs-driver-intc_sar b/Documentation/ABI/testing/sysfs-driver-intc_sar new file mode 100644 index 000000000000..ec334b0e5ed9 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intc_sar @@ -0,0 +1,54 @@ +What: /sys/bus/platform/devices/INTC1092:00/intc_reg +Date: August 2021 +KernelVersion: 5.15 +Contact: Shravan S <s.shravan@intel.com>, + An Sudhakar <sudhakar.an@intel.com> +Description: + Specific Absorption Rate (SAR) regulatory mode is typically + derived based on information like mcc (Mobile Country Code) and + mnc (Mobile Network Code) that is available for the currently + attached LTE network. A userspace application is required to set + the current SAR regulatory mode on the Dynamic SAR driver using + this sysfs node. Such an application can also read back using + this sysfs node, the currently configured regulatory mode value + from the Dynamic SAR driver. + + Acceptable regulatory modes are: + == ==== + 0 FCC + 1 CE + 2 ISED + == ==== + + - The regulatory mode value has one of the above values. + - The default regulatory mode used in the driver is 0. + +What: /sys/bus/platform/devices/INTC1092:00/intc_data +Date: August 2021 +KernelVersion: 5.15 +Contact: Shravan S <s.shravan@intel.com>, + An Sudhakar <sudhakar.an@intel.com> +Description: + This sysfs entry is used to retrieve Dynamic SAR information + emitted/maintained by a BIOS that supports Dynamic SAR. + + The retrieved information is in the order given below: + - device_mode + - bandtable_index + - antennatable_index + - sartable_index + + The above information is sent as integer values separated + by a single space. This information can then be pushed to a + WWAN modem that uses this to control the transmit signal + level using the Band/Antenna/SAR table index information. + These parameters are derived/decided by aggregating + device-mode like laptop/tablet/clamshell etc. and the + proximity-sensor data available to the embedded controller on + given host. The regulatory mode configured on Dynamic SAR + driver also influences these values. + + The userspace applications can poll for changes to this file + using POLLPRI event on file-descriptor (fd) obtained by opening + this sysfs entry. Application can then read this information from + the sysfs node and consume the given information. diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index b4a5d55fa19f..ec3a7149ced5 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -1298,3 +1298,239 @@ Description: This node is used to set or display whether UFS WriteBooster is (if the platform supports UFSHCD_CAP_CLK_SCALING). For a platform that doesn't support UFSHCD_CAP_CLK_SCALING, we can disable/enable WriteBooster through this sysfs node. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the HPB specification version. + The full information about the descriptor can be found in the UFS + HPB (Host Performance Booster) Extension specifications. + Example: version 1.2.3 = 0123h + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows an indication of the HPB control mode. + 00h: Host control mode + 01h: Device control mode + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_region_size +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the bHPBRegionSize which can be calculated + as in the following (in bytes): + HPB Region size = 512B * 2^bHPBRegionSize + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the maximum number of HPB LU supported by + the device. + 00h: HPB is not supported by the device. + 01h ~ 20h: Maximum number of HPB LU supported by the device + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_subregion_size +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the bHPBSubRegionSize, which can be + calculated as in the following (in bytes) and shall be a multiple of + logical block size: + HPB Sub-Region size = 512B x 2^bHPBSubRegionSize + bHPBSubRegionSize shall not exceed bHPBRegionSize. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_max_active_regions +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the maximum number of active HPB regions that + is supported by the device. + + The file is read only. + +What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_lu_max_active_regions +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the maximum number of HPB regions assigned to + the HPB logical unit. + + The file is read only. + +What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_pinned_region_start_offset +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the start offset of HPB pinned region. + + The file is read only. + +What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_number_pinned_regions +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the number of HPB pinned regions assigned to + the HPB logical unit. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/hit_cnt +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the number of reads that changed to HPB read. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/miss_cnt +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the number of reads that cannot be changed to + HPB read. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/rb_noti_cnt +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the number of response UPIUs that has + recommendations for activating sub-regions and/or inactivating region. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/rb_active_cnt +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the number of active sub-regions recommended by + response UPIUs. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/rb_inactive_cnt +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the number of inactive regions recommended by + response UPIUs. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_stats/map_req_cnt +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the number of read buffer commands for + activating sub-regions recommended by response UPIUs. + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_params/requeue_timeout_ms +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the requeue timeout threshold for write buffer + command in ms. The value can be changed by writing an integer to + this entry. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_size_hpb_single_cmd +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the maximum HPB data size for using a single HPB + command. + + === ======== + 00h 4KB + 01h 8KB + 02h 12KB + ... + FFh 1024KB + === ======== + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/flags/hpb_enable +Date: June 2021 +Contact: Daejun Park <daejun7.park@samsung.com> +Description: This entry shows the status of HPB. + + == ============================ + 0 HPB is not enabled. + 1 HPB is enabled + == ============================ + + The file is read only. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/activation_thld +Date: February 2021 +Contact: Avri Altman <avri.altman@wdc.com> +Description: In host control mode, reads are the major source of activation + trials. Once this threshold hs met, the region is added to the + "to-be-activated" list. Since we reset the read counter upon + write, this include sending a rb command updating the region + ppn as well. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/normalization_factor +Date: February 2021 +Contact: Avri Altman <avri.altman@wdc.com> +Description: In host control mode, we think of the regions as "buckets". + Those buckets are being filled with reads, and emptied on write. + We use entries_per_srgn - the amount of blocks in a subregion as + our bucket size. This applies because HPB1.0 only handles + single-block reads. Once the bucket size is crossed, we trigger + a normalization work - not only to avoid overflow, but mainly + because we want to keep those counters normalized, as we are + using those reads as a comparative score, to make various decisions. + The normalization is dividing (shift right) the read counter by + the normalization_factor. If during consecutive normalizations + an active region has exhausted its reads - inactivate it. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_enter +Date: February 2021 +Contact: Avri Altman <avri.altman@wdc.com> +Description: Region deactivation is often due to the fact that eviction took + place: A region becomes active at the expense of another. This is + happening when the max-active-regions limit has been crossed. + In host mode, eviction is considered an extreme measure. We + want to verify that the entering region has enough reads, and + the exiting region has much fewer reads. eviction_thld_enter is + the min reads that a region must have in order to be considered + a candidate for evicting another region. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_exit +Date: February 2021 +Contact: Avri Altman <avri.altman@wdc.com> +Description: Same as above for the exiting region. A region is considered to + be a candidate for eviction only if it has fewer reads than + eviction_thld_exit. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_ms +Date: February 2021 +Contact: Avri Altman <avri.altman@wdc.com> +Description: In order not to hang on to "cold" regions, we inactivate + a region that has no READ access for a predefined amount of + time - read_timeout_ms. If read_timeout_ms has expired, and the + region is dirty, it is less likely that we can make any use of + HPB reading it so we inactivate it. Still, deactivation has + its overhead, and we may still benefit from HPB reading this + region if it is clean - see read_timeout_expiries. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_expiries +Date: February 2021 +Contact: Avri Altman <avri.altman@wdc.com> +Description: If the region read timeout has expired, but the region is clean, + just re-wind its timer for another spin. Do that as long as it + is clean and did not exhaust its read_timeout_expiries threshold. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/timeout_polling_interval_ms +Date: February 2021 +Contact: Avri Altman <avri.altman@wdc.com> +Description: The frequency with which the delayed worker that checks the + read_timeouts is awakened. + +What: /sys/class/scsi_device/*/device/hpb_param_sysfs/inflight_map_req +Date: February 2021 +Contact: Avri Altman <avri.altman@wdc.com> +Description: In host control mode the host is the originator of map requests. + To avoid flooding the device with map requests, use a simple throttling + mechanism that limits the number of inflight map requests. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index ef4b9218ae1e..f627e705e663 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -41,8 +41,7 @@ Description: This parameter controls the number of prefree segments to be What: /sys/fs/f2fs/<disk>/main_blkaddr Date: November 2019 Contact: "Ramon Pantin" <pantin@google.com> -Description: - Shows first block address of MAIN area. +Description: Shows first block address of MAIN area. What: /sys/fs/f2fs/<disk>/ipu_policy Date: November 2013 @@ -493,3 +492,23 @@ Contact: "Chao Yu" <yuchao0@huawei.com> Description: When ATGC is on, it controls age threshold to bypass GCing young candidates whose age is not beyond the threshold, by default it was initialized as 604800 seconds (equals to 7 days). + +What: /sys/fs/f2fs/<disk>/gc_reclaimed_segments +Date: July 2021 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: Show how many segments have been reclaimed by GC during a specific + GC mode (0: GC normal, 1: GC idle CB, 2: GC idle greedy, + 3: GC idle AT, 4: GC urgent high, 5: GC urgent low) + You can re-initialize this value to "0". + +What: /sys/fs/f2fs/<disk>/gc_segment_mode +Date: July 2021 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: You can control for which gc mode the "gc_reclaimed_segments" node shows. + Refer to the description of the modes in "gc_reclaimed_segments". + +What: /sys/fs/f2fs/<disk>/seq_file_ra_mul +Date: July 2021 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: You can control the multiplier value of bdi device readahead window size + between 2 (default) and 256 for POSIX_FADV_SEQUENTIAL advise option. diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers new file mode 100644 index 000000000000..5d3bc997dc64 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers @@ -0,0 +1,24 @@ +What: /sys/kernel/dmabuf/buffers +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju <hridya@google.com> +Description: The /sys/kernel/dmabuf/buffers directory contains a + snapshot of the internal state of every DMA-BUF. + /sys/kernel/dmabuf/buffers/<inode_number> will contain the + statistics for the DMA-BUF with the unique inode number + <inode_number> +Users: kernel memory tuning/debugging tools + +What: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju <hridya@google.com> +Description: This file is read-only and contains the name of the exporter of + the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/size +Date: May 2021 +KernelVersion: v5.13 +Contact: Hridya Valsaraju <hridya@google.com> +Description: This file is read-only and specifies the size of the DMA-BUF in + bytes. diff --git a/Documentation/ABI/testing/sysfs-kernel-iommu_groups b/Documentation/ABI/testing/sysfs-kernel-iommu_groups index eae2f1c1e11e..b15af6a5bc08 100644 --- a/Documentation/ABI/testing/sysfs-kernel-iommu_groups +++ b/Documentation/ABI/testing/sysfs-kernel-iommu_groups @@ -42,8 +42,12 @@ Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default ======== ====================================================== DMA All the DMA transactions from the device in this group are translated by the iommu. + DMA-FQ As above, but using batched invalidation to lazily + remove translations after use. This may offer reduced + overhead at the cost of reduced memory protection. identity All the DMA transactions from the device in this group - are not translated by the iommu. + are not translated by the iommu. Maximum performance + but zero protection. auto Change to the type the device was booted with. ======== ====================================================== diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-numa b/Documentation/ABI/testing/sysfs-kernel-mm-numa new file mode 100644 index 000000000000..77e559d4ed80 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-mm-numa @@ -0,0 +1,24 @@ +What: /sys/kernel/mm/numa/ +Date: June 2021 +Contact: Linux memory management mailing list <linux-mm@kvack.org> +Description: Interface for NUMA + +What: /sys/kernel/mm/numa/demotion_enabled +Date: June 2021 +Contact: Linux memory management mailing list <linux-mm@kvack.org> +Description: Enable/disable demoting pages during reclaim + + Page migration during reclaim is intended for systems + with tiered memory configurations. These systems have + multiple types of memory with varied performance + characteristics instead of plain NUMA systems where + the same kind of memory is found at varied distances. + Allowing page migration during reclaim enables these + systems to migrate pages from fast tiers to slow tiers + when the fast tier is under pressure. This migration + is performed before swap. It may move data to a NUMA + node that does not fall into the cpuset of the + allocating process which might be construed to violate + the guarantees of cpusets. This should not be enabled + on systems which need strict cpuset location + guarantees. diff --git a/Documentation/ABI/testing/sysfs-platform-dell-smbios b/Documentation/ABI/testing/sysfs-platform-dell-smbios index e6e0f7f834a7..5583da581025 100644 --- a/Documentation/ABI/testing/sysfs-platform-dell-smbios +++ b/Documentation/ABI/testing/sysfs-platform-dell-smbios @@ -1,7 +1,7 @@ What: /sys/devices/platform/<platform>/tokens/* Date: November 2017 KernelVersion: 4.15 -Contact: "Mario Limonciello" <mario.limonciello@dell.com> +Contact: Dell.Client.Kernel@dell.com Description: A read-only description of Dell platform tokens available on the machine. diff --git a/Documentation/ABI/testing/sysfs-platform-dptf b/Documentation/ABI/testing/sysfs-platform-dptf index 141834342a4d..53c6b1000320 100644 --- a/Documentation/ABI/testing/sysfs-platform-dptf +++ b/Documentation/ABI/testing/sysfs-platform-dptf @@ -111,3 +111,43 @@ Contact: linux-acpi@vger.kernel.org Description: (RW) The PCH FIVR (Fully Integrated Voltage Regulator) switching frequency in MHz, when FIVR clock is 38.4MHz. + +What: /sys/bus/platform/devices/INTC1045:00/pch_fivr_switch_frequency/fivr_switching_freq_mhz +Date: September, 2021 +KernelVersion: v5.15 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) Get the FIVR switching control frequency in MHz. + +What: /sys/bus/platform/devices/INTC1045:00/pch_fivr_switch_frequency/fivr_switching_fault_status +Date: September, 2021 +KernelVersion: v5.15 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) Read the FIVR switching frequency control fault status. + +What: /sys/bus/platform/devices/INTC1045:00/pch_fivr_switch_frequency/ssc_clock_info +Date: September, 2021 +KernelVersion: v5.15 +Contact: linux-acpi@vger.kernel.org +Description: + (RO) Presents SSC (spread spectrum clock) information for EMI + (Electro magnetic interference) control. This is a bit mask. + Bits Description + [7:0] Sets clock spectrum spread percentage: + 0x00=0.2% , 0x3F=10% + 1 LSB = 0.1% increase in spread (for + settings 0x01 thru 0x1C) + 1 LSB = 0.2% increase in spread (for + settings 0x1E thru 0x3F) + [8] When set to 1, enables spread + spectrum clock + [9] 0: Triangle mode. FFC frequency + walks around the Fcenter in a linear + fashion + 1: Random walk mode. FFC frequency + changes randomly within the SSC + (Spread spectrum clock) range + [10] 0: No white noise. 1: Add white noise + to spread waveform + [11] When 1, future writes are ignored. diff --git a/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt b/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt index e19144fd5d86..fd3a7ec79760 100644 --- a/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt +++ b/Documentation/ABI/testing/sysfs-platform-intel-wmi-thunderbolt @@ -1,7 +1,7 @@ What: /sys/devices/platform/<platform>/force_power Date: September 2017 KernelVersion: 4.15 -Contact: "Mario Limonciello" <mario.limonciello@dell.com> +Contact: "Mario Limonciello" <mario.limonciello@outlook.com> Description: Modify the platform force power state, influencing Thunderbolt controllers to turn on or off when no diff --git a/Documentation/ABI/testing/sysfs-platform_profile b/Documentation/ABI/testing/sysfs-platform_profile index dae9c8941905..baf1d125f9f8 100644 --- a/Documentation/ABI/testing/sysfs-platform_profile +++ b/Documentation/ABI/testing/sysfs-platform_profile @@ -26,3 +26,10 @@ Contact: Hans de Goede <hdegoede@redhat.com> Description: Reading this file gives the current selected profile for this device. Writing this file with one of the strings from platform_profile_choices changes the profile to the new value. + + This file can be monitored for changes by polling for POLLPRI, + POLLPRI will be signalled on any changes, independent of those + changes coming from a userspace write; or coming from another + source such as e.g. a hotkey triggered profile change handled + either directly by the embedded-controller or fully handled + inside the kernel. diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index 51c0f578bfce..90ec4987074b 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -295,7 +295,7 @@ Description: What: /sys/power/resume_offset Date: April 2018 -Contact: Mario Limonciello <mario.limonciello@dell.com> +Contact: Mario Limonciello <mario.limonciello@outlook.com> Description: This file is used for telling the kernel an offset into a disk to use when hibernating the system such as with a swap file. diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp index 2363ad810ddb..d378f57c1b73 100644 --- a/Documentation/ABI/testing/sysfs-ptp +++ b/Documentation/ABI/testing/sysfs-ptp @@ -33,6 +33,13 @@ Description: frequency adjustment value (a positive integer) in parts per billion. +What: /sys/class/ptp/ptpN/max_vclocks +Date: May 2021 +Contact: Yangbo Lu <yangbo.lu@nxp.com> +Description: + This file contains the maximum number of ptp vclocks. + Write integer to re-configure it. + What: /sys/class/ptp/ptpN/n_alarms Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> @@ -61,6 +68,19 @@ Description: This file contains the number of programmable pins offered by the PTP hardware clock. +What: /sys/class/ptp/ptpN/n_vclocks +Date: May 2021 +Contact: Yangbo Lu <yangbo.lu@nxp.com> +Description: + This file contains the number of virtual PTP clocks in + use. By default, the value is 0 meaning that only the + physical clock is in use. Setting the value creates + the corresponding number of virtual clocks and causes + the physical clock to become free running. Setting the + value back to 0 deletes the virtual clocks and + switches the physical clock back to normal, adjustable + operation. + What: /sys/class/ptp/ptpN/pins Date: March 2014 Contact: Richard Cochran <richardcochran@gmail.com> diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst index db609b97ad58..fb73345cfb8a 100644 --- a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst +++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst @@ -43,6 +43,7 @@ entries corresponding to EPF driver will be created by the EPF core. .. <EPF Driver1>/ ... <EPF Device 11>/ ... <EPF Device 21>/ + ... <EPF Device 31>/ .. <EPF Driver2>/ ... <EPF Device 12>/ ... <EPF Device 22>/ @@ -68,6 +69,7 @@ created) ... subsys_vendor_id ... subsys_id ... interrupt_pin + ... <Symlink EPF Device 31>/ ... primary/ ... <Symlink EPC Device1>/ ... secondary/ @@ -79,6 +81,13 @@ interface should be added in 'primary' directory and symlink of endpoint controller connected to secondary interface should be added in 'secondary' directory. +The <EPF Device> directory can have a list of symbolic links +(<Symlink EPF Device 31>) to other <EPF Device>. These symbolic links should +be created by the user to represent the virtual functions that are bound to +the physical function. In the above directory structure <EPF Device 11> is a +physical function and <EPF Device 31> is a virtual function. An EPF device once +it's linked to another EPF device, cannot be linked to a EPC device. + EPC Device ========== @@ -98,7 +107,8 @@ entries corresponding to EPC device will be created by the EPC core. The <EPC Device> directory will have a list of symbolic links to <EPF Device>. These symbolic links should be created by the user to -represent the functions present in the endpoint device. +represent the functions present in the endpoint device. Only <EPF Device> +that represents a physical function can be linked to a EPC device. The <EPC Device> directory will also have a *start* field. Once "1" is written to this field, the endpoint device will be ready to diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index fa651e25d98c..87c6f4a6ca32 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -103,6 +103,7 @@ need pass only as many optional fields as necessary: - subvendor and subdevice fields default to PCI_ANY_ID (FFFFFFFF) - class and classmask fields default to 0 - driver_data defaults to 0UL. + - override_only field defaults to 0. Note that driver_data must match the value used by any of the pci_device_id entries defined in the driver. This makes the driver_data field mandatory diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index 11cdab037bff..eeb351296df1 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -112,6 +112,35 @@ on PowerPC. The ``smp_mb__after_unlock_lock()`` invocations prevent this ``WARN_ON()`` from triggering. ++-----------------------------------------------------------------------+ +| **Quick Quiz**: | ++-----------------------------------------------------------------------+ +| But the chain of rcu_node-structure lock acquisitions guarantees | +| that new readers will see all of the updater's pre-grace-period | +| accesses and also guarantees that the updater's post-grace-period | +| accesses will see all of the old reader's accesses. So why do we | +| need all of those calls to smp_mb__after_unlock_lock()? | ++-----------------------------------------------------------------------+ +| **Answer**: | ++-----------------------------------------------------------------------+ +| Because we must provide ordering for RCU's polling grace-period | +| primitives, for example, get_state_synchronize_rcu() and | +| poll_state_synchronize_rcu(). Consider this code:: | +| | +| CPU 0 CPU 1 | +| ---- ---- | +| WRITE_ONCE(X, 1) WRITE_ONCE(Y, 1) | +| g = get_state_synchronize_rcu() smp_mb() | +| while (!poll_state_synchronize_rcu(g)) r1 = READ_ONCE(X) | +| continue; | +| r0 = READ_ONCE(Y) | +| | +| RCU guarantees that the outcome r0 == 0 && r1 == 0 will not | +| happen, even if CPU 1 is in an RCU extended quiescent state | +| (idle or offline) and thus won't interact directly with the RCU | +| core processing at all. | ++-----------------------------------------------------------------------+ + This approach must be extended to include idle CPUs, which need RCU's grace-period memory ordering guarantee to extend to any RCU read-side critical sections preceding and following the current diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 38a39476fc24..45278e2974c0 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -362,9 +362,8 @@ do_something_gp() uses rcu_dereference() to fetch from ``gp``: 12 } The rcu_dereference() uses volatile casts and (for DEC Alpha) memory -barriers in the Linux kernel. Should a `high-quality implementation of -C11 ``memory_order_consume`` -[PDF] <http://www.rdrop.com/users/paulmck/RCU/consume.2015.07.13a.pdf>`__ +barriers in the Linux kernel. Should a |high-quality implementation of +C11 memory_order_consume [PDF]|_ ever appear, then rcu_dereference() could be implemented as a ``memory_order_consume`` load. Regardless of the exact implementation, a pointer fetched by rcu_dereference() may not be used outside of the @@ -374,6 +373,9 @@ element has been passed from RCU to some other synchronization mechanism, most commonly locking or `reference counting <https://www.kernel.org/doc/Documentation/RCU/rcuref.txt>`__. +.. |high-quality implementation of C11 memory_order_consume [PDF]| replace:: high-quality implementation of C11 ``memory_order_consume`` [PDF] +.. _high-quality implementation of C11 memory_order_consume [PDF]: http://www.rdrop.com/users/paulmck/RCU/consume.2015.07.13a.pdf + In short, updaters use rcu_assign_pointer() and readers use rcu_dereference(), and these two RCU API elements work together to ensure that readers have a consistent view of newly added data elements. diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 01cc21f17f7b..f4545b7c9a63 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -37,7 +37,7 @@ over a rather long period of time, but improvements are always welcome! 1. Does the update code have proper mutual exclusion? - RCU does allow -readers- to run (almost) naked, but -writers- must + RCU does allow *readers* to run (almost) naked, but *writers* must still use some sort of mutual exclusion, such as: a. locking, @@ -73,7 +73,7 @@ over a rather long period of time, but improvements are always welcome! critical section is every bit as bad as letting them leak out from under a lock. Unless, of course, you have arranged some other means of protection, such as a lock or a reference count - -before- letting them out of the RCU read-side critical section. + *before* letting them out of the RCU read-side critical section. 3. Does the update code tolerate concurrent accesses? @@ -101,7 +101,7 @@ over a rather long period of time, but improvements are always welcome! c. Make updates appear atomic to readers. For example, pointer updates to properly aligned fields will appear atomic, as will individual atomic primitives. - Sequences of operations performed under a lock will -not- + Sequences of operations performed under a lock will *not* appear to be atomic to RCU readers, nor will sequences of multiple atomic primitives. @@ -333,7 +333,7 @@ over a rather long period of time, but improvements are always welcome! for example) may be omitted. 10. Conversely, if you are in an RCU read-side critical section, - and you don't hold the appropriate update-side lock, you -must- + and you don't hold the appropriate update-side lock, you *must* use the "_rcu()" variants of the list macros. Failing to do so will break Alpha, cause aggressive compilers to generate bad code, and confuse people trying to read your code. @@ -359,12 +359,12 @@ over a rather long period of time, but improvements are always welcome! callback pending, then that RCU callback will execute on some surviving CPU. (If this was not the case, a self-spawning RCU callback would prevent the victim CPU from ever going offline.) - Furthermore, CPUs designated by rcu_nocbs= might well -always- + Furthermore, CPUs designated by rcu_nocbs= might well *always* have their RCU callbacks executed on some other CPUs, in fact, for some real-time workloads, this is the whole point of using the rcu_nocbs= kernel boot parameter. -13. Unlike other forms of RCU, it -is- permissible to block in an +13. Unlike other forms of RCU, it *is* permissible to block in an SRCU read-side critical section (demarked by srcu_read_lock() and srcu_read_unlock()), hence the "SRCU": "sleepable RCU". Please note that if you don't need to sleep in read-side critical @@ -411,16 +411,16 @@ over a rather long period of time, but improvements are always welcome! 14. The whole point of call_rcu(), synchronize_rcu(), and friends is to wait until all pre-existing readers have finished before carrying out some otherwise-destructive operation. It is - therefore critically important to -first- remove any path + therefore critically important to *first* remove any path that readers can follow that could be affected by the - destructive operation, and -only- -then- invoke call_rcu(), + destructive operation, and *only then* invoke call_rcu(), synchronize_rcu(), or friends. Because these primitives only wait for pre-existing readers, it is the caller's responsibility to guarantee that any subsequent readers will execute safely. -15. The various RCU read-side primitives do -not- necessarily contain +15. The various RCU read-side primitives do *not* necessarily contain memory barriers. You should therefore plan for the CPU and the compiler to freely reorder code into and out of RCU read-side critical sections. It is the responsibility of the @@ -459,8 +459,8 @@ over a rather long period of time, but improvements are always welcome! pass in a function defined within a loadable module, then it in necessary to wait for all pending callbacks to be invoked after the last invocation and before unloading that module. Note that - it is absolutely -not- sufficient to wait for a grace period! - The current (say) synchronize_rcu() implementation is -not- + it is absolutely *not* sufficient to wait for a grace period! + The current (say) synchronize_rcu() implementation is *not* guaranteed to wait for callbacks registered on other CPUs. Or even on the current CPU if that CPU recently went offline and came back online. @@ -470,7 +470,7 @@ over a rather long period of time, but improvements are always welcome! - call_rcu() -> rcu_barrier() - call_srcu() -> srcu_barrier() - However, these barrier functions are absolutely -not- guaranteed + However, these barrier functions are absolutely *not* guaranteed to wait for a grace period. In fact, if there are no call_rcu() callbacks waiting anywhere in the system, rcu_barrier() is within its rights to return immediately. diff --git a/Documentation/RCU/rcu_dereference.rst b/Documentation/RCU/rcu_dereference.rst index f3e587acb4de..0b418a5b243c 100644 --- a/Documentation/RCU/rcu_dereference.rst +++ b/Documentation/RCU/rcu_dereference.rst @@ -43,7 +43,7 @@ Follow these rules to keep your RCU code working properly: - Set bits and clear bits down in the must-be-zero low-order bits of that pointer. This clearly means that the pointer must have alignment constraints, for example, this does - -not- work in general for char* pointers. + *not* work in general for char* pointers. - XOR bits to translate pointers, as is done in some classic buddy-allocator algorithms. @@ -174,7 +174,7 @@ Follow these rules to keep your RCU code working properly: Please see the "CONTROL DEPENDENCIES" section of Documentation/memory-barriers.txt for more details. - - The pointers are not equal -and- the compiler does + - The pointers are not equal *and* the compiler does not have enough information to deduce the value of the pointer. Note that the volatile cast in rcu_dereference() will normally prevent the compiler from knowing too much. @@ -360,7 +360,7 @@ in turn destroying the ordering between this load and the loads of the return values. This can result in "p->b" returning pre-initialization garbage values. -In short, rcu_dereference() is -not- optional when you are going to +In short, rcu_dereference() is *not* optional when you are going to dereference the resulting pointer. diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst index 7148e9be08c3..5036df24ae61 100644 --- a/Documentation/RCU/stallwarn.rst +++ b/Documentation/RCU/stallwarn.rst @@ -32,7 +32,7 @@ warnings: - Booting Linux using a console connection that is too slow to keep up with the boot-time console-message rate. For example, - a 115Kbaud serial console can be -way- too slow to keep up + a 115Kbaud serial console can be *way* too slow to keep up with boot-time message rates, and will frequently result in RCU CPU stall warning messages. Especially if you have added debug printk()s. @@ -105,7 +105,7 @@ warnings: leading the realization that the CPU had failed. The RCU, RCU-sched, and RCU-tasks implementations have CPU stall warning. -Note that SRCU does -not- have CPU stall warnings. Please note that +Note that SRCU does *not* have CPU stall warnings. Please note that RCU only detects CPU stalls when there is a grace period in progress. No grace period, no CPU stall warnings. @@ -145,7 +145,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT this parameter is checked only at the beginning of a cycle. So if you are 10 seconds into a 40-second stall, setting this sysfs parameter to (say) five will shorten the timeout for the - -next- stall, or the following warning for the current stall + *next* stall, or the following warning for the current stall (assuming the stall lasts long enough). It will not affect the timing of the next warning for the current stall. @@ -189,8 +189,8 @@ rcupdate.rcu_task_stall_timeout Interpreting RCU's CPU Stall-Detector "Splats" ============================================== -For non-RCU-tasks flavors of RCU, when a CPU detects that it is stalling, -it will print a message similar to the following:: +For non-RCU-tasks flavors of RCU, when a CPU detects that some other +CPU is stalling, it will print a message similar to the following:: INFO: rcu_sched detected stalls on CPUs/tasks: 2-...: (3 GPs behind) idle=06c/0/0 softirq=1453/1455 fqs=0 @@ -202,8 +202,10 @@ causing stalls, and that the stall was affecting RCU-sched. This message will normally be followed by stack dumps for each CPU. Please note that PREEMPT_RCU builds can be stalled by tasks as well as by CPUs, and that the tasks will be indicated by PID, for example, "P3421". It is even -possible for an rcu_state stall to be caused by both CPUs -and- tasks, +possible for an rcu_state stall to be caused by both CPUs *and* tasks, in which case the offending CPUs and tasks will all be called out in the list. +In some cases, CPUs will detect themselves stalling, which will result +in a self-detected stall. CPU 2's "(3 GPs behind)" indicates that this CPU has not interacted with the RCU core for the past three grace periods. In contrast, CPU 16's "(0 @@ -224,7 +226,7 @@ is the number that had executed since boot at the time that this CPU last noted the beginning of a grace period, which might be the current (stalled) grace period, or it might be some earlier grace period (for example, if the CPU might have been in dyntick-idle mode for an extended -time period. The number after the "/" is the number that have executed +time period). The number after the "/" is the number that have executed since boot until the current time. If this latter number stays constant across repeated stall-warning messages, it is possible that RCU's softirq handlers are no longer able to execute on this CPU. This can happen if @@ -283,7 +285,8 @@ If the relevant grace-period kthread has been unable to run prior to the stall warning, as was the case in the "All QSes seen" line above, the following additional line is printed:: - kthread starved for 23807 jiffies! g7075 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 ->cpu=5 + rcu_sched kthread starved for 23807 jiffies! g7075 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 ->cpu=5 + Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior. Starving the grace-period kthreads of CPU time can of course result in RCU CPU stall warnings even when all CPUs and tasks have passed @@ -313,15 +316,21 @@ is the current ``TIMER_SOFTIRQ`` count on cpu 4. If this value does not change on successive RCU CPU stall warnings, there is further reason to suspect a timer problem. +These messages are usually followed by stack dumps of the CPUs and tasks +involved in the stall. These stack traces can help you locate the cause +of the stall, keeping in mind that the CPU detecting the stall will have +an interrupt frame that is mainly devoted to detecting the stall. + Multiple Warnings From One Stall ================================ -If a stall lasts long enough, multiple stall-warning messages will be -printed for it. The second and subsequent messages are printed at +If a stall lasts long enough, multiple stall-warning messages will +be printed for it. The second and subsequent messages are printed at longer intervals, so that the time between (say) the first and second message will be about three times the interval between the beginning -of the stall and the first message. +of the stall and the first message. It can be helpful to compare the +stack dumps for the different messages for the same stalled grace period. Stall Warnings for Expedited Grace Periods diff --git a/Documentation/admin-guide/binderfs.rst b/Documentation/admin-guide/binderfs.rst index 199d84314a14..41a4db00df8d 100644 --- a/Documentation/admin-guide/binderfs.rst +++ b/Documentation/admin-guide/binderfs.rst @@ -72,3 +72,16 @@ that the `rm() <rm_>`_ tool can be used to delete them. Note that the ``binder-control`` device cannot be deleted since this would make the binderfs instance unusable. The ``binder-control`` device will be deleted when the binderfs instance is unmounted and all references to it have been dropped. + +Binder features +--------------- + +Assuming an instance of binderfs has been mounted at ``/dev/binderfs``, the +features supported by the binder driver can be located under +``/dev/binderfs/features/``. The presence of individual files can be tested +to determine whether a particular feature is supported by the driver. + +Example:: + + cat /dev/binderfs/features/oneway_spam_detection + 1 diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 5c7377b5bd3e..babbe04c8d37 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -2056,6 +2056,17 @@ Cpuset Interface Files The value of "cpuset.mems" stays constant until the next update and won't be affected by any memory nodes hotplug events. + Setting a non-empty value to "cpuset.mems" causes memory of + tasks within the cgroup to be migrated to the designated nodes if + they are currently using memory outside of the designated nodes. + + There is a cost for this memory migration. The migration + may not be complete and some memory pages may be left behind. + So it is recommended that "cpuset.mems" should be set properly + before spawning new tasks into the cpuset. Even if there is + a need to change "cpuset.mems" with active tasks, it shouldn't + be done frequently. + cpuset.mems.effective A read-only multiple values file which exists on all cpuset-enabled cgroups. diff --git a/Documentation/admin-guide/device-mapper/dm-ima.rst b/Documentation/admin-guide/device-mapper/dm-ima.rst new file mode 100644 index 000000000000..a4aa50a828e0 --- /dev/null +++ b/Documentation/admin-guide/device-mapper/dm-ima.rst @@ -0,0 +1,715 @@ +====== +dm-ima +====== + +For a given system, various external services/infrastructure tools +(including the attestation service) interact with it - both during the +setup and during rest of the system run-time. They share sensitive data +and/or execute critical workload on that system. The external services +may want to verify the current run-time state of the relevant kernel +subsystems before fully trusting the system with business-critical +data/workload. + +Device mapper plays a critical role on a given system by providing +various important functionalities to the block devices using various +target types like crypt, verity, integrity etc. Each of these target +types’ functionalities can be configured with various attributes. +The attributes chosen to configure these target types can significantly +impact the security profile of the block device, and in-turn, of the +system itself. For instance, the type of encryption algorithm and the +key size determines the strength of encryption for a given block device. + +Therefore, verifying the current state of various block devices as well +as their various target attributes is crucial for external services before +fully trusting the system with business-critical data/workload. + +IMA kernel subsystem provides the necessary functionality for +device mapper to measure the state and configuration of +various block devices - + +- by device mapper itself, from within the kernel, +- in a tamper resistant way, +- and re-measured - triggered on state/configuration change. + +Setting the IMA Policy: +======================= +For IMA to measure the data on a given system, the IMA policy on the +system needs to be updated to have following line, and the system needs +to be restarted for the measurements to take effect. + +:: + + /etc/ima/ima-policy + measure func=CRITICAL_DATA label=device-mapper template=ima-buf + +The measurements will be reflected in the IMA logs, which are located at: + +:: + + /sys/kernel/security/integrity/ima/ascii_runtime_measurements + /sys/kernel/security/integrity/ima/binary_runtime_measurements + +Then IMA ASCII measurement log has the following format: + +:: + + <PCR> <TEMPLATE_DATA_DIGEST> <TEMPLATE_NAME> <TEMPLATE_DATA> + + PCR := Platform Configuration Register, in which the values are registered. + This is applicable if TPM chip is in use. + + TEMPLATE_DATA_DIGEST := Template data digest of the IMA record. + TEMPLATE_NAME := Template name that registered the integrity value (e.g. ima-buf). + + TEMPLATE_DATA := <ALG> ":" <EVENT_DIGEST> <EVENT_NAME> <EVENT_DATA> + It contains data for the specific event to be measured, + in a given template data format. + + ALG := Algorithm to compute event digest + EVENT_DIGEST := Digest of the event data + EVENT_NAME := Description of the event (e.g. 'dm_table_load'). + EVENT_DATA := The event data to be measured. + +| + +| *NOTE #1:* +| The DM target data measured by IMA subsystem can alternatively + be queried from userspace by setting DM_IMA_MEASUREMENT_FLAG with + DM_TABLE_STATUS_CMD. + +| + +| *NOTE #2:* +| The Kernel configuration CONFIG_IMA_DISABLE_HTABLE allows measurement of duplicate records. +| To support recording duplicate IMA events in the IMA log, the Kernel needs to be configured with + CONFIG_IMA_DISABLE_HTABLE=y. + +Supported Device States: +======================== +Following device state changes will trigger IMA measurements: + + 1. Table load + #. Device resume + #. Device remove + #. Table clear + #. Device rename + +1. Table load: +--------------- +When a new table is loaded in a device's inactive table slot, +the device information and target specific details from the +targets in the table are measured. + +The IMA measurement log has the following format for 'dm_table_load': + +:: + + EVENT_NAME := "dm_table_load" + EVENT_DATA := <dm_version_str> ";" <device_metadata> ";" <table_load_data> + + dm_version_str := "dm_version=" <N> "." <N> "." <N> + Same as Device Mapper driver version. + device_metadata := <device_name> "," <device_uuid> "," <device_major> "," <device_minor> "," + <minor_count> "," <num_device_targets> ";" + + device_name := "name=" <dm-device-name> + device_uuid := "uuid=" <dm-device-uuid> + device_major := "major=" <N> + device_minor := "minor=" <N> + minor_count := "minor_count=" <N> + num_device_targets := "num_targets=" <N> + dm-device-name := Name of the device. If it contains special characters like '\', ',', ';', + they are prefixed with '\'. + dm-device-uuid := UUID of the device. If it contains special characters like '\', ',', ';', + they are prefixed with '\'. + + table_load_data := <target_data> + Represents the data (as name=value pairs) from various targets in the table, + which is being loaded into the DM device's inactive table slot. + target_data := <target_data_row> | <target_data><target_data_row> + + target_data_row := <target_index> "," <target_begin> "," <target_len> "," <target_name> "," + <target_version> "," <target_attributes> ";" + target_index := "target_index=" <N> + Represents nth target in the table (from 0 to N-1 targets specified in <num_device_targets>) + If all the data for N targets doesn't fit in the given buffer - then the data that fits + in the buffer (say from target 0 to x) is measured in a given IMA event. + The remaining data from targets x+1 to N-1 is measured in the subsequent IMA events, + with the same format as that of 'dm_table_load' + i.e. <dm_version_str> ";" <device_metadata> ";" <table_load_data>. + + target_begin := "target_begin=" <N> + target_len := "target_len=" <N> + target_name := Name of the target. 'linear', 'crypt', 'integrity' etc. + The targets that are supported for IMA measurements are documented below in the + 'Supported targets' section. + target_version := "target_version=" <N> "." <N> "." <N> + target_attributes := Data containing comma separated list of name=value pairs of target specific attributes. + + For instance, if a linear device is created with the following table entries, + # dmsetup create linear1 + 0 2 linear /dev/loop0 512 + 2 2 linear /dev/loop0 512 + 4 2 linear /dev/loop0 512 + 6 2 linear /dev/loop0 512 + + Then IMA ASCII measurement log will have the following entry: + (converted from ASCII to text for readability) + + 10 a8c5ff755561c7a28146389d1514c318592af49a ima-buf sha256:4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72 + dm_table_load + dm_version=4.45.0; + name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4; + target_index=0,target_begin=0,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; + target_index=1,target_begin=2,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; + target_index=2,target_begin=4,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; + target_index=3,target_begin=6,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512; + +2. Device resume: +------------------ +When a suspended device is resumed, the device information and the hash of the +data from previous load of an active table are measured. + +The IMA measurement log has the following format for 'dm_device_resume': + +:: + + EVENT_NAME := "dm_device_resume" + EVENT_DATA := <dm_version_str> ";" <device_metadata> ";" <active_table_hash> ";" <current_device_capacity> ";" + + dm_version_str := As described in the 'Table load' section above. + device_metadata := As described in the 'Table load' section above. + active_table_hash := "active_table_hash=" <table_hash_alg> ":" <table_hash> + Rerpresents the hash of the IMA data being measured for the + active table for the device. + table_hash_alg := Algorithm used to compute the hash. + table_hash := Hash of the (<dm_version_str> ";" <device_metadata> ";" <table_load_data> ";") + as described in the 'dm_table_load' above. + Note: If the table_load data spans across multiple IMA 'dm_table_load' + events for a given device, the hash is computed combining all the event data + i.e. (<dm_version_str> ";" <device_metadata> ";" <table_load_data> ";") + across all those events. + current_device_capacity := "current_device_capacity=" <N> + + For instance, if a linear device is resumed with the following command, + #dmsetup resume linear1 + + then IMA ASCII measurement log will have an entry with: + (converted from ASCII to text for readability) + + 10 56c00cc062ffc24ccd9ac2d67d194af3282b934e ima-buf sha256:e7d12c03b958b4e0e53e7363a06376be88d98a1ac191fdbd3baf5e4b77f329b6 + dm_device_resume + dm_version=4.45.0; + name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4; + active_table_hash=sha256:4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72;current_device_capacity=8; + +3. Device remove: +------------------ +When a device is removed, the device information and a sha256 hash of the +data from an active and inactive table are measured. + +The IMA measurement log has the following format for 'dm_device_remove': + +:: + + EVENT_NAME := "dm_device_remove" + EVENT_DATA := <dm_version_str> ";" <device_active_metadata> ";" <device_inactive_metadata> ";" + <active_table_hash> "," <inactive_table_hash> "," <remove_all> ";" <current_device_capacity> ";" + + dm_version_str := As described in the 'Table load' section above. + device_active_metadata := Device metadata that reflects the currently loaded active table. + The format is same as 'device_metadata' described in the 'Table load' section above. + device_inactive_metadata := Device metadata that reflects the inactive table. + The format is same as 'device_metadata' described in the 'Table load' section above. + active_table_hash := Hash of the currently loaded active table. + The format is same as 'active_table_hash' described in the 'Device resume' section above. + inactive_table_hash := Hash of the inactive table. + The format is same as 'active_table_hash' described in the 'Device resume' section above. + remove_all := "remove_all=" <yes_no> + yes_no := "y" | "n" + current_device_capacity := "current_device_capacity=" <N> + + For instance, if a linear device is removed with the following command, + #dmsetup remove l1 + + then IMA ASCII measurement log will have the following entry: + (converted from ASCII to text for readability) + + 10 790e830a3a7a31590824ac0642b3b31c2d0e8b38 ima-buf sha256:ab9f3c959367a8f5d4403d6ce9c3627dadfa8f9f0e7ec7899299782388de3840 + dm_device_remove + dm_version=4.45.0; + device_active_metadata=name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=2; + device_inactive_metadata=name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=1; + active_table_hash=sha256:4a7e62efaebfc86af755831998b7db6f59b60d23c9534fb16a4455907957953a, + inactive_table_hash=sha256:9d79c175bc2302d55a183e8f50ad4bafd60f7692fd6249e5fd213e2464384b86,remove_all=n; + current_device_capacity=2048; + +4. Table clear: +---------------- +When an inactive table is cleared from the device, the device information and a sha256 hash of the +data from an inactive table are measured. + +The IMA measurement log has the following format for 'dm_table_clear': + +:: + + EVENT_NAME := "dm_table_clear" + EVENT_DATA := <dm_version_str> ";" <device_inactive_metadata> ";" <inactive_table_hash> ";" <current_device_capacity> ";" + + dm_version_str := As described in the 'Table load' section above. + device_inactive_metadata := Device metadata that was captured during the load time inactive table being cleared. + The format is same as 'device_metadata' described in the 'Table load' section above. + inactive_table_hash := Hash of the inactive table being cleared from the device. + The format is same as 'active_table_hash' described in the 'Device resume' section above. + current_device_capacity := "current_device_capacity=" <N> + + For instance, if a linear device's inactive table is cleared, + #dmsetup clear l1 + + then IMA ASCII measurement log will have an entry with: + (converted from ASCII to text for readability) + + 10 77d347408f557f68f0041acb0072946bb2367fe5 ima-buf sha256:42f9ca22163fdfa548e6229dece2959bc5ce295c681644240035827ada0e1db5 + dm_table_clear + dm_version=4.45.0; + name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=1; + inactive_table_hash=sha256:75c0dc347063bf474d28a9907037eba060bfe39d8847fc0646d75e149045d545;current_device_capacity=1024; + +5. Device rename: +------------------ +When an device's NAME or UUID is changed, the device information and the new NAME and UUID +are measured. + +The IMA measurement log has the following format for 'dm_device_rename': + +:: + + EVENT_NAME := "dm_device_rename" + EVENT_DATA := <dm_version_str> ";" <device_active_metadata> ";" <new_device_name> "," <new_device_uuid> ";" <current_device_capacity> ";" + + dm_version_str := As described in the 'Table load' section above. + device_active_metadata := Device metadata that reflects the currently loaded active table. + The format is same as 'device_metadata' described in the 'Table load' section above. + new_device_name := "new_name=" <dm-device-name> + dm-device-name := Same as <dm-device-name> described in 'Table load' section above + new_device_uuid := "new_uuid=" <dm-device-uuid> + dm-device-uuid := Same as <dm-device-uuid> described in 'Table load' section above + current_device_capacity := "current_device_capacity=" <N> + + E.g 1: if a linear device's name is changed with the following command, + #dmsetup rename linear1 --setuuid 1234-5678 + + then IMA ASCII measurement log will have an entry with: + (converted from ASCII to text for readability) + + 10 8b0423209b4c66ac1523f4c9848c9b51ee332f48 ima-buf sha256:6847b7258134189531db593e9230b257c84f04038b5a18fd2e1473860e0569ac + dm_device_rename + dm_version=4.45.0; + name=linear1,uuid=,major=253,minor=2,minor_count=1,num_targets=1;new_name=linear1,new_uuid=1234-5678; + current_device_capacity=1024; + + E.g 2: if a linear device's name is changed with the following command, + # dmsetup rename linear1 linear=2 + + then IMA ASCII measurement log will have an entry with: + (converted from ASCII to text for readability) + + 10 bef70476b99c2bdf7136fae033aa8627da1bf76f ima-buf sha256:8c6f9f53b9ef9dc8f92a2f2cca8910e622543d0f0d37d484870cb16b95111402 + dm_device_rename + dm_version=4.45.0; + name=linear1,uuid=1234-5678,major=253,minor=2,minor_count=1,num_targets=1; + new_name=linear\=2,new_uuid=1234-5678; + current_device_capacity=1024; + +Supported targets: +================== + +Following targets are supported to measure their data using IMA: + + 1. cache + #. crypt + #. integrity + #. linear + #. mirror + #. multipath + #. raid + #. snapshot + #. striped + #. verity + +1. cache +--------- +The 'target_attributes' (described as part of EVENT_DATA in 'Table load' +section above) has the following data format for 'cache' target. + +:: + + target_attributes := <target_name> "," <target_version> "," <metadata_mode> "," <cache_metadata_device> "," + <cache_device> "," <cache_origin_device> "," <writethrough> "," <writeback> "," + <passthrough> "," <no_discard_passdown> ";" + + target_name := "target_name=cache" + target_version := "target_version=" <N> "." <N> "." <N> + metadata_mode := "metadata_mode=" <cache_metadata_mode> + cache_metadata_mode := "fail" | "ro" | "rw" + cache_device := "cache_device=" <cache_device_name_string> + cache_origin_device := "cache_origin_device=" <cache_origin_device_string> + writethrough := "writethrough=" <yes_no> + writeback := "writeback=" <yes_no> + passthrough := "passthrough=" <yes_no> + no_discard_passdown := "no_discard_passdown=" <yes_no> + yes_no := "y" | "n" + + E.g. + When a 'cache' target is loaded, then IMA ASCII measurement log will have an entry + similar to the following, depicting what 'cache' attributes are measured in EVENT_DATA + for 'dm_table_load' event. + (converted from ASCII to text for readability) + + dm_version=4.45.0;name=cache1,uuid=cache_uuid,major=253,minor=2,minor_count=1,num_targets=1; + target_index=0,target_begin=0,target_len=28672,target_name=cache,target_version=2.2.0,metadata_mode=rw, + cache_metadata_device=253:4,cache_device=253:3,cache_origin_device=253:5,writethrough=y,writeback=n, + passthrough=n,metadata2=y,no_discard_passdown=n; + + +2. crypt +--------- +The 'target_attributes' (described as part of EVENT_DATA in 'Table load' +section above) has the following data format for 'crypt' target. + +:: + + target_attributes := <target_name> "," <target_version> "," <allow_discards> "," <same_cpu_crypt> "," + <submit_from_crypt_cpus> "," <no_read_workqueue> "," <no_write_workqueue> "," + <iv_large_sectors> "," <iv_large_sectors> "," [<integrity_tag_size> ","] [<cipher_auth> ","] + [<sector_size> ","] [<cipher_string> ","] <key_size> "," <key_parts> "," + <key_extra_size> "," <key_mac_size> ";" + + target_name := "target_name=crypt" + target_version := "target_version=" <N> "." <N> "." <N> + allow_discards := "allow_discards=" <yes_no> + same_cpu_crypt := "same_cpu_crypt=" <yes_no> + submit_from_crypt_cpus := "submit_from_crypt_cpus=" <yes_no> + no_read_workqueue := "no_read_workqueue=" <yes_no> + no_write_workqueue := "no_write_workqueue=" <yes_no> + iv_large_sectors := "iv_large_sectors=" <yes_no> + integrity_tag_size := "integrity_tag_size=" <N> + cipher_auth := "cipher_auth=" <string> + sector_size := "sector_size=" <N> + cipher_string := "cipher_string=" + key_size := "key_size=" <N> + key_parts := "key_parts=" <N> + key_extra_size := "key_extra_size=" <N> + key_mac_size := "key_mac_size=" <N> + yes_no := "y" | "n" + + E.g. + When a 'crypt' target is loaded, then IMA ASCII measurement log will have an entry + similar to the following, depicting what 'crypt' attributes are measured in EVENT_DATA + for 'dm_table_load' event. + (converted from ASCII to text for readability) + + dm_version=4.45.0; + name=crypt1,uuid=crypt_uuid1,major=253,minor=0,minor_count=1,num_targets=1; + target_index=0,target_begin=0,target_len=1953125,target_name=crypt,target_version=1.23.0, + allow_discards=y,same_cpu=n,submit_from_crypt_cpus=n,no_read_workqueue=n,no_write_workqueue=n, + iv_large_sectors=n,cipher_string=aes-xts-plain64,key_size=32,key_parts=1,key_extra_size=0,key_mac_size=0; + +3. integrity +------------- +The 'target_attributes' (described as part of EVENT_DATA in 'Table load' +section above) has the following data format for 'integrity' target. + +:: + + target_attributes := <target_name> "," <target_version> "," <dev_name> "," <start> + <tag_size> "," <mode> "," [<meta_device> ","] [<block_size> ","] <recalculate> "," + <allow_discards> "," <fix_padding> "," <fix_hmac> "," <legacy_recalculate> "," + <journal_sectors> "," <interleave_sectors> "," <buffer_sectors> ";" + + target_name := "target_name=integrity" + target_version := "target_version=" <N> "." <N> "." <N> + dev_name := "dev_name=" <device_name_str> + start := "start=" <N> + tag_size := "tag_size=" <N> + mode := "mode=" <integrity_mode_str> + integrity_mode_str := "J" | "B" | "D" | "R" + meta_device := "meta_device=" <meta_device_str> + block_size := "block_size=" <N> + recalculate := "recalculate=" <yes_no> + allow_discards := "allow_discards=" <yes_no> + fix_padding := "fix_padding=" <yes_no> + fix_hmac := "fix_hmac=" <yes_no> + legacy_recalculate := "legacy_recalculate=" <yes_no> + journal_sectors := "journal_sectors=" <N> + interleave_sectors := "interleave_sectors=" <N> + buffer_sectors := "buffer_sectors=" <N> + yes_no := "y" | "n" + + E.g. + When a 'integrity' target is loaded, then IMA ASCII measurement log will have an entry + similar to the following, depicting what 'integrity' attributes are measured in EVENT_DATA + for 'dm_table_load' event. + (converted from ASCII to text for readability) + + dm_version=4.45.0; + name=integrity1,uuid=,major=253,minor=1,minor_count=1,num_targets=1; + target_index=0,target_begin=0,target_len=7856,target_name=integrity,target_version=1.10.0, + dev_name=253:0,start=0,tag_size=32,mode=J,recalculate=n,allow_discards=n,fix_padding=n, + fix_hmac=n,legacy_recalculate=n,journal_sectors=88,interleave_sectors=32768,buffer_sectors=128; + + +4. linear +---------- +The 'target_attributes' (described as part of EVENT_DATA in 'Table load' +section above) has the following data format for 'linear' target. + +:: + + target_attributes := <target_name> "," <target_version> "," <device_name> <,> <start> ";" + + target_name := "target_name=linear" + target_version := "target_version=" <N> "." <N> "." <N> + device_name := "device_name=" <linear_device_name_str> + start := "start=" <N> + + E.g. + When a 'linear' target is loaded, then IMA ASCII measurement log will have an entry + similar to the following, depicting what 'linear' attributes are measured in EVENT_DATA + for 'dm_table_load' event. + (converted from ASCII to text for readability) + + dm_version=4.45.0; + name=linear1,uuid=linear_uuid1,major=253,minor=2,minor_count=1,num_targets=1; + target_index=0,target_begin=0,target_len=28672,target_name=linear,target_version=1.4.0, + device_name=253:1,start=2048; + +5. mirror +---------- +The 'target_attributes' (described as part of EVENT_DATA in 'Table load' +section above) has the following data format for 'mirror' target. + +:: + + target_attributes := <target_name> "," <target_version> "," <nr_mirrors> "," + <mirror_device_data> "," <handle_errors> "," <keep_log> "," <log_type_status> ";" + + target_name := "target_name=mirror" + target_version := "target_version=" <N> "." <N> "." <N> + nr_mirrors := "nr_mirrors=" <NR> + mirror_device_data := <mirror_device_row> | <mirror_device_data><mirror_device_row> + mirror_device_row is repeated <NR> times - for <NR> described in <nr_mirrors>. + mirror_device_row := <mirror_device_name> "," <mirror_device_status> + mirror_device_name := "mirror_device_" <X> "=" <mirror_device_name_str> + where <X> ranges from 0 to (<NR> -1) - for <NR> described in <nr_mirrors>. + mirror_device_status := "mirror_device_" <X> "_status=" <mirror_device_status_char> + where <X> ranges from 0 to (<NR> -1) - for <NR> described in <nr_mirrors>. + mirror_device_status_char := "A" | "F" | "D" | "S" | "R" | "U" + handle_errors := "handle_errors=" <yes_no> + keep_log := "keep_log=" <yes_no> + log_type_status := "log_type_status=" <log_type_status_str> + yes_no := "y" | "n" + + E.g. + When a 'mirror' target is loaded, then IMA ASCII measurement log will have an entry + similar to the following, depicting what 'mirror' attributes are measured in EVENT_DATA + for 'dm_table_load' event. + (converted from ASCII to text for readability) + + dm_version=4.45.0; + name=mirror1,uuid=mirror_uuid1,major=253,minor=6,minor_count=1,num_targets=1; + target_index=0,target_begin=0,target_len=2048,target_name=mirror,target_version=1.14.0,nr_mirrors=2, + mirror_device_0=253:4,mirror_device_0_status=A, + mirror_device_1=253:5,mirror_device_1_status=A, + handle_errors=y,keep_log=n,log_type_status=; + +6. multipath +------------- +The 'target_attributes' (described as part of EVENT_DATA in 'Table load' +section above) has the following data format for 'multipath' target. + +:: + + target_attributes := <target_name> "," <target_version> "," <nr_priority_groups> + ["," <pg_state> "," <priority_groups> "," <priority_group_paths>] ";" + + target_name := "target_name=multipath" + target_version := "target_version=" <N> "." <N> "." <N> + nr_priority_groups := "nr_priority_groups=" <NPG> + priority_groups := <priority_groups_row>|<priority_groups_row><priority_groups> + priority_groups_row := "pg_state_" <X> "=" <pg_state_str> "," "nr_pgpaths_" <X> "=" <NPGP> "," + "path_selector_name_" <X> "=" <string> "," <priority_group_paths> + where <X> ranges from 0 to (<NPG> -1) - for <NPG> described in <nr_priority_groups>. + pg_state_str := "E" | "A" | "D" + <priority_group_paths> := <priority_group_paths_row> | <priority_group_paths_row><priority_group_paths> + priority_group_paths_row := "path_name_" <X> "_" <Y> "=" <string> "," "is_active_" <X> "_" <Y> "=" <is_active_str> + "fail_count_" <X> "_" <Y> "=" <N> "," "path_selector_status_" <X> "_" <Y> "=" <path_selector_status_str> + where <X> ranges from 0 to (<NPG> -1) - for <NPG> described in <nr_priority_groups>, + and <Y> ranges from 0 to (<NPGP> -1) - for <NPGP> described in <priority_groups_row>. + is_active_str := "A" | "F" + + E.g. + When a 'multipath' target is loaded, then IMA ASCII measurement log will have an entry + similar to the following, depicting what 'multipath' attributes are measured in EVENT_DATA + for 'dm_table_load' event. + (converted from ASCII to text for readability) + + dm_version=4.45.0; + name=mp,uuid=,major=253,minor=0,minor_count=1,num_targets=1; + target_index=0,target_begin=0,target_len=2097152,target_name=multipath,target_version=1.14.0,nr_priority_groups=2, + pg_state_0=E,nr_pgpaths_0=2,path_selector_name_0=queue-length, + path_name_0_0=8:16,is_active_0_0=A,fail_count_0_0=0,path_selector_status_0_0=, + path_name_0_1=8:32,is_active_0_1=A,fail_count_0_1=0,path_selector_status_0_1=, + pg_state_1=E,nr_pgpaths_1=2,path_selector_name_1=queue-length, + path_name_1_0=8:48,is_active_1_0=A,fail_count_1_0=0,path_selector_status_1_0=, + path_name_1_1=8:64,is_active_1_1=A,fail_count_1_1=0,path_selector_status_1_1=; + +7. raid +-------- +The 'target_attributes' (described as part of EVENT_DATA in 'Table load' +section above) has the following data format for 'raid' target. + +:: + + target_attributes := <target_name> "," <target_version> "," <raid_type> "," <raid_disks> "," <raid_state> + <raid_device_status> ["," journal_dev_mode] ";" + + target_name := "target_name=raid" + target_version := "target_version=" <N> "." <N> "." <N> + raid_type := "raid_type=" <raid_type_str> + raid_disks := "raid_disks=" <NRD> + raid_state := "raid_state=" <raid_state_str> + raid_state_str := "frozen" | "reshape" |"resync" | "check" | "repair" | "recover" | "idle" |"undef" + raid_device_status := <raid_device_status_row> | <raid_device_status_row><raid_device_status> + <raid_device_status_row> is repeated <NRD> times - for <NRD> described in <raid_disks>. + raid_device_status_row := "raid_device_" <X> "_status=" <raid_device_status_str> + where <X> ranges from 0 to (<NRD> -1) - for <NRD> described in <raid_disks>. + raid_device_status_str := "A" | "D" | "a" | "-" + journal_dev_mode := "journal_dev_mode=" <journal_dev_mode_str> + journal_dev_mode_str := "writethrough" | "writeback" | "invalid" + + E.g. + When a 'raid' target is loaded, then IMA ASCII measurement log will have an entry + similar to the following, depicting what 'raid' attributes are measured in EVENT_DATA + for 'dm_table_load' event. + (converted from ASCII to text for readability) + + dm_version=4.45.0; + name=raid_LV1,uuid=uuid_raid_LV1,major=253,minor=12,minor_count=1,num_targets=1; + target_index=0,target_begin=0,target_len=2048,target_name=raid,target_version=1.15.1, + raid_type=raid10,raid_disks=4,raid_state=idle, + raid_device_0_status=A, + raid_device_1_status=A, + raid_device_2_status=A, + raid_device_3_status=A; + + +8. snapshot +------------ +The 'target_attributes' (described as part of EVENT_DATA in 'Table load' +section above) has the following data format for 'snapshot' target. + +:: + + target_attributes := <target_name> "," <target_version> "," <snap_origin_name> "," + <snap_cow_name> "," <snap_valid> "," <snap_merge_failed> "," <snapshot_overflowed> ";" + + target_name := "target_name=snapshot" + target_version := "target_version=" <N> "." <N> "." <N> + snap_origin_name := "snap_origin_name=" <string> + snap_cow_name := "snap_cow_name=" <string> + snap_valid := "snap_valid=" <yes_no> + snap_merge_failed := "snap_merge_failed=" <yes_no> + snapshot_overflowed := "snapshot_overflowed=" <yes_no> + yes_no := "y" | "n" + + E.g. + When a 'snapshot' target is loaded, then IMA ASCII measurement log will have an entry + similar to the following, depicting what 'snapshot' attributes are measured in EVENT_DATA + for 'dm_table_load' event. + (converted from ASCII to text for readability) + + dm_version=4.45.0; + name=snap1,uuid=snap_uuid1,major=253,minor=13,minor_count=1,num_targets=1; + target_index=0,target_begin=0,target_len=4096,target_name=snapshot,target_version=1.16.0, + snap_origin_name=253:11,snap_cow_name=253:12,snap_valid=y,snap_merge_failed=n,snapshot_overflowed=n; + +9. striped +----------- +The 'target_attributes' (described as part of EVENT_DATA in 'Table load' +section above) has the following data format for 'striped' target. + +:: + + target_attributes := <target_name> "," <target_version> "," <stripes> "," <chunk_size> "," + <stripe_data> ";" + + target_name := "target_name=striped" + target_version := "target_version=" <N> "." <N> "." <N> + stripes := "stripes=" <NS> + chunk_size := "chunk_size=" <N> + stripe_data := <stripe_data_row>|<stripe_data><stripe_data_row> + stripe_data_row := <stripe_device_name> "," <stripe_physical_start> "," <stripe_status> + stripe_device_name := "stripe_" <X> "_device_name=" <stripe_device_name_str> + where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>. + stripe_physical_start := "stripe_" <X> "_physical_start=" <N> + where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>. + stripe_status := "stripe_" <X> "_status=" <stripe_status_str> + where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>. + stripe_status_str := "D" | "A" + + E.g. + When a 'striped' target is loaded, then IMA ASCII measurement log will have an entry + similar to the following, depicting what 'striped' attributes are measured in EVENT_DATA + for 'dm_table_load' event. + (converted from ASCII to text for readability) + + dm_version=4.45.0; + name=striped1,uuid=striped_uuid1,major=253,minor=5,minor_count=1,num_targets=1; + target_index=0,target_begin=0,target_len=640,target_name=striped,target_version=1.6.0,stripes=2,chunk_size=64, + stripe_0_device_name=253:0,stripe_0_physical_start=2048,stripe_0_status=A, + stripe_1_device_name=253:3,stripe_1_physical_start=2048,stripe_1_status=A; + +10. verity +---------- +The 'target_attributes' (described as part of EVENT_DATA in 'Table load' +section above) has the following data format for 'verity' target. + +:: + + target_attributes := <target_name> "," <target_version> "," <hash_failed> "," <verity_version> "," + <data_device_name> "," <hash_device_name> "," <verity_algorithm> "," <root_digest> "," + <salt> "," <ignore_zero_blocks> "," <check_at_most_once> ["," <root_hash_sig_key_desc>] + ["," <verity_mode>] ";" + + target_name := "target_name=verity" + target_version := "target_version=" <N> "." <N> "." <N> + hash_failed := "hash_failed=" <hash_failed_str> + hash_failed_str := "C" | "V" + verity_version := "verity_version=" <verity_version_str> + data_device_name := "data_device_name=" <data_device_name_str> + hash_device_name := "hash_device_name=" <hash_device_name_str> + verity_algorithm := "verity_algorithm=" <verity_algorithm_str> + root_digest := "root_digest=" <root_digest_str> + salt := "salt=" <salt_str> + salt_str := "-" <verity_salt_str> + ignore_zero_blocks := "ignore_zero_blocks=" <yes_no> + check_at_most_once := "check_at_most_once=" <yes_no> + root_hash_sig_key_desc := "root_hash_sig_key_desc=" + verity_mode := "verity_mode=" <verity_mode_str> + verity_mode_str := "ignore_corruption" | "restart_on_corruption" | "panic_on_corruption" | "invalid" + yes_no := "y" | "n" + + E.g. + When a 'verity' target is loaded, then IMA ASCII measurement log will have an entry + similar to the following, depicting what 'verity' attributes are measured in EVENT_DATA + for 'dm_table_load' event. + (converted from ASCII to text for readability) + + dm_version=4.45.0; + name=test-verity,uuid=,major=253,minor=2,minor_count=1,num_targets=1; + target_index=0,target_begin=0,target_len=1953120,target_name=verity,target_version=1.8.0,hash_failed=V, + verity_version=1,data_device_name=253:1,hash_device_name=253:0,verity_algorithm=sha256, + root_digest=29cb87e60ce7b12b443ba6008266f3e41e93e403d7f298f8e3f316b29ff89c5e, + salt=e48da609055204e89ae53b655ca2216dd983cf3cb829f34f63a297d106d53e2d, + ignore_zero_blocks=n,check_at_most_once=n; diff --git a/Documentation/admin-guide/device-mapper/index.rst b/Documentation/admin-guide/device-mapper/index.rst index 6cf8adc86fa8..cde52cc09645 100644 --- a/Documentation/admin-guide/device-mapper/index.rst +++ b/Documentation/admin-guide/device-mapper/index.rst @@ -13,6 +13,7 @@ Device Mapper dm-dust dm-ebs dm-flakey + dm-ima dm-init dm-integrity dm-io diff --git a/Documentation/admin-guide/device-mapper/writecache.rst b/Documentation/admin-guide/device-mapper/writecache.rst index 65427d8dfca6..10429779a91a 100644 --- a/Documentation/admin-guide/device-mapper/writecache.rst +++ b/Documentation/admin-guide/device-mapper/writecache.rst @@ -78,13 +78,23 @@ Status: 2. the number of blocks 3. the number of free blocks 4. the number of blocks under writeback +5. the number of read requests +6. the number of read requests that hit the cache +7. the number of write requests +8. the number of write requests that hit uncommitted block +9. the number of write requests that hit committed block +10. the number of write requests that bypass the cache +11. the number of write requests that are allocated in the cache +12. the number of write requests that are blocked on the freelist +13. the number of flush requests +14. the number of discard requests Messages: flush - flush the cache device. The message returns successfully + Flush the cache device. The message returns successfully if the cache device was flushed without an error flush_on_suspend - flush the cache device on next suspend. Use this message + Flush the cache device on next suspend. Use this message when you are going to remove the cache device. The proper sequence for removing the cache device is: @@ -98,3 +108,5 @@ Messages: 6. the cache device is now inactive and it can be deleted cleaner See above "cleaner" constructor documentation. + clear_stats + Clear the statistics that are reported on the status line diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt index 9c2be821c225..922c23bb4372 100644 --- a/Documentation/admin-guide/devices.txt +++ b/Documentation/admin-guide/devices.txt @@ -2993,10 +2993,10 @@ 65 = /dev/infiniband/issm1 Second InfiniBand IsSM device ... 127 = /dev/infiniband/issm63 63rd InfiniBand IsSM device - 128 = /dev/infiniband/uverbs0 First InfiniBand verbs device - 129 = /dev/infiniband/uverbs1 Second InfiniBand verbs device + 192 = /dev/infiniband/uverbs0 First InfiniBand verbs device + 193 = /dev/infiniband/uverbs1 Second InfiniBand verbs device ... - 159 = /dev/infiniband/uverbs31 31st InfiniBand verbs device + 223 = /dev/infiniband/uverbs31 31st InfiniBand verbs device 232 char Biometric Devices 0 = /dev/biometric/sensor0/fingerprint first fingerprint sensor on first device diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index f12cda55538b..8cbc711cda93 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -16,3 +16,4 @@ are configurable at compile, boot or run time. multihit.rst special-register-buffer-data-sampling.rst core-scheduling.rst + l1d_flush.rst diff --git a/Documentation/admin-guide/hw-vuln/l1d_flush.rst b/Documentation/admin-guide/hw-vuln/l1d_flush.rst new file mode 100644 index 000000000000..210020bc3f56 --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/l1d_flush.rst @@ -0,0 +1,69 @@ +L1D Flushing +============ + +With an increasing number of vulnerabilities being reported around data +leaks from the Level 1 Data cache (L1D) the kernel provides an opt-in +mechanism to flush the L1D cache on context switch. + +This mechanism can be used to address e.g. CVE-2020-0550. For applications +the mechanism keeps them safe from vulnerabilities, related to leaks +(snooping of) from the L1D cache. + + +Related CVEs +------------ +The following CVEs can be addressed by this +mechanism + + ============= ======================== ================== + CVE-2020-0550 Improper Data Forwarding OS related aspects + ============= ======================== ================== + +Usage Guidelines +---------------- + +Please see document: :ref:`Documentation/userspace-api/spec_ctrl.rst +<set_spec_ctrl>` for details. + +**NOTE**: The feature is disabled by default, applications need to +specifically opt into the feature to enable it. + +Mitigation +---------- + +When PR_SET_L1D_FLUSH is enabled for a task a flush of the L1D cache is +performed when the task is scheduled out and the incoming task belongs to a +different process and therefore to a different address space. + +If the underlying CPU supports L1D flushing in hardware, the hardware +mechanism is used, software fallback for the mitigation, is not supported. + +Mitigation control on the kernel command line +--------------------------------------------- + +The kernel command line allows to control the L1D flush mitigations at boot +time with the option "l1d_flush=". The valid arguments for this option are: + + ============ ============================================================= + on Enables the prctl interface, applications trying to use + the prctl() will fail with an error if l1d_flush is not + enabled + ============ ============================================================= + +By default the mechanism is disabled. + +Limitations +----------- + +The mechanism does not mitigate L1D data leaks between tasks belonging to +different processes which are concurrently executing on sibling threads of +a physical CPU core when SMT is enabled on the system. + +This can be addressed by controlled placement of processes on physical CPU +cores or by disabling SMT. See the relevant chapter in the L1TF mitigation +document: :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst <smt_control>`. + +**NOTE** : The opt-in of a task for L1D flushing works only when the task's +affinity is limited to cores running in non-SMT mode. If a task which +requested L1D flushing is scheduled on a SMT-enabled core the kernel sends +a SIGBUS to the task. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index bdb22006f713..828d11441ebf 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -287,13 +287,21 @@ do not want to use tracing_snapshot_alloc() as it needs to be done where GFP_KERNEL allocations are allowed. + allow_mismatched_32bit_el0 [ARM64] + Allow execve() of 32-bit applications and setting of the + PER_LINUX32 personality on systems where only a strict + subset of the CPUs support 32-bit EL0. When this + parameter is present, the set of CPUs supporting 32-bit + EL0 is indicated by /sys/devices/system/cpu/aarch32_el0 + and hot-unplug operations may be restricted. + + See Documentation/arm64/asymmetric-32bit.rst for more + information. + amd_iommu= [HW,X86-64] Pass parameters to the AMD IOMMU driver in the system. Possible values are: - fullflush - enable flushing of IO/TLB entries when - they are unmapped. Otherwise they are - flushed before they will be reused, which - is a lot of faster + fullflush - Deprecated, equivalent to iommu.strict=1 off - do not initialize any AMD IOMMU found in the system force_isolation - Force device isolation for all @@ -380,6 +388,9 @@ arm64.nopauth [ARM64] Unconditionally disable Pointer Authentication support + arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension + support + ataflop= [HW,M68k] atarimouse= [HW,MOUSE] Atari Mouse @@ -1944,18 +1955,17 @@ this case, gfx device will use physical address for DMA. strict [Default Off] - With this option on every unmap_single operation will - result in a hardware IOTLB flush operation as opposed - to batching them for performance. + Deprecated, equivalent to iommu.strict=1. sp_off [Default Off] By default, super page will be supported if Intel IOMMU has the capability. With this option, super page will not be supported. - sm_on [Default Off] - By default, scalable mode will be disabled even if the - hardware advertises that it has support for the scalable - mode translation. With this option set, scalable mode - will be used on hardware which claims to support it. + sm_on + Enable the Intel IOMMU scalable mode if the hardware + advertises that it has support for the scalable mode + translation. + sm_off + Disallow use of the Intel IOMMU scalable mode. tboot_noforce [Default Off] Do not force the Intel IOMMU enabled under tboot. By default, tboot will force Intel IOMMU on, which @@ -2047,13 +2057,12 @@ throughput at the cost of reduced device isolation. Will fall back to strict mode if not supported by the relevant IOMMU driver. - 1 - Strict mode (default). + 1 - Strict mode. DMA unmap operations invalidate IOMMU hardware TLBs synchronously. - Note: on x86, the default behaviour depends on the - equivalent driver-specific parameters, but a strict - mode explicitly specified by either method takes - precedence. + unset - Use value of CONFIG_IOMMU_DEFAULT_DMA_{LAZY,STRICT}. + Note: on x86, strict mode specified via one of the + legacy driver-specific options takes precedence. iommu.passthrough= [ARM64, X86] Configure DMA to bypass the IOMMU by default. @@ -2421,6 +2430,23 @@ feature (tagged TLBs) on capable Intel chips. Default is 1 (enabled) + l1d_flush= [X86,INTEL] + Control mitigation for L1D based snooping vulnerability. + + Certain CPUs are vulnerable to an exploit against CPU + internal buffers which can forward information to a + disclosure gadget under certain conditions. + + In vulnerable processors, the speculatively + forwarded data can be used in a cache side channel + attack, to access data to which the attacker does + not have direct access. + + This parameter controls the mitigation. The + options are: + + on - enable the interface for the mitigation + l1tf= [X86] Control mitigation of the L1TF vulnerability on affected CPUs @@ -4167,6 +4193,15 @@ Format: <bool> (1/Y/y=enable, 0/N/n=disable) default: disabled + printk.console_no_auto_verbose= + Disable console loglevel raise on oops, panic + or lockdep-detected issues (only if lock debug is on). + With an exception to setups with low baudrate on + serial console, keeping this 0 is a good choice + in order to provide more debug information. + Format: <bool> + default: 0 (auto_verbose is enabled) + printk.devkmsg={on,off,ratelimit} Control writing to /dev/kmsg. on - unlimited logging to /dev/kmsg from userspace @@ -4777,7 +4812,7 @@ reboot= [KNL] Format (x86 or x86_64): - [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \ + [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] | d[efault] \ [[,]s[mp]#### \ [[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \ [[,]f[orce] @@ -4945,8 +4980,6 @@ sa1100ir [NET] See drivers/net/irda/sa1100_ir.c. - sbni= [NET] Granch SBNI12 leased line adapter - sched_verbose [KNL] Enables verbose scheduler debug messages. schedstats= [KNL,X86] Enable or disable scheduled statistics. diff --git a/Documentation/admin-guide/laptops/lg-laptop.rst b/Documentation/admin-guide/laptops/lg-laptop.rst index ce9b14671cb9..6fbe165dcd27 100644 --- a/Documentation/admin-guide/laptops/lg-laptop.rst +++ b/Documentation/admin-guide/laptops/lg-laptop.rst @@ -13,10 +13,8 @@ Hotkeys The following FN keys are ignored by the kernel without this driver: - FN-F1 (LG control panel) - Generates F15 -- FN-F5 (Touchpad toggle) - Generates F13 +- FN-F5 (Touchpad toggle) - Generates F21 - FN-F6 (Airplane mode) - Generates RFKILL -- FN-F8 (Keyboard backlight) - Generates F16. - This key also changes keyboard backlight mode. - FN-F9 (Reader mode) - Generates F14 The rest of the FN keys work without a need for a special driver. diff --git a/Documentation/admin-guide/mm/damon/index.rst b/Documentation/admin-guide/mm/damon/index.rst new file mode 100644 index 000000000000..8c5dde3a5754 --- /dev/null +++ b/Documentation/admin-guide/mm/damon/index.rst @@ -0,0 +1,15 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================== +Monitoring Data Accesses +======================== + +:doc:`DAMON </vm/damon/index>` allows light-weight data access monitoring. +Using DAMON, users can analyze the memory access patterns of their systems and +optimize those. + +.. toctree:: + :maxdepth: 2 + + start + usage diff --git a/Documentation/admin-guide/mm/damon/start.rst b/Documentation/admin-guide/mm/damon/start.rst new file mode 100644 index 000000000000..d5eb89a8fc38 --- /dev/null +++ b/Documentation/admin-guide/mm/damon/start.rst @@ -0,0 +1,114 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +Getting Started +=============== + +This document briefly describes how you can use DAMON by demonstrating its +default user space tool. Please note that this document describes only a part +of its features for brevity. Please refer to :doc:`usage` for more details. + + +TL; DR +====== + +Follow the commands below to monitor and visualize the memory access pattern of +your workload. :: + + # # build the kernel with CONFIG_DAMON_*=y, install it, and reboot + # mount -t debugfs none /sys/kernel/debug/ + # git clone https://github.com/awslabs/damo + # ./damo/damo record $(pidof <your workload>) + # ./damo/damo report heat --plot_ascii + +The final command draws the access heatmap of ``<your workload>``. The heatmap +shows which memory region (x-axis) is accessed when (y-axis) and how frequently +(number; the higher the more accesses have been observed). :: + + 111111111111111111111111111111111111111111111111111111110000 + 111121111111111111111111111111211111111111111111111111110000 + 000000000000000000000000000000000000000000000000001555552000 + 000000000000000000000000000000000000000000000222223555552000 + 000000000000000000000000000000000000000011111677775000000000 + 000000000000000000000000000000000000000488888000000000000000 + 000000000000000000000000000000000177888400000000000000000000 + 000000000000000000000000000046666522222100000000000000000000 + 000000000000000000000014444344444300000000000000000000000000 + 000000000000000002222245555510000000000000000000000000000000 + # access_frequency: 0 1 2 3 4 5 6 7 8 9 + # x-axis: space (140286319947776-140286426374096: 101.496 MiB) + # y-axis: time (605442256436361-605479951866441: 37.695430s) + # resolution: 60x10 (1.692 MiB and 3.770s for each character) + + +Prerequisites +============= + +Kernel +------ + +You should first ensure your system is running on a kernel built with +``CONFIG_DAMON_*=y``. + + +User Space Tool +--------------- + +For the demonstration, we will use the default user space tool for DAMON, +called DAMON Operator (DAMO). It is available at +https://github.com/awslabs/damo. The examples below assume that ``damo`` is on +your ``$PATH``. It's not mandatory, though. + +Because DAMO is using the debugfs interface (refer to :doc:`usage` for the +detail) of DAMON, you should ensure debugfs is mounted. Mount it manually as +below:: + + # mount -t debugfs none /sys/kernel/debug/ + +or append the following line to your ``/etc/fstab`` file so that your system +can automatically mount debugfs upon booting:: + + debugfs /sys/kernel/debug debugfs defaults 0 0 + + +Recording Data Access Patterns +============================== + +The commands below record the memory access patterns of a program and save the +monitoring results to a file. :: + + $ git clone https://github.com/sjp38/masim + $ cd masim; make; ./masim ./configs/zigzag.cfg & + $ sudo damo record -o damon.data $(pidof masim) + +The first two lines of the commands download an artificial memory access +generator program and run it in the background. The generator will repeatedly +access two 100 MiB sized memory regions one by one. You can substitute this +with your real workload. The last line asks ``damo`` to record the access +pattern in the ``damon.data`` file. + + +Visualizing Recorded Patterns +============================= + +The following three commands visualize the recorded access patterns and save +the results as separate image files. :: + + $ damo report heats --heatmap access_pattern_heatmap.png + $ damo report wss --range 0 101 1 --plot wss_dist.png + $ damo report wss --range 0 101 1 --sortby time --plot wss_chron_change.png + +- ``access_pattern_heatmap.png`` will visualize the data access pattern in a + heatmap, showing which memory region (y-axis) got accessed when (x-axis) + and how frequently (color). +- ``wss_dist.png`` will show the distribution of the working set size. +- ``wss_chron_change.png`` will show how the working set size has + chronologically changed. + +You can view the visualizations of this example workload at [1]_. +Visualizations of other realistic workloads are available at [2]_ [3]_ [4]_. + +.. [1] https://damonitor.github.io/doc/html/v17/admin-guide/mm/damon/start.html#visualizing-recorded-patterns +.. [2] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.1.png.html +.. [3] https://damonitor.github.io/test/result/visual/latest/rec.wss_sz.png.html +.. [4] https://damonitor.github.io/test/result/visual/latest/rec.wss_time.png.html diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst new file mode 100644 index 000000000000..a72cda374aba --- /dev/null +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -0,0 +1,112 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +Detailed Usages +=============== + +DAMON provides below three interfaces for different users. + +- *DAMON user space tool.* + This is for privileged people such as system administrators who want a + just-working human-friendly interface. Using this, users can use the DAMON’s + major features in a human-friendly way. It may not be highly tuned for + special cases, though. It supports only virtual address spaces monitoring. +- *debugfs interface.* + This is for privileged user space programmers who want more optimized use of + DAMON. Using this, users can use DAMON’s major features by reading + from and writing to special debugfs files. Therefore, you can write and use + your personalized DAMON debugfs wrapper programs that reads/writes the + debugfs files instead of you. The DAMON user space tool is also a reference + implementation of such programs. It supports only virtual address spaces + monitoring. +- *Kernel Space Programming Interface.* + This is for kernel space programmers. Using this, users can utilize every + feature of DAMON most flexibly and efficiently by writing kernel space + DAMON application programs for you. You can even extend DAMON for various + address spaces. + +Nevertheless, you could write your own user space tool using the debugfs +interface. A reference implementation is available at +https://github.com/awslabs/damo. If you are a kernel programmer, you could +refer to :doc:`/vm/damon/api` for the kernel space programming interface. For +the reason, this document describes only the debugfs interface + +debugfs Interface +================= + +DAMON exports three files, ``attrs``, ``target_ids``, and ``monitor_on`` under +its debugfs directory, ``<debugfs>/damon/``. + + +Attributes +---------- + +Users can get and set the ``sampling interval``, ``aggregation interval``, +``regions update interval``, and min/max number of monitoring target regions by +reading from and writing to the ``attrs`` file. To know about the monitoring +attributes in detail, please refer to the :doc:`/vm/damon/design`. For +example, below commands set those values to 5 ms, 100 ms, 1,000 ms, 10 and +1000, and then check it again:: + + # cd <debugfs>/damon + # echo 5000 100000 1000000 10 1000 > attrs + # cat attrs + 5000 100000 1000000 10 1000 + + +Target IDs +---------- + +Some types of address spaces supports multiple monitoring target. For example, +the virtual memory address spaces monitoring can have multiple processes as the +monitoring targets. Users can set the targets by writing relevant id values of +the targets to, and get the ids of the current targets by reading from the +``target_ids`` file. In case of the virtual address spaces monitoring, the +values should be pids of the monitoring target processes. For example, below +commands set processes having pids 42 and 4242 as the monitoring targets and +check it again:: + + # cd <debugfs>/damon + # echo 42 4242 > target_ids + # cat target_ids + 42 4242 + +Note that setting the target ids doesn't start the monitoring. + + +Turning On/Off +-------------- + +Setting the files as described above doesn't incur effect unless you explicitly +start the monitoring. You can start, stop, and check the current status of the +monitoring by writing to and reading from the ``monitor_on`` file. Writing +``on`` to the file starts the monitoring of the targets with the attributes. +Writing ``off`` to the file stops those. DAMON also stops if every target +process is terminated. Below example commands turn on, off, and check the +status of DAMON:: + + # cd <debugfs>/damon + # echo on > monitor_on + # echo off > monitor_on + # cat monitor_on + off + +Please note that you cannot write to the above-mentioned debugfs files while +the monitoring is turned on. If you write to the files while DAMON is running, +an error code such as ``-EBUSY`` will be returned. + + +Tracepoint for Monitoring Results +================================= + +DAMON provides the monitoring results via a tracepoint, +``damon:damon_aggregated``. While the monitoring is turned on, you could +record the tracepoint events and show results using tracepoint supporting tools +like ``perf``. For example:: + + # echo on > monitor_on + # perf record -e damon:damon_aggregated & + # sleep 5 + # kill 9 $(pidof perf) + # echo off > monitor_on + # perf script diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst index 4b14d8b50e9e..cbd19d5e625f 100644 --- a/Documentation/admin-guide/mm/index.rst +++ b/Documentation/admin-guide/mm/index.rst @@ -27,6 +27,7 @@ the Linux memory management. concepts cma_debugfs + damon/index hugetlbpage idle_page_tracking ksm diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index c6bae2d77160..03dfbc925252 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -1,466 +1,576 @@ .. _admin_guide_memory_hotplug: -============== -Memory Hotplug -============== +================== +Memory Hot(Un)Plug +================== -:Created: Jul 28 2007 -:Updated: Add some details about locking internals: Aug 20 2018 - -This document is about memory hotplug including how-to-use and current status. -Because Memory Hotplug is still under development, contents of this text will -be changed often. +This document describes generic Linux support for memory hot(un)plug with +a focus on System RAM, including ZONE_MOVABLE support. .. contents:: :local: -.. note:: +Introduction +============ - (1) x86_64's has special implementation for memory hotplug. - This text does not describe it. - (2) This text assumes that sysfs is mounted at ``/sys``. +Memory hot(un)plug allows for increasing and decreasing the size of physical +memory available to a machine at runtime. In the simplest case, it consists of +physically plugging or unplugging a DIMM at runtime, coordinated with the +operating system. +Memory hot(un)plug is used for various purposes: -Introduction -============ +- The physical memory available to a machine can be adjusted at runtime, up- or + downgrading the memory capacity. This dynamic memory resizing, sometimes + referred to as "capacity on demand", is frequently used with virtual machines + and logical partitions. + +- Replacing hardware, such as DIMMs or whole NUMA nodes, without downtime. One + example is replacing failing memory modules. -Purpose of memory hotplug -------------------------- +- Reducing energy consumption either by physically unplugging memory modules or + by logically unplugging (parts of) memory modules from Linux. -Memory Hotplug allows users to increase/decrease the amount of memory. -Generally, there are two purposes. +Further, the basic memory hot(un)plug infrastructure in Linux is nowadays also +used to expose persistent memory, other performance-differentiated memory and +reserved memory regions as ordinary system RAM to Linux. -(A) For changing the amount of memory. - This is to allow a feature like capacity on demand. -(B) For installing/removing DIMMs or NUMA-nodes physically. - This is to exchange DIMMs/NUMA-nodes, reduce power consumption, etc. +Linux only supports memory hot(un)plug on selected 64 bit architectures, such as +x86_64, arm64, ppc64, s390x and ia64. -(A) is required by highly virtualized environments and (B) is required by -hardware which supports memory power management. +Memory Hot(Un)Plug Granularity +------------------------------ -Linux memory hotplug is designed for both purpose. +Memory hot(un)plug in Linux uses the SPARSEMEM memory model, which divides the +physical memory address space into chunks of the same size: memory sections. The +size of a memory section is architecture dependent. For example, x86_64 uses +128 MiB and ppc64 uses 16 MiB. -Phases of memory hotplug +Memory sections are combined into chunks referred to as "memory blocks". The +size of a memory block is architecture dependent and corresponds to the smallest +granularity that can be hot(un)plugged. The default size of a memory block is +the same as memory section size, unless an architecture specifies otherwise. + +All memory blocks have the same size. + +Phases of Memory Hotplug ------------------------ -There are 2 phases in Memory Hotplug: +Memory hotplug consists of two phases: - 1) Physical Memory Hotplug phase - 2) Logical Memory Hotplug phase. +(1) Adding the memory to Linux +(2) Onlining memory blocks -The First phase is to communicate hardware/firmware and make/erase -environment for hotplugged memory. Basically, this phase is necessary -for the purpose (B), but this is good phase for communication between -highly virtualized environments too. +In the first phase, metadata, such as the memory map ("memmap") and page tables +for the direct mapping, is allocated and initialized, and memory blocks are +created; the latter also creates sysfs files for managing newly created memory +blocks. -When memory is hotplugged, the kernel recognizes new memory, makes new memory -management tables, and makes sysfs files for new memory's operation. +In the second phase, added memory is exposed to the page allocator. After this +phase, the memory is visible in memory statistics, such as free and total +memory, of the system. -If firmware supports notification of connection of new memory to OS, -this phase is triggered automatically. ACPI can notify this event. If not, -"probe" operation by system administration is used instead. -(see :ref:`memory_hotplug_physical_mem`). +Phases of Memory Hotunplug +-------------------------- -Logical Memory Hotplug phase is to change memory state into -available/unavailable for users. Amount of memory from user's view is -changed by this phase. The kernel makes all memory in it as free pages -when a memory range is available. +Memory hotunplug consists of two phases: -In this document, this phase is described as online/offline. +(1) Offlining memory blocks +(2) Removing the memory from Linux -Logical Memory Hotplug phase is triggered by write of sysfs file by system -administrator. For the hot-add case, it must be executed after Physical Hotplug -phase by hand. -(However, if you writes udev's hotplug scripts for memory hotplug, these -phases can be execute in seamless way.) +In the fist phase, memory is "hidden" from the page allocator again, for +example, by migrating busy memory to other memory locations and removing all +relevant free pages from the page allocator After this phase, the memory is no +longer visible in memory statistics of the system. -Unit of Memory online/offline operation ---------------------------------------- +In the second phase, the memory blocks are removed and metadata is freed. -Memory hotplug uses SPARSEMEM memory model which allows memory to be divided -into chunks of the same size. These chunks are called "sections". The size of -a memory section is architecture dependent. For example, power uses 16MiB, ia64 -uses 1GiB. +Memory Hotplug Notifications +============================ -Memory sections are combined into chunks referred to as "memory blocks". The -size of a memory block is architecture dependent and represents the logical -unit upon which memory online/offline operations are to be performed. The -default size of a memory block is the same as memory section size unless an -architecture specifies otherwise. (see :ref:`memory_hotplug_sysfs_files`.) +There are various ways how Linux is notified about memory hotplug events such +that it can start adding hotplugged memory. This description is limited to +systems that support ACPI; mechanisms specific to other firmware interfaces or +virtual machines are not described. -To determine the size (in bytes) of a memory block please read this file:: +ACPI Notifications +------------------ - /sys/devices/system/memory/block_size_bytes +Platforms that support ACPI, such as x86_64, can support memory hotplug +notifications via ACPI. -Kernel Configuration -==================== +In general, a firmware supporting memory hotplug defines a memory class object +HID "PNP0C80". When notified about hotplug of a new memory device, the ACPI +driver will hotplug the memory to Linux. -To use memory hotplug feature, kernel must be compiled with following -config options. +If the firmware supports hotplug of NUMA nodes, it defines an object _HID +"ACPI0004", "PNP0A05", or "PNP0A06". When notified about an hotplug event, all +assigned memory devices are added to Linux by the ACPI driver. -- For all memory hotplug: - - Memory model -> Sparse Memory (``CONFIG_SPARSEMEM``) - - Allow for memory hot-add (``CONFIG_MEMORY_HOTPLUG``) +Similarly, Linux can be notified about requests to hotunplug a memory device or +a NUMA node via ACPI. The ACPI driver will try offlining all relevant memory +blocks, and, if successful, hotunplug the memory from Linux. -- To enable memory removal, the following are also necessary: - - Allow for memory hot remove (``CONFIG_MEMORY_HOTREMOVE``) - - Page Migration (``CONFIG_MIGRATION``) +Manual Probing +-------------- -- For ACPI memory hotplug, the following are also necessary: - - Memory hotplug (under ACPI Support menu) (``CONFIG_ACPI_HOTPLUG_MEMORY``) - - This option can be kernel module. +On some architectures, the firmware may not be able to notify the operating +system about a memory hotplug event. Instead, the memory has to be manually +probed from user space. -- As a related configuration, if your box has a feature of NUMA-node hotplug - via ACPI, then this option is necessary too. +The probe interface is located at:: - - ACPI0004,PNP0A05 and PNP0A06 Container Driver (under ACPI Support menu) - (``CONFIG_ACPI_CONTAINER``). + /sys/devices/system/memory/probe - This option can be kernel module too. +Only complete memory blocks can be probed. Individual memory blocks are probed +by providing the physical start address of the memory block:: + % echo addr > /sys/devices/system/memory/probe -.. _memory_hotplug_sysfs_files: +Which results in a memory block for the range [addr, addr + memory_block_size) +being created. -sysfs files for memory hotplug -============================== +.. note:: -All memory blocks have their device information in sysfs. Each memory block -is described under ``/sys/devices/system/memory`` as:: + Using the probe interface is discouraged as it is easy to crash the kernel, + because Linux cannot validate user input; this interface might be removed in + the future. - /sys/devices/system/memory/memoryXXX +Onlining and Offlining Memory Blocks +==================================== -where XXX is the memory block id. +After a memory block has been created, Linux has to be instructed to actually +make use of that memory: the memory block has to be "online". -For the memory block covered by the sysfs directory. It is expected that all -memory sections in this range are present and no memory holes exist in the -range. Currently there is no way to determine if there is a memory hole, but -the existence of one should not affect the hotplug capabilities of the memory -block. +Before a memory block can be removed, Linux has to stop using any memory part of +the memory block: the memory block has to be "offlined". -For example, assume 1GiB memory block size. A device for a memory starting at -0x100000000 is ``/sys/device/system/memory/memory4``:: +The Linux kernel can be configured to automatically online added memory blocks +and drivers automatically trigger offlining of memory blocks when trying +hotunplug of memory. Memory blocks can only be removed once offlining succeeded +and drivers may trigger offlining of memory blocks when attempting hotunplug of +memory. - (0x100000000 / 1Gib = 4) +Onlining Memory Blocks Manually +------------------------------- -This device covers address range [0x100000000 ... 0x140000000) +If auto-onlining of memory blocks isn't enabled, user-space has to manually +trigger onlining of memory blocks. Often, udev rules are used to automate this +task in user space. -Under each memory block, you can see 5 files: +Onlining of a memory block can be triggered via:: -- ``/sys/devices/system/memory/memoryXXX/phys_index`` -- ``/sys/devices/system/memory/memoryXXX/phys_device`` -- ``/sys/devices/system/memory/memoryXXX/state`` -- ``/sys/devices/system/memory/memoryXXX/removable`` -- ``/sys/devices/system/memory/memoryXXX/valid_zones`` + % echo online > /sys/devices/system/memory/memoryXXX/state -=================== ============================================================ -``phys_index`` read-only and contains memory block id, same as XXX. -``state`` read-write +Or alternatively:: - - at read: contains online/offline state of memory. - - at write: user can specify "online_kernel", + % echo 1 > /sys/devices/system/memory/memoryXXX/online - "online_movable", "online", "offline" command - which will be performed on all sections in the block. -``phys_device`` read-only: legacy interface only ever used on s390x to - expose the covered storage increment. -``removable`` read-only: legacy interface that indicated whether a memory - block was likely to be offlineable or not. Newer kernel - versions return "1" if and only if the kernel supports - memory offlining. -``valid_zones`` read-only: designed to show by which zone memory provided by - a memory block is managed, and to show by which zone memory - provided by an offline memory block could be managed when - onlining. - - The first column shows it`s default zone. - - "memory6/valid_zones: Normal Movable" shows this memoryblock - can be onlined to ZONE_NORMAL by default and to ZONE_MOVABLE - by online_movable. - - "memory7/valid_zones: Movable Normal" shows this memoryblock - can be onlined to ZONE_MOVABLE by default and to ZONE_NORMAL - by online_kernel. -=================== ============================================================ +The kernel will select the target zone automatically, usually defaulting to +``ZONE_NORMAL`` unless ``movablecore=1`` has been specified on the kernel +command line or if the memory block would intersect the ZONE_MOVABLE already. -.. note:: +One can explicitly request to associate an offline memory block with +ZONE_MOVABLE by:: - These directories/files appear after physical memory hotplug phase. + % echo online_movable > /sys/devices/system/memory/memoryXXX/state -If CONFIG_NUMA is enabled the memoryXXX/ directories can also be accessed -via symbolic links located in the ``/sys/devices/system/node/node*`` directories. +Or one can explicitly request a kernel zone (usually ZONE_NORMAL) by:: -For example:: + % echo online_kernel > /sys/devices/system/memory/memoryXXX/state - /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 +In any case, if onlining succeeds, the state of the memory block is changed to +be "online". If it fails, the state of the memory block will remain unchanged +and the above commands will fail. -A backlink will also be created:: +Onlining Memory Blocks Automatically +------------------------------------ - /sys/devices/system/memory/memory9/node0 -> ../../node/node0 +The kernel can be configured to try auto-onlining of newly added memory blocks. +If this feature is disabled, the memory blocks will stay offline until +explicitly onlined from user space. -.. _memory_hotplug_physical_mem: +The configured auto-online behavior can be observed via:: -Physical memory hot-add phase -============================= + % cat /sys/devices/system/memory/auto_online_blocks -Hardware(Firmware) Support --------------------------- +Auto-onlining can be enabled by writing ``online``, ``online_kernel`` or +``online_movable`` to that file, like:: -On x86_64/ia64 platform, memory hotplug by ACPI is supported. + % echo online > /sys/devices/system/memory/auto_online_blocks -In general, the firmware (ACPI) which supports memory hotplug defines -memory class object of _HID "PNP0C80". When a notify is asserted to PNP0C80, -Linux's ACPI handler does hot-add memory to the system and calls a hotplug udev -script. This will be done automatically. +Modifying the auto-online behavior will only affect all subsequently added +memory blocks only. -But scripts for memory hotplug are not contained in generic udev package(now). -You may have to write it by yourself or online/offline memory by hand. -Please see :ref:`memory_hotplug_how_to_online_memory` and -:ref:`memory_hotplug_how_to_offline_memory`. +.. note:: -If firmware supports NUMA-node hotplug, and defines an object _HID "ACPI0004", -"PNP0A05", or "PNP0A06", notification is asserted to it, and ACPI handler -calls hotplug code for all of objects which are defined in it. -If memory device is found, memory hotplug code will be called. + In corner cases, auto-onlining can fail. The kernel won't retry. Note that + auto-onlining is not expected to fail in default configurations. -Notify memory hot-add event by hand ------------------------------------ +.. note:: -On some architectures, the firmware may not notify the kernel of a memory -hotplug event. Therefore, the memory "probe" interface is supported to -explicitly notify the kernel. This interface depends on -CONFIG_ARCH_MEMORY_PROBE and can be configured on powerpc, sh, and x86 -if hotplug is supported, although for x86 this should be handled by ACPI -notification. + DLPAR on ppc64 ignores the ``offline`` setting and will still online added + memory blocks; if onlining fails, memory blocks are removed again. -Probe interface is located at:: +Offlining Memory Blocks +----------------------- - /sys/devices/system/memory/probe +In the current implementation, Linux's memory offlining will try migrating all +movable pages off the affected memory block. As most kernel allocations, such as +page tables, are unmovable, page migration can fail and, therefore, inhibit +memory offlining from succeeding. -You can tell the physical address of new memory to the kernel by:: +Having the memory provided by memory block managed by ZONE_MOVABLE significantly +increases memory offlining reliability; still, memory offlining can fail in +some corner cases. - % echo start_address_of_new_memory > /sys/devices/system/memory/probe +Further, memory offlining might retry for a long time (or even forever), until +aborted by the user. -Then, [start_address_of_new_memory, start_address_of_new_memory + -memory_block_size] memory range is hot-added. In this case, hotplug script is -not called (in current implementation). You'll have to online memory by -yourself. Please see :ref:`memory_hotplug_how_to_online_memory`. +Offlining of a memory block can be triggered via:: -Logical Memory hot-add phase -============================ + % echo offline > /sys/devices/system/memory/memoryXXX/state -State of memory ---------------- +Or alternatively:: -To see (online/offline) state of a memory block, read 'state' file:: + % echo 0 > /sys/devices/system/memory/memoryXXX/online - % cat /sys/device/system/memory/memoryXXX/state +If offlining succeeds, the state of the memory block is changed to be "offline". +If it fails, the state of the memory block will remain unchanged and the above +commands will fail, for example, via:: + bash: echo: write error: Device or resource busy -- If the memory block is online, you'll read "online". -- If the memory block is offline, you'll read "offline". +or via:: + bash: echo: write error: Invalid argument -.. _memory_hotplug_how_to_online_memory: +Observing the State of Memory Blocks +------------------------------------ -How to online memory --------------------- +The state (online/offline/going-offline) of a memory block can be observed +either via:: -When the memory is hot-added, the kernel decides whether or not to "online" -it according to the policy which can be read from "auto_online_blocks" file:: + % cat /sys/device/system/memory/memoryXXX/state - % cat /sys/devices/system/memory/auto_online_blocks +Or alternatively (1/0) via:: -The default depends on the CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel config -option. If it is disabled the default is "offline" which means the newly added -memory is not in a ready-to-use state and you have to "online" the newly added -memory blocks manually. Automatic onlining can be requested by writing "online" -to "auto_online_blocks" file:: + % cat /sys/device/system/memory/memoryXXX/online - % echo online > /sys/devices/system/memory/auto_online_blocks +For an online memory block, the managing zone can be observed via:: -This sets a global policy and impacts all memory blocks that will subsequently -be hotplugged. Currently offline blocks keep their state. It is possible, under -certain circumstances, that some memory blocks will be added but will fail to -online. User space tools can check their "state" files -(``/sys/devices/system/memory/memoryXXX/state``) and try to online them manually. + % cat /sys/device/system/memory/memoryXXX/valid_zones -If the automatic onlining wasn't requested, failed, or some memory block was -offlined it is possible to change the individual block's state by writing to the -"state" file:: +Configuring Memory Hot(Un)Plug +============================== - % echo online > /sys/devices/system/memory/memoryXXX/state +There are various ways how system administrators can configure memory +hot(un)plug and interact with memory blocks, especially, to online them. -This onlining will not change the ZONE type of the target memory block, -If the memory block doesn't belong to any zone an appropriate kernel zone -(usually ZONE_NORMAL) will be used unless movable_node kernel command line -option is specified when ZONE_MOVABLE will be used. +Memory Hot(Un)Plug Configuration via Sysfs +------------------------------------------ -You can explicitly request to associate it with ZONE_MOVABLE by:: +Some memory hot(un)plug properties can be configured or inspected via sysfs in:: - % echo online_movable > /sys/devices/system/memory/memoryXXX/state + /sys/devices/system/memory/ -.. note:: current limit: this memory block must be adjacent to ZONE_MOVABLE +The following files are currently defined: -Or you can explicitly request a kernel zone (usually ZONE_NORMAL) by:: +====================== ========================================================= +``auto_online_blocks`` read-write: set or get the default state of new memory + blocks; configure auto-onlining. - % echo online_kernel > /sys/devices/system/memory/memoryXXX/state + The default value depends on the + CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel configuration + option. -.. note:: current limit: this memory block must be adjacent to ZONE_NORMAL + See the ``state`` property of memory blocks for details. +``block_size_bytes`` read-only: the size in bytes of a memory block. +``probe`` write-only: add (probe) selected memory blocks manually + from user space by supplying the physical start address. -An explicit zone onlining can fail (e.g. when the range is already within -and existing and incompatible zone already). + Availability depends on the CONFIG_ARCH_MEMORY_PROBE + kernel configuration option. +``uevent`` read-write: generic udev file for device subsystems. +====================== ========================================================= -After this, memory block XXX's state will be 'online' and the amount of -available memory will be increased. +.. note:: -This may be changed in future. + When the CONFIG_MEMORY_FAILURE kernel configuration option is enabled, two + additional files ``hard_offline_page`` and ``soft_offline_page`` are available + to trigger hwpoisoning of pages, for example, for testing purposes. Note that + this functionality is not really related to memory hot(un)plug or actual + offlining of memory blocks. -Logical memory remove -===================== +Memory Block Configuration via Sysfs +------------------------------------ -Memory offline and ZONE_MOVABLE -------------------------------- +Each memory block is represented as a memory block device that can be +onlined or offlined. All memory blocks have their device information located in +sysfs. Each present memory block is listed under +``/sys/devices/system/memory`` as:: -Memory offlining is more complicated than memory online. Because memory offline -has to make the whole memory block be unused, memory offline can fail if -the memory block includes memory which cannot be freed. + /sys/devices/system/memory/memoryXXX -In general, memory offline can use 2 techniques. +where XXX is the memory block id; the number of digits is variable. -(1) reclaim and free all memory in the memory block. -(2) migrate all pages in the memory block. +A present memory block indicates that some memory in the range is present; +however, a memory block might span memory holes. A memory block spanning memory +holes cannot be offlined. -In the current implementation, Linux's memory offline uses method (2), freeing -all pages in the memory block by page migration. But not all pages are -migratable. Under current Linux, migratable pages are anonymous pages and -page caches. For offlining a memory block by migration, the kernel has to -guarantee that the memory block contains only migratable pages. +For example, assume 1 GiB memory block size. A device for a memory starting at +0x100000000 is ``/sys/device/system/memory/memory4``:: -Now, a boot option for making a memory block which consists of migratable pages -is supported. By specifying "kernelcore=" or "movablecore=" boot option, you can -create ZONE_MOVABLE...a zone which is just used for movable pages. -(See also Documentation/admin-guide/kernel-parameters.rst) + (0x100000000 / 1Gib = 4) -Assume the system has "TOTAL" amount of memory at boot time, this boot option -creates ZONE_MOVABLE as following. +This device covers address range [0x100000000 ... 0x140000000) -1) When kernelcore=YYYY boot option is used, - Size of memory not for movable pages (not for offline) is YYYY. - Size of memory for movable pages (for offline) is TOTAL-YYYY. +The following files are currently defined: -2) When movablecore=ZZZZ boot option is used, - Size of memory not for movable pages (not for offline) is TOTAL - ZZZZ. - Size of memory for movable pages (for offline) is ZZZZ. +=================== ============================================================ +``online`` read-write: simplified interface to trigger onlining / + offlining and to observe the state of a memory block. + When onlining, the zone is selected automatically. +``phys_device`` read-only: legacy interface only ever used on s390x to + expose the covered storage increment. +``phys_index`` read-only: the memory block id (XXX). +``removable`` read-only: legacy interface that indicated whether a memory + block was likely to be offlineable or not. Nowadays, the + kernel return ``1`` if and only if it supports memory + offlining. +``state`` read-write: advanced interface to trigger onlining / + offlining and to observe the state of a memory block. + + When writing, ``online``, ``offline``, ``online_kernel`` and + ``online_movable`` are supported. + + ``online_movable`` specifies onlining to ZONE_MOVABLE. + ``online_kernel`` specifies onlining to the default kernel + zone for the memory block, such as ZONE_NORMAL. + ``online`` let's the kernel select the zone automatically. + + When reading, ``online``, ``offline`` and ``going-offline`` + may be returned. +``uevent`` read-write: generic uevent file for devices. +``valid_zones`` read-only: when a block is online, shows the zone it + belongs to; when a block is offline, shows what zone will + manage it when the block will be onlined. + + For online memory blocks, ``DMA``, ``DMA32``, ``Normal``, + ``Movable`` and ``none`` may be returned. ``none`` indicates + that memory provided by a memory block is managed by + multiple zones or spans multiple nodes; such memory blocks + cannot be offlined. ``Movable`` indicates ZONE_MOVABLE. + Other values indicate a kernel zone. + + For offline memory blocks, the first column shows the + zone the kernel would select when onlining the memory block + right now without further specifying a zone. + + Availability depends on the CONFIG_MEMORY_HOTREMOVE + kernel configuration option. +=================== ============================================================ .. note:: - Unfortunately, there is no information to show which memory block belongs - to ZONE_MOVABLE. This is TBD. + If the CONFIG_NUMA kernel configuration option is enabled, the memoryXXX/ + directories can also be accessed via symbolic links located in the + ``/sys/devices/system/node/node*`` directories. + + For example:: + + /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 + + A backlink will also be created:: + + /sys/devices/system/memory/memory9/node0 -> ../../node/node0 + +Command Line Parameters +----------------------- + +Some command line parameters affect memory hot(un)plug handling. The following +command line parameters are relevant: + +======================== ======================================================= +``memhp_default_state`` configure auto-onlining by essentially setting + ``/sys/devices/system/memory/auto_online_blocks``. +``movablecore`` configure automatic zone selection of the kernel. When + set, the kernel will default to ZONE_MOVABLE, unless + other zones can be kept contiguous. +======================== ======================================================= + +Module Parameters +------------------ - Memory offlining can fail when dissolving a free huge page on ZONE_MOVABLE - and the feature of freeing unused vmemmap pages associated with each hugetlb - page is enabled. +Instead of additional command line parameters or sysfs files, the +``memory_hotplug`` subsystem now provides a dedicated namespace for module +parameters. Module parameters can be set via the command line by predicating +them with ``memory_hotplug.`` such as:: + + memory_hotplug.memmap_on_memory=1 + +and they can be observed (and some even modified at runtime) via:: + + /sys/modules/memory_hotplug/parameters/ + +The following module parameters are currently defined: + +======================== ======================================================= +``memmap_on_memory`` read-write: Allocate memory for the memmap from the + added memory block itself. Even if enabled, actual + support depends on various other system properties and + should only be regarded as a hint whether the behavior + would be desired. + + While allocating the memmap from the memory block + itself makes memory hotplug less likely to fail and + keeps the memmap on the same NUMA node in any case, it + can fragment physical memory in a way that huge pages + in bigger granularity cannot be formed on hotplugged + memory. +======================== ======================================================= + +ZONE_MOVABLE +============ + +ZONE_MOVABLE is an important mechanism for more reliable memory offlining. +Further, having system RAM managed by ZONE_MOVABLE instead of one of the +kernel zones can increase the number of possible transparent huge pages and +dynamically allocated huge pages. + +Most kernel allocations are unmovable. Important examples include the memory +map (usually 1/64ths of memory), page tables, and kmalloc(). Such allocations +can only be served from the kernel zones. + +Most user space pages, such as anonymous memory, and page cache pages are +movable. Such allocations can be served from ZONE_MOVABLE and the kernel zones. + +Only movable allocations are served from ZONE_MOVABLE, resulting in unmovable +allocations being limited to the kernel zones. Without ZONE_MOVABLE, there is +absolutely no guarantee whether a memory block can be offlined successfully. + +Zone Imbalances +--------------- - This can happen when we have plenty of ZONE_MOVABLE memory, but not enough - kernel memory to allocate vmemmmap pages. We may even be able to migrate - huge page contents, but will not be able to dissolve the source huge page. - This will prevent an offline operation and is unfortunate as memory offlining - is expected to succeed on movable zones. Users that depend on memory hotplug - to succeed for movable zones should carefully consider whether the memory - savings gained from this feature are worth the risk of possibly not being - able to offline memory in certain situations. +Having too much system RAM managed by ZONE_MOVABLE is called a zone imbalance, +which can harm the system or degrade performance. As one example, the kernel +might crash because it runs out of free memory for unmovable allocations, +although there is still plenty of free memory left in ZONE_MOVABLE. + +Usually, MOVABLE:KERNEL ratios of up to 3:1 or even 4:1 are fine. Ratios of 63:1 +are definitely impossible due to the overhead for the memory map. + +Actual safe zone ratios depend on the workload. Extreme cases, like excessive +long-term pinning of pages, might not be able to deal with ZONE_MOVABLE at all. .. note:: - Techniques that rely on long-term pinnings of memory (especially, RDMA and - vfio) are fundamentally problematic with ZONE_MOVABLE and, therefore, memory - hot remove. Pinned pages cannot reside on ZONE_MOVABLE, to guarantee that - memory can still get hot removed - be aware that pinning can fail even if - there is plenty of free memory in ZONE_MOVABLE. In addition, using - ZONE_MOVABLE might make page pinning more expensive, because pages have to be - migrated off that zone first. -.. _memory_hotplug_how_to_offline_memory: + CMA memory part of a kernel zone essentially behaves like memory in + ZONE_MOVABLE and similar considerations apply, especially when combining + CMA with ZONE_MOVABLE. -How to offline memory ---------------------- +ZONE_MOVABLE Sizing Considerations +---------------------------------- -You can offline a memory block by using the same sysfs interface that was used -in memory onlining:: +We usually expect that a large portion of available system RAM will actually +be consumed by user space, either directly or indirectly via the page cache. In +the normal case, ZONE_MOVABLE can be used when allocating such pages just fine. - % echo offline > /sys/devices/system/memory/memoryXXX/state +With that in mind, it makes sense that we can have a big portion of system RAM +managed by ZONE_MOVABLE. However, there are some things to consider when using +ZONE_MOVABLE, especially when fine-tuning zone ratios: + +- Having a lot of offline memory blocks. Even offline memory blocks consume + memory for metadata and page tables in the direct map; having a lot of offline + memory blocks is not a typical case, though. + +- Memory ballooning without balloon compaction is incompatible with + ZONE_MOVABLE. Only some implementations, such as virtio-balloon and + pseries CMM, fully support balloon compaction. + + Further, the CONFIG_BALLOON_COMPACTION kernel configuration option might be + disabled. In that case, balloon inflation will only perform unmovable + allocations and silently create a zone imbalance, usually triggered by + inflation requests from the hypervisor. + +- Gigantic pages are unmovable, resulting in user space consuming a + lot of unmovable memory. + +- Huge pages are unmovable when an architectures does not support huge + page migration, resulting in a similar issue as with gigantic pages. + +- Page tables are unmovable. Excessive swapping, mapping extremely large + files or ZONE_DEVICE memory can be problematic, although only really relevant + in corner cases. When we manage a lot of user space memory that has been + swapped out or is served from a file/persistent memory/... we still need a lot + of page tables to manage that memory once user space accessed that memory. + +- In certain DAX configurations the memory map for the device memory will be + allocated from the kernel zones. + +- KASAN can have a significant memory overhead, for example, consuming 1/8th of + the total system memory size as (unmovable) tracking metadata. + +- Long-term pinning of pages. Techniques that rely on long-term pinnings + (especially, RDMA and vfio/mdev) are fundamentally problematic with + ZONE_MOVABLE, and therefore, memory offlining. Pinned pages cannot reside + on ZONE_MOVABLE as that would turn these pages unmovable. Therefore, they + have to be migrated off that zone while pinning. Pinning a page can fail + even if there is plenty of free memory in ZONE_MOVABLE. + + In addition, using ZONE_MOVABLE might make page pinning more expensive, + because of the page migration overhead. + +By default, all the memory configured at boot time is managed by the kernel +zones and ZONE_MOVABLE is not used. + +To enable ZONE_MOVABLE to include the memory present at boot and to control the +ratio between movable and kernel zones there are two command line options: +``kernelcore=`` and ``movablecore=``. See +Documentation/admin-guide/kernel-parameters.rst for their description. + +Memory Offlining and ZONE_MOVABLE +--------------------------------- + +Even with ZONE_MOVABLE, there are some corner cases where offlining a memory +block might fail: + +- Memory blocks with memory holes; this applies to memory blocks present during + boot and can apply to memory blocks hotplugged via the XEN balloon and the + Hyper-V balloon. + +- Mixed NUMA nodes and mixed zones within a single memory block prevent memory + offlining; this applies to memory blocks present during boot only. + +- Special memory blocks prevented by the system from getting offlined. Examples + include any memory available during boot on arm64 or memory blocks spanning + the crashkernel area on s390x; this usually applies to memory blocks present + during boot only. + +- Memory blocks overlapping with CMA areas cannot be offlined, this applies to + memory blocks present during boot only. + +- Concurrent activity that operates on the same physical memory area, such as + allocating gigantic pages, can result in temporary offlining failures. + +- Out of memory when dissolving huge pages, especially when freeing unused + vmemmap pages associated with each hugetlb page is enabled. + + Offlining code may be able to migrate huge page contents, but may not be able + to dissolve the source huge page because it fails allocating (unmovable) pages + for the vmemmap, because the system might not have free memory in the kernel + zones left. + + Users that depend on memory offlining to succeed for movable zones should + carefully consider whether the memory savings gained from this feature are + worth the risk of possibly not being able to offline memory in certain + situations. + +Further, when running into out of memory situations while migrating pages, or +when still encountering permanently unmovable pages within ZONE_MOVABLE +(-> BUG), memory offlining will keep retrying until it eventually succeeds. + +When offlining is triggered from user space, the offlining context can be +terminated by sending a fatal signal. A timeout based offlining can easily be +implemented via:: -If offline succeeds, the state of the memory block is changed to be "offline". -If it fails, some error core (like -EBUSY) will be returned by the kernel. -Even if a memory block does not belong to ZONE_MOVABLE, you can try to offline -it. If it doesn't contain 'unmovable' memory, you'll get success. - -A memory block under ZONE_MOVABLE is considered to be able to be offlined -easily. But under some busy state, it may return -EBUSY. Even if a memory -block cannot be offlined due to -EBUSY, you can retry offlining it and may be -able to offline it (or not). (For example, a page is referred to by some kernel -internal call and released soon.) - -Consideration: - Memory hotplug's design direction is to make the possibility of memory - offlining higher and to guarantee unplugging memory under any situation. But - it needs more work. Returning -EBUSY under some situation may be good because - the user can decide to retry more or not by himself. Currently, memory - offlining code does some amount of retry with 120 seconds timeout. - -Physical memory remove -====================== - -Need more implementation yet.... - - Notification completion of remove works by OS to firmware. - - Guard from remove if not yet. - - -Locking Internals -================= - -When adding/removing memory that uses memory block devices (i.e. ordinary RAM), -the device_hotplug_lock should be held to: - -- synchronize against online/offline requests (e.g. via sysfs). This way, memory - block devices can only be accessed (.online/.state attributes) by user - space once memory has been fully added. And when removing memory, we - know nobody is in critical sections. -- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC) - -Especially, there is a possible lock inversion that is avoided using -device_hotplug_lock when adding memory and user space tries to online that -memory faster than expected: - -- device_online() will first take the device_lock(), followed by - mem_hotplug_lock -- add_memory_resource() will first take the mem_hotplug_lock, followed by - the device_lock() (while creating the devices, during bus_add_device()). - -As the device is visible to user space before taking the device_lock(), this -can result in a lock inversion. - -onlining/offlining of memory should be done via device_online()/ -device_offline() - to make sure it is properly synchronized to actions -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type) - -When adding/removing/onlining/offlining memory or adding/removing -heterogeneous/device memory, we should always hold the mem_hotplug_lock in -write mode to serialise memory hotplug (e.g. access to global/zone -variables). - -In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read -mode allows for a quite efficient get_online_mems/put_online_mems -implementation, so code accessing memory can protect from that memory -vanishing. - - -Future Work -=========== - - - allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like - sysctl or new control file. - - showing memory block and physical device relationship. - - test and make it better memory offlining. - - support HugeTLB page migration and offlining. - - memmap removing at memory offline. - - physical remove memory. + % timeout $TIMEOUT offline_block | failure_handling diff --git a/Documentation/admin-guide/mm/numa_memory_policy.rst b/Documentation/admin-guide/mm/numa_memory_policy.rst index 067a90a1499c..64fd0ba0d057 100644 --- a/Documentation/admin-guide/mm/numa_memory_policy.rst +++ b/Documentation/admin-guide/mm/numa_memory_policy.rst @@ -245,6 +245,13 @@ MPOL_INTERLEAVED address range or file. During system boot up, the temporary interleaved system default policy works in this mode. +MPOL_PREFERRED_MANY + This mode specifices that the allocation should be preferrably + satisfied from the nodemask specified in the policy. If there is + a memory pressure on all nodes in the nodemask, the allocation + can fall back to all existing numa nodes. This is effectively + MPOL_PREFERRED allowed for a mask rather than a single node. + NUMA memory policy supports the following optional mode flags: MPOL_F_STATIC_NODES @@ -253,10 +260,10 @@ MPOL_F_STATIC_NODES nodes changes after the memory policy has been defined. Without this flag, any time a mempolicy is rebound because of a - change in the set of allowed nodes, the node (Preferred) or - nodemask (Bind, Interleave) is remapped to the new set of - allowed nodes. This may result in nodes being used that were - previously undesired. + change in the set of allowed nodes, the preferred nodemask (Preferred + Many), preferred node (Preferred) or nodemask (Bind, Interleave) is + remapped to the new set of allowed nodes. This may result in nodes + being used that were previously undesired. With this flag, if the user-specified nodes overlap with the nodes allowed by the task's cpuset, then the memory policy is diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 003d5cc3751b..5e795202111f 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -118,7 +118,8 @@ compaction_proactiveness This tunable takes a value in the range [0, 100] with a default value of 20. This tunable determines how aggressively compaction is done in the -background. Setting it to 0 disables proactive compaction. +background. Write of a non zero value to this tunable will immediately +trigger the proactive compaction. Setting it to 0 disables proactive compaction. Note that compaction has a non-trivial system-wide impact as pages belonging to different processes are moved around, which could also lead diff --git a/Documentation/arm64/asymmetric-32bit.rst b/Documentation/arm64/asymmetric-32bit.rst new file mode 100644 index 000000000000..64a0b505da7d --- /dev/null +++ b/Documentation/arm64/asymmetric-32bit.rst @@ -0,0 +1,155 @@ +====================== +Asymmetric 32-bit SoCs +====================== + +Author: Will Deacon <will@kernel.org> + +This document describes the impact of asymmetric 32-bit SoCs on the +execution of 32-bit (``AArch32``) applications. + +Date: 2021-05-17 + +Introduction +============ + +Some Armv9 SoCs suffer from a big.LITTLE misfeature where only a subset +of the CPUs are capable of executing 32-bit user applications. On such +a system, Linux by default treats the asymmetry as a "mismatch" and +disables support for both the ``PER_LINUX32`` personality and +``execve(2)`` of 32-bit ELF binaries, with the latter returning +``-ENOEXEC``. If the mismatch is detected during late onlining of a +64-bit-only CPU, then the onlining operation fails and the new CPU is +unavailable for scheduling. + +Surprisingly, these SoCs have been produced with the intention of +running legacy 32-bit binaries. Unsurprisingly, that doesn't work very +well with the default behaviour of Linux. + +It seems inevitable that future SoCs will drop 32-bit support +altogether, so if you're stuck in the unenviable position of needing to +run 32-bit code on one of these transitionary platforms then you would +be wise to consider alternatives such as recompilation, emulation or +retirement. If neither of those options are practical, then read on. + +Enabling kernel support +======================= + +Since the kernel support is not completely transparent to userspace, +allowing 32-bit tasks to run on an asymmetric 32-bit system requires an +explicit "opt-in" and can be enabled by passing the +``allow_mismatched_32bit_el0`` parameter on the kernel command-line. + +For the remainder of this document we will refer to an *asymmetric +system* to mean an asymmetric 32-bit SoC running Linux with this kernel +command-line option enabled. + +Userspace impact +================ + +32-bit tasks running on an asymmetric system behave in mostly the same +way as on a homogeneous system, with a few key differences relating to +CPU affinity. + +sysfs +----- + +The subset of CPUs capable of running 32-bit tasks is described in +``/sys/devices/system/cpu/aarch32_el0`` and is documented further in +``Documentation/ABI/testing/sysfs-devices-system-cpu``. + +**Note:** CPUs are advertised by this file as they are detected and so +late-onlining of 32-bit-capable CPUs can result in the file contents +being modified by the kernel at runtime. Once advertised, CPUs are never +removed from the file. + +``execve(2)`` +------------- + +On a homogeneous system, the CPU affinity of a task is preserved across +``execve(2)``. This is not always possible on an asymmetric system, +specifically when the new program being executed is 32-bit yet the +affinity mask contains 64-bit-only CPUs. In this situation, the kernel +determines the new affinity mask as follows: + + 1. If the 32-bit-capable subset of the affinity mask is not empty, + then the affinity is restricted to that subset and the old affinity + mask is saved. This saved mask is inherited over ``fork(2)`` and + preserved across ``execve(2)`` of 32-bit programs. + + **Note:** This step does not apply to ``SCHED_DEADLINE`` tasks. + See `SCHED_DEADLINE`_. + + 2. Otherwise, the cpuset hierarchy of the task is walked until an + ancestor is found containing at least one 32-bit-capable CPU. The + affinity of the task is then changed to match the 32-bit-capable + subset of the cpuset determined by the walk. + + 3. On failure (i.e. out of memory), the affinity is changed to the set + of all 32-bit-capable CPUs of which the kernel is aware. + +A subsequent ``execve(2)`` of a 64-bit program by the 32-bit task will +invalidate the affinity mask saved in (1) and attempt to restore the CPU +affinity of the task using the saved mask if it was previously valid. +This restoration may fail due to intervening changes to the deadline +policy or cpuset hierarchy, in which case the ``execve(2)`` continues +with the affinity unchanged. + +Calls to ``sched_setaffinity(2)`` for a 32-bit task will consider only +the 32-bit-capable CPUs of the requested affinity mask. On success, the +affinity for the task is updated and any saved mask from a prior +``execve(2)`` is invalidated. + +``SCHED_DEADLINE`` +------------------ + +Explicit admission of a 32-bit deadline task to the default root domain +(e.g. by calling ``sched_setattr(2)``) is rejected on an asymmetric +32-bit system unless admission control is disabled by writing -1 to +``/proc/sys/kernel/sched_rt_runtime_us``. + +``execve(2)`` of a 32-bit program from a 64-bit deadline task will +return ``-ENOEXEC`` if the root domain for the task contains any +64-bit-only CPUs and admission control is enabled. Concurrent offlining +of 32-bit-capable CPUs may still necessitate the procedure described in +`execve(2)`_, in which case step (1) is skipped and a warning is +emitted on the console. + +**Note:** It is recommended that a set of 32-bit-capable CPUs are placed +into a separate root domain if ``SCHED_DEADLINE`` is to be used with +32-bit tasks on an asymmetric system. Failure to do so is likely to +result in missed deadlines. + +Cpusets +------- + +The affinity of a 32-bit task on an asymmetric system may include CPUs +that are not explicitly allowed by the cpuset to which it is attached. +This can occur as a result of the following two situations: + + - A 64-bit task attached to a cpuset which allows only 64-bit CPUs + executes a 32-bit program. + + - All of the 32-bit-capable CPUs allowed by a cpuset containing a + 32-bit task are offlined. + +In both of these cases, the new affinity is calculated according to step +(2) of the process described in `execve(2)`_ and the cpuset hierarchy is +unchanged irrespective of the cgroup version. + +CPU hotplug +----------- + +On an asymmetric system, the first detected 32-bit-capable CPU is +prevented from being offlined by userspace and any such attempt will +return ``-EPERM``. Note that suspend is still permitted even if the +primary CPU (i.e. CPU 0) is 64-bit-only. + +KVM +--- + +Although KVM will not advertise 32-bit EL0 support to any vCPUs on an +asymmetric system, a broken guest at EL1 could still attempt to execute +32-bit code at EL0. In this case, an exit from a vCPU thread in 32-bit +mode will return to host userspace with an ``exit_reason`` of +``KVM_EXIT_FAIL_ENTRY`` and will remain non-runnable until successfully +re-initialised by a subsequent ``KVM_ARM_VCPU_INIT`` operation. diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index a9192e7a231b..3f9d86557c5e 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -207,10 +207,17 @@ Before jumping into the kernel, the following conditions must be met: software at a higher exception level to prevent execution in an UNKNOWN state. - - SCR_EL3.FIQ must have the same value across all CPUs the kernel is - executing on. - - The value of SCR_EL3.FIQ must be the same as the one present at boot - time whenever the kernel is executing. + For all systems: + - If EL3 is present: + + - SCR_EL3.FIQ must have the same value across all CPUs the kernel is + executing on. + - The value of SCR_EL3.FIQ must be the same as the one present at boot + time whenever the kernel is executing. + + - If EL3 is present and the kernel is entered at EL2: + + - SCR_EL3.HCE (bit 8) must be initialised to 0b1. For systems with a GICv3 interrupt controller to be used in v3 mode: - If EL3 is present: @@ -311,6 +318,28 @@ Before jumping into the kernel, the following conditions must be met: - ZCR_EL2.LEN must be initialised to the same value for all CPUs the kernel will execute on. + For CPUs with the Scalable Matrix Extension (FEAT_SME): + + - If EL3 is present: + + - CPTR_EL3.ESM (bit 12) must be initialised to 0b1. + + - SCR_EL3.EnTP2 (bit 41) must be initialised to 0b1. + + - SMCR_EL3.LEN must be initialised to the same value for all CPUs the + kernel will execute on. + + - If the kernel is entered at EL1 and EL2 is present: + + - CPTR_EL2.TSM (bit 12) must be initialised to 0b0. + + - CPTR_EL2.SMEN (bits 25:24) must be initialised to 0b11. + + - SCTLR_EL2.EnTP2 (bit 60) must be initialised to 0b1. + + - SMCR_EL2.LEN must be initialised to the same value for all CPUs the + kernel will execute on. + The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must enter the kernel in the same exception level. Where the values documented diff --git a/Documentation/arm64/index.rst b/Documentation/arm64/index.rst index 97d65ba12a35..4f840bac083e 100644 --- a/Documentation/arm64/index.rst +++ b/Documentation/arm64/index.rst @@ -10,6 +10,7 @@ ARM64 Architecture acpi_object_usage amu arm-acpi + asymmetric-32bit booting cpu-feature-registers elf_hwcaps diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst index b540178a93f8..7b99c8f428eb 100644 --- a/Documentation/arm64/memory-tagging-extension.rst +++ b/Documentation/arm64/memory-tagging-extension.rst @@ -77,14 +77,20 @@ configurable behaviours: address is unknown). The user can select the above modes, per thread, using the -``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where -``flags`` contain one of the following values in the ``PR_MTE_TCF_MASK`` +``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where ``flags`` +contains any number of the following values in the ``PR_MTE_TCF_MASK`` bit-field: -- ``PR_MTE_TCF_NONE`` - *Ignore* tag check faults +- ``PR_MTE_TCF_NONE`` - *Ignore* tag check faults + (ignored if combined with other options) - ``PR_MTE_TCF_SYNC`` - *Synchronous* tag check fault mode - ``PR_MTE_TCF_ASYNC`` - *Asynchronous* tag check fault mode +If no modes are specified, tag check faults are ignored. If a single +mode is specified, the program will run in that mode. If multiple +modes are specified, the mode is selected as described in the "Per-CPU +preferred tag checking modes" section below. + The current tag check fault mode can be read using the ``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call. @@ -120,13 +126,39 @@ in the ``PR_MTE_TAG_MASK`` bit-field. interface provides an include mask. An include mask of ``0`` (exclusion mask ``0xffff``) results in the CPU always generating tag ``0``. +Per-CPU preferred tag checking mode +----------------------------------- + +On some CPUs the performance of MTE in stricter tag checking modes +is similar to that of less strict tag checking modes. This makes it +worthwhile to enable stricter checks on those CPUs when a less strict +checking mode is requested, in order to gain the error detection +benefits of the stricter checks without the performance downsides. To +support this scenario, a privileged user may configure a stricter +tag checking mode as the CPU's preferred tag checking mode. + +The preferred tag checking mode for each CPU is controlled by +``/sys/devices/system/cpu/cpu<N>/mte_tcf_preferred``, to which a +privileged user may write the value ``async`` or ``sync``. The default +preferred mode for each CPU is ``async``. + +To allow a program to potentially run in the CPU's preferred tag +checking mode, the user program may set multiple tag check fault mode +bits in the ``flags`` argument to the ``prctl(PR_SET_TAGGED_ADDR_CTRL, +flags, 0, 0, 0)`` system call. If the CPU's preferred tag checking +mode is in the task's set of provided tag checking modes (this will +always be the case at present because the kernel only supports two +tag checking modes, but future kernels may support more modes), that +mode will be selected. Otherwise, one of the modes in the task's mode +set will be selected in a currently unspecified manner. + Initial process state --------------------- On ``execve()``, the new process has the following configuration: - ``PR_TAGGED_ADDR_ENABLE`` set to 0 (disabled) -- Tag checking mode set to ``PR_MTE_TCF_NONE`` +- No tag checking modes are selected (tag check faults ignored) - ``PR_MTE_TAG_MASK`` set to 0 (all tags excluded) - ``PSTATE.TCO`` set to 0 - ``PROT_MTE`` not set on any of the initial memory maps @@ -251,11 +283,13 @@ Example of correct usage return EXIT_FAILURE; /* - * Enable the tagged address ABI, synchronous MTE tag check faults and - * allow all non-zero tags in the randomly generated set. + * Enable the tagged address ABI, synchronous or asynchronous MTE + * tag check faults (based on per-CPU preference) and allow all + * non-zero tags in the randomly generated set. */ if (prctl(PR_SET_TAGGED_ADDR_CTRL, - PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | (0xfffe << PR_MTE_TAG_SHIFT), + PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC | + (0xfffe << PR_MTE_TAG_SHIFT), 0, 0, 0)) { perror("prctl() failed"); return EXIT_FAILURE; diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst index 459e6b66ff68..0c9120ec58ae 100644 --- a/Documentation/arm64/tagged-address-abi.rst +++ b/Documentation/arm64/tagged-address-abi.rst @@ -45,14 +45,24 @@ how the user addresses are used by the kernel: 1. User addresses not accessed by the kernel but used for address space management (e.g. ``mprotect()``, ``madvise()``). The use of valid - tagged pointers in this context is allowed with the exception of - ``brk()``, ``mmap()`` and the ``new_address`` argument to - ``mremap()`` as these have the potential to alias with existing - user addresses. - - NOTE: This behaviour changed in v5.6 and so some earlier kernels may - incorrectly accept valid tagged pointers for the ``brk()``, - ``mmap()`` and ``mremap()`` system calls. + tagged pointers in this context is allowed with these exceptions: + + - ``brk()``, ``mmap()`` and the ``new_address`` argument to + ``mremap()`` as these have the potential to alias with existing + user addresses. + + NOTE: This behaviour changed in v5.6 and so some earlier kernels may + incorrectly accept valid tagged pointers for the ``brk()``, + ``mmap()`` and ``mremap()`` system calls. + + - The ``range.start``, ``start`` and ``dst`` arguments to the + ``UFFDIO_*`` ``ioctl()``s used on a file descriptor obtained from + ``userfaultfd()``, as fault addresses subsequently obtained by reading + the file descriptor will be untagged, which may otherwise confuse + tag-unaware programs. + + NOTE: This behaviour changed in v5.14 and so some earlier kernels may + incorrectly accept valid tagged pointers for this system call. 2. User addresses accessed by the kernel (e.g. ``write()``). This ABI relaxation is disabled by default and the application thread needs to diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt index 0f1fdedf36bb..0f1ffa03db09 100644 --- a/Documentation/atomic_t.txt +++ b/Documentation/atomic_t.txt @@ -271,3 +271,97 @@ WRITE_ONCE. Thus: SC *y, t; is allowed. + + +CMPXCHG vs TRY_CMPXCHG +---------------------- + + int atomic_cmpxchg(atomic_t *ptr, int old, int new); + bool atomic_try_cmpxchg(atomic_t *ptr, int *oldp, int new); + +Both provide the same functionality, but try_cmpxchg() can lead to more +compact code. The functions relate like: + + bool atomic_try_cmpxchg(atomic_t *ptr, int *oldp, int new) + { + int ret, old = *oldp; + ret = atomic_cmpxchg(ptr, old, new); + if (ret != old) + *oldp = ret; + return ret == old; + } + +and: + + int atomic_cmpxchg(atomic_t *ptr, int old, int new) + { + (void)atomic_try_cmpxchg(ptr, &old, new); + return old; + } + +Usage: + + old = atomic_read(&v); old = atomic_read(&v); + for (;;) { do { + new = func(old); new = func(old); + tmp = atomic_cmpxchg(&v, old, new); } while (!atomic_try_cmpxchg(&v, &old, new)); + if (tmp == old) + break; + old = tmp; + } + +NB. try_cmpxchg() also generates better code on some platforms (notably x86) +where the function more closely matches the hardware instruction. + + +FORWARD PROGRESS +---------------- + +In general strong forward progress is expected of all unconditional atomic +operations -- those in the Arithmetic and Bitwise classes and xchg(). However +a fair amount of code also requires forward progress from the conditional +atomic operations. + +Specifically 'simple' cmpxchg() loops are expected to not starve one another +indefinitely. However, this is not evident on LL/SC architectures, because +while an LL/SC architecure 'can/should/must' provide forward progress +guarantees between competing LL/SC sections, such a guarantee does not +transfer to cmpxchg() implemented using LL/SC. Consider: + + old = atomic_read(&v); + do { + new = func(old); + } while (!atomic_try_cmpxchg(&v, &old, new)); + +which on LL/SC becomes something like: + + old = atomic_read(&v); + do { + new = func(old); + } while (!({ + volatile asm ("1: LL %[oldval], %[v]\n" + " CMP %[oldval], %[old]\n" + " BNE 2f\n" + " SC %[new], %[v]\n" + " BNE 1b\n" + "2:\n" + : [oldval] "=&r" (oldval), [v] "m" (v) + : [old] "r" (old), [new] "r" (new) + : "memory"); + success = (oldval == old); + if (!success) + old = oldval; + success; })); + +However, even the forward branch from the failed compare can cause the LL/SC +to fail on some architectures, let alone whatever the compiler makes of the C +loop body. As a result there is no guarantee what so ever the cacheline +containing @v will stay on the local CPU and progress is made. + +Even native CAS architectures can fail to provide forward progress for their +primitive (See Sparc64 for an example). + +Such implementations are strongly encouraged to add exponential backoff loops +to a failed CAS in order to ensure some progress. Affected architectures are +also strongly encouraged to inspect/audit the atomic fallbacks, refcount_t and +their locking primitives. diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index baea6c2abba5..1ceb5d704a97 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -15,15 +15,7 @@ that goes into great technical depth about the BPF Architecture. libbpf ====== -Libbpf is a userspace library for loading and interacting with bpf programs. - -.. toctree:: - :maxdepth: 1 - - libbpf/libbpf - libbpf/libbpf_api - libbpf/libbpf_build - libbpf/libbpf_naming_convention +Documentation/bpf/libbpf/libbpf.rst is a userspace library for loading and interacting with bpf programs. BPF Type Format (BTF) ===================== diff --git a/Documentation/bpf/libbpf/libbpf.rst b/Documentation/bpf/libbpf/index.rst index 1b1e61d5ead1..4f8adfc3ab83 100644 --- a/Documentation/bpf/libbpf/libbpf.rst +++ b/Documentation/bpf/libbpf/index.rst @@ -3,6 +3,14 @@ libbpf ====== +For API documentation see the `versioned API documentation site <https://libbpf.readthedocs.io/en/latest/api.html>`_. + +.. toctree:: + :maxdepth: 1 + + libbpf_naming_convention + libbpf_build + This is documentation for libbpf, a userspace library for loading and interacting with bpf programs. diff --git a/Documentation/bpf/libbpf/libbpf_api.rst b/Documentation/bpf/libbpf/libbpf_api.rst deleted file mode 100644 index f07eecd054da..000000000000 --- a/Documentation/bpf/libbpf/libbpf_api.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) - -API -=== - -This documentation is autogenerated from header files in libbpf, tools/lib/bpf - -.. kernel-doc:: tools/lib/bpf/libbpf.h - :internal: - -.. kernel-doc:: tools/lib/bpf/bpf.h - :internal: - -.. kernel-doc:: tools/lib/bpf/btf.h - :internal: - -.. kernel-doc:: tools/lib/bpf/xsk.h - :internal: - -.. kernel-doc:: tools/lib/bpf/bpf_tracing.h - :internal: - -.. kernel-doc:: tools/lib/bpf/bpf_core_read.h - :internal: - -.. kernel-doc:: tools/lib/bpf/bpf_endian.h - :internal:
\ No newline at end of file diff --git a/Documentation/bpf/libbpf/libbpf_naming_convention.rst b/Documentation/bpf/libbpf/libbpf_naming_convention.rst index 3de1d51e41da..9c68d5014ff1 100644 --- a/Documentation/bpf/libbpf/libbpf_naming_convention.rst +++ b/Documentation/bpf/libbpf/libbpf_naming_convention.rst @@ -69,7 +69,7 @@ functions. These can be mixed and matched. Note that these functions are not reentrant for performance reasons. ABI -========== +--- libbpf can be both linked statically or used as DSO. To avoid possible conflicts with other libraries an application is linked with, all @@ -108,7 +108,7 @@ This bump in ABI version is at most once per kernel development cycle. For example, if current state of ``libbpf.map`` is: -.. code-block:: c +.. code-block:: none LIBBPF_0.0.1 { global: @@ -121,7 +121,7 @@ For example, if current state of ``libbpf.map`` is: , and a new symbol ``bpf_func_c`` is being introduced, then ``libbpf.map`` should be changed like this: -.. code-block:: c +.. code-block:: none LIBBPF_0.0.1 { global: diff --git a/Documentation/core-api/cachetlb.rst b/Documentation/core-api/cachetlb.rst index fe4290e26729..8aed9103e48a 100644 --- a/Documentation/core-api/cachetlb.rst +++ b/Documentation/core-api/cachetlb.rst @@ -271,10 +271,15 @@ maps this page at its virtual address. ``void flush_dcache_page(struct page *page)`` - Any time the kernel writes to a page cache page, _OR_ - the kernel is about to read from a page cache page and - user space shared/writable mappings of this page potentially - exist, this routine is called. + This routines must be called when: + + a) the kernel did write to a page that is in the page cache page + and / or in high memory + b) the kernel is about to read from a page cache page and user space + shared/writable mappings of this page potentially exist. Note + that {get,pin}_user_pages{_fast} already call flush_dcache_page + on any page found in the user address space and thus driver + code rarely needs to take this into account. .. note:: @@ -284,38 +289,34 @@ maps this page at its virtual address. handling vfs symlinks in the page cache need not call this interface at all. - The phrase "kernel writes to a page cache page" means, - specifically, that the kernel executes store instructions - that dirty data in that page at the page->virtual mapping - of that page. It is important to flush here to handle - D-cache aliasing, to make sure these kernel stores are - visible to user space mappings of that page. - - The corollary case is just as important, if there are users - which have shared+writable mappings of this file, we must make - sure that kernel reads of these pages will see the most recent - stores done by the user. - - If D-cache aliasing is not an issue, this routine may - simply be defined as a nop on that architecture. - - There is a bit set aside in page->flags (PG_arch_1) as - "architecture private". The kernel guarantees that, - for pagecache pages, it will clear this bit when such - a page first enters the pagecache. - - This allows these interfaces to be implemented much more - efficiently. It allows one to "defer" (perhaps indefinitely) - the actual flush if there are currently no user processes - mapping this page. See sparc64's flush_dcache_page and - update_mmu_cache implementations for an example of how to go - about doing this. - - The idea is, first at flush_dcache_page() time, if - page->mapping->i_mmap is an empty tree, just mark the architecture - private page flag bit. Later, in update_mmu_cache(), a check is - made of this flag bit, and if set the flush is done and the flag - bit is cleared. + The phrase "kernel writes to a page cache page" means, specifically, + that the kernel executes store instructions that dirty data in that + page at the page->virtual mapping of that page. It is important to + flush here to handle D-cache aliasing, to make sure these kernel stores + are visible to user space mappings of that page. + + The corollary case is just as important, if there are users which have + shared+writable mappings of this file, we must make sure that kernel + reads of these pages will see the most recent stores done by the user. + + If D-cache aliasing is not an issue, this routine may simply be defined + as a nop on that architecture. + + There is a bit set aside in page->flags (PG_arch_1) as "architecture + private". The kernel guarantees that, for pagecache pages, it will + clear this bit when such a page first enters the pagecache. + + This allows these interfaces to be implemented much more efficiently. + It allows one to "defer" (perhaps indefinitely) the actual flush if + there are currently no user processes mapping this page. See sparc64's + flush_dcache_page and update_mmu_cache implementations for an example + of how to go about doing this. + + The idea is, first at flush_dcache_page() time, if page_file_mapping() + returns a mapping, and mapping_mapped on that mapping returns %false, + just mark the architecture private page flag bit. Later, in + update_mmu_cache(), a check is made of this flag bit, and if set the + flush is done and the flag bit is cleared. .. important:: @@ -351,19 +352,6 @@ maps this page at its virtual address. architectures). For incoherent architectures, it should flush the cache of the page at vmaddr. - ``void flush_kernel_dcache_page(struct page *page)`` - - When the kernel needs to modify a user page is has obtained - with kmap, it calls this function after all modifications are - complete (but before kunmapping it) to bring the underlying - page up to date. It is assumed here that the user has no - incoherent cached copies (i.e. the original page was obtained - from a mechanism like get_user_pages()). The default - implementation is a nop and should remain so on all coherent - architectures. On incoherent architectures, this should flush - the kernel cache for page (using page_address(page)). - - ``void flush_icache_range(unsigned long start, unsigned long end)`` When the kernel stores into addresses that it will execute diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst index 0c872cbea7d5..b66e3cae1472 100644 --- a/Documentation/core-api/cpu_hotplug.rst +++ b/Documentation/core-api/cpu_hotplug.rst @@ -226,7 +226,7 @@ goes online (offline) and during initial setup (shutdown) of the driver. However each registration and removal function is also available with a ``_nocalls`` suffix which does not invoke the provided callbacks if the invocation of the callbacks is not desired. During the manual setup (or teardown) the functions -``get_online_cpus()`` and ``put_online_cpus()`` should be used to inhibit CPU +``cpus_read_lock()`` and ``cpus_read_unlock()`` should be used to inhibit CPU hotplug operations. diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst index 53283b3729a1..6979b4af2c1f 100644 --- a/Documentation/core-api/irq/irq-domain.rst +++ b/Documentation/core-api/irq/irq-domain.rst @@ -55,8 +55,24 @@ exist then it will allocate a new Linux irq_desc, associate it with the hwirq, and call the .map() callback so the driver can perform any required hardware setup. -When an interrupt is received, irq_find_mapping() function should -be used to find the Linux IRQ number from the hwirq number. +Once a mapping has been established, it can be retrieved or used via a +variety of methods: + +- irq_resolve_mapping() returns a pointer to the irq_desc structure + for a given domain and hwirq number, and NULL if there was no + mapping. +- irq_find_mapping() returns a Linux IRQ number for a given domain and + hwirq number, and 0 if there was no mapping +- irq_linear_revmap() is now identical to irq_find_mapping(), and is + deprecated +- generic_handle_domain_irq() handles an interrupt described by a + domain and a hwirq number +- handle_domain_irq() does the same thing for root interrupt + controllers and deals with the set_irq_reg()/irq_enter() sequences + that most architecture requires + +Note that irq domain lookups must happen in contexts that are +compatible with a RCU read-side critical section. The irq_create_mapping() function must be called *atleast once* before any call to irq_find_mapping(), lest the descriptor will not @@ -137,7 +153,9 @@ required. Calling irq_create_direct_mapping() will allocate a Linux IRQ number and call the .map() callback so that driver can program the Linux IRQ number into the hardware. -Most drivers cannot use this mapping. +Most drivers cannot use this mapping, and it is now gated on the +CONFIG_IRQ_DOMAIN_NOMAP option. Please refrain from introducing new +users of this API. Legacy ------ @@ -157,6 +175,10 @@ for IRQ numbers that are passed to struct device registrations. In that case the Linux IRQ numbers cannot be dynamically assigned and the legacy mapping should be used. +As the name implies, the *_legacy() functions are deprecated and only +exist to ease the support of ancient platforms. No new users should be +added. + The legacy map assumes a contiguous range of IRQ numbers has already been allocated for the controller and that the IRQ number can be calculated by adding a fixed offset to the hwirq number, and diff --git a/Documentation/core-api/printk-basics.rst b/Documentation/core-api/printk-basics.rst index 965e4281eddd..2dde24ca7d9f 100644 --- a/Documentation/core-api/printk-basics.rst +++ b/Documentation/core-api/printk-basics.rst @@ -107,9 +107,6 @@ also ``CONFIG_DYNAMIC_DEBUG`` in the case of pr_debug()) is defined. Function reference ================== -.. kernel-doc:: kernel/printk/printk.c - :functions: printk - .. kernel-doc:: include/linux/printk.h - :functions: pr_emerg pr_alert pr_crit pr_err pr_warn pr_notice pr_info + :functions: printk pr_emerg pr_alert pr_crit pr_err pr_warn pr_notice pr_info pr_fmt pr_debug pr_devel pr_cont diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index 83ec4a556c19..21dc03bc10a4 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -181,9 +181,16 @@ By default, KASAN prints a bug report only for the first invalid memory access. With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This effectively disables ``panic_on_warn`` for KASAN reports. +Alternatively, independent of ``panic_on_warn`` the ``kasan.fault=`` boot +parameter can be used to control panic and reporting behaviour: + +- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN + report or also panic the kernel (default: ``report``). The panic happens even + if ``kasan_multi_shot`` is enabled. + Hardware tag-based KASAN mode (see the section about various modes below) is intended for use in production as a security mitigation. Therefore, it supports -boot parameters that allow disabling KASAN or controlling its features. +additional boot parameters that allow disabling KASAN or controlling features: - ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``). @@ -199,10 +206,6 @@ boot parameters that allow disabling KASAN or controlling its features. - ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack traces collection (default: ``on``). -- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN - report or also panic the kernel (default: ``report``). The panic happens even - if ``kasan_multi_shot`` is enabled. - Implementation details ---------------------- diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index 6a600cf8430b..7db43c7c09b8 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -127,6 +127,18 @@ Kconfig options: causes KCSAN to not report data races due to conflicts where the only plain accesses are aligned writes up to word size. +* ``CONFIG_KCSAN_PERMISSIVE``: Enable additional permissive rules to ignore + certain classes of common data races. Unlike the above, the rules are more + complex involving value-change patterns, access type, and address. This + option depends on ``CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=y``. For details + please see the ``kernel/kcsan/permissive.h``. Testers and maintainers that + only focus on reports from specific subsystems and not the whole kernel are + recommended to disable this option. + +To use the strictest possible rules, select ``CONFIG_KCSAN_STRICT=y``, which +configures KCSAN to follow the Linux-kernel memory consistency model (LKMM) as +closely as possible. + DebugFS interface ~~~~~~~~~~~~~~~~~ diff --git a/Documentation/dev-tools/kfence.rst b/Documentation/dev-tools/kfence.rst index fdf04e741ea5..0fbe3308bf37 100644 --- a/Documentation/dev-tools/kfence.rst +++ b/Documentation/dev-tools/kfence.rst @@ -65,25 +65,27 @@ Error reports A typical out-of-bounds access looks like this:: ================================================================== - BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0xa3/0x22b + BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0xa6/0x234 - Out-of-bounds read at 0xffffffffb672efff (1B left of kfence-#17): - test_out_of_bounds_read+0xa3/0x22b - kunit_try_run_case+0x51/0x85 + Out-of-bounds read at 0xffff8c3f2e291fff (1B left of kfence-#72): + test_out_of_bounds_read+0xa6/0x234 + kunit_try_run_case+0x61/0xa0 kunit_generic_run_threadfn_adapter+0x16/0x30 - kthread+0x137/0x160 + kthread+0x176/0x1b0 ret_from_fork+0x22/0x30 - kfence-#17 [0xffffffffb672f000-0xffffffffb672f01f, size=32, cache=kmalloc-32] allocated by task 507: - test_alloc+0xf3/0x25b - test_out_of_bounds_read+0x98/0x22b - kunit_try_run_case+0x51/0x85 + kfence-#72: 0xffff8c3f2e292000-0xffff8c3f2e29201f, size=32, cache=kmalloc-32 + + allocated by task 484 on cpu 0 at 32.919330s: + test_alloc+0xfe/0x738 + test_out_of_bounds_read+0x9b/0x234 + kunit_try_run_case+0x61/0xa0 kunit_generic_run_threadfn_adapter+0x16/0x30 - kthread+0x137/0x160 + kthread+0x176/0x1b0 ret_from_fork+0x22/0x30 - CPU: 4 PID: 107 Comm: kunit_try_catch Not tainted 5.8.0-rc6+ #7 - Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014 + CPU: 0 PID: 484 Comm: kunit_try_catch Not tainted 5.13.0-rc3+ #7 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 ================================================================== The header of the report provides a short summary of the function involved in @@ -96,30 +98,32 @@ Use-after-free accesses are reported as:: ================================================================== BUG: KFENCE: use-after-free read in test_use_after_free_read+0xb3/0x143 - Use-after-free read at 0xffffffffb673dfe0 (in kfence-#24): + Use-after-free read at 0xffff8c3f2e2a0000 (in kfence-#79): test_use_after_free_read+0xb3/0x143 - kunit_try_run_case+0x51/0x85 + kunit_try_run_case+0x61/0xa0 kunit_generic_run_threadfn_adapter+0x16/0x30 - kthread+0x137/0x160 + kthread+0x176/0x1b0 ret_from_fork+0x22/0x30 - kfence-#24 [0xffffffffb673dfe0-0xffffffffb673dfff, size=32, cache=kmalloc-32] allocated by task 507: - test_alloc+0xf3/0x25b + kfence-#79: 0xffff8c3f2e2a0000-0xffff8c3f2e2a001f, size=32, cache=kmalloc-32 + + allocated by task 488 on cpu 2 at 33.871326s: + test_alloc+0xfe/0x738 test_use_after_free_read+0x76/0x143 - kunit_try_run_case+0x51/0x85 + kunit_try_run_case+0x61/0xa0 kunit_generic_run_threadfn_adapter+0x16/0x30 - kthread+0x137/0x160 + kthread+0x176/0x1b0 ret_from_fork+0x22/0x30 - freed by task 507: + freed by task 488 on cpu 2 at 33.871358s: test_use_after_free_read+0xa8/0x143 - kunit_try_run_case+0x51/0x85 + kunit_try_run_case+0x61/0xa0 kunit_generic_run_threadfn_adapter+0x16/0x30 - kthread+0x137/0x160 + kthread+0x176/0x1b0 ret_from_fork+0x22/0x30 - CPU: 4 PID: 109 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7 - Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014 + CPU: 2 PID: 488 Comm: kunit_try_catch Tainted: G B 5.13.0-rc3+ #7 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 ================================================================== KFENCE also reports on invalid frees, such as double-frees:: @@ -127,30 +131,32 @@ KFENCE also reports on invalid frees, such as double-frees:: ================================================================== BUG: KFENCE: invalid free in test_double_free+0xdc/0x171 - Invalid free of 0xffffffffb6741000: + Invalid free of 0xffff8c3f2e2a4000 (in kfence-#81): test_double_free+0xdc/0x171 - kunit_try_run_case+0x51/0x85 + kunit_try_run_case+0x61/0xa0 kunit_generic_run_threadfn_adapter+0x16/0x30 - kthread+0x137/0x160 + kthread+0x176/0x1b0 ret_from_fork+0x22/0x30 - kfence-#26 [0xffffffffb6741000-0xffffffffb674101f, size=32, cache=kmalloc-32] allocated by task 507: - test_alloc+0xf3/0x25b + kfence-#81: 0xffff8c3f2e2a4000-0xffff8c3f2e2a401f, size=32, cache=kmalloc-32 + + allocated by task 490 on cpu 1 at 34.175321s: + test_alloc+0xfe/0x738 test_double_free+0x76/0x171 - kunit_try_run_case+0x51/0x85 + kunit_try_run_case+0x61/0xa0 kunit_generic_run_threadfn_adapter+0x16/0x30 - kthread+0x137/0x160 + kthread+0x176/0x1b0 ret_from_fork+0x22/0x30 - freed by task 507: + freed by task 490 on cpu 1 at 34.175348s: test_double_free+0xa8/0x171 - kunit_try_run_case+0x51/0x85 + kunit_try_run_case+0x61/0xa0 kunit_generic_run_threadfn_adapter+0x16/0x30 - kthread+0x137/0x160 + kthread+0x176/0x1b0 ret_from_fork+0x22/0x30 - CPU: 4 PID: 111 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7 - Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014 + CPU: 1 PID: 490 Comm: kunit_try_catch Tainted: G B 5.13.0-rc3+ #7 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 ================================================================== KFENCE also uses pattern-based redzones on the other side of an object's guard @@ -160,23 +166,25 @@ These are reported on frees:: ================================================================== BUG: KFENCE: memory corruption in test_kmalloc_aligned_oob_write+0xef/0x184 - Corrupted memory at 0xffffffffb6797ff9 [ 0xac . . . . . . ] (in kfence-#69): + Corrupted memory at 0xffff8c3f2e33aff9 [ 0xac . . . . . . ] (in kfence-#156): test_kmalloc_aligned_oob_write+0xef/0x184 - kunit_try_run_case+0x51/0x85 + kunit_try_run_case+0x61/0xa0 kunit_generic_run_threadfn_adapter+0x16/0x30 - kthread+0x137/0x160 + kthread+0x176/0x1b0 ret_from_fork+0x22/0x30 - kfence-#69 [0xffffffffb6797fb0-0xffffffffb6797ff8, size=73, cache=kmalloc-96] allocated by task 507: - test_alloc+0xf3/0x25b + kfence-#156: 0xffff8c3f2e33afb0-0xffff8c3f2e33aff8, size=73, cache=kmalloc-96 + + allocated by task 502 on cpu 7 at 42.159302s: + test_alloc+0xfe/0x738 test_kmalloc_aligned_oob_write+0x57/0x184 - kunit_try_run_case+0x51/0x85 + kunit_try_run_case+0x61/0xa0 kunit_generic_run_threadfn_adapter+0x16/0x30 - kthread+0x137/0x160 + kthread+0x176/0x1b0 ret_from_fork+0x22/0x30 - CPU: 4 PID: 120 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7 - Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014 + CPU: 7 PID: 502 Comm: kunit_try_catch Tainted: G B 5.13.0-rc3+ #7 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 ================================================================== For such errors, the address where the corruption occurred as well as the diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst index c7ff9afe407a..ae52e0f489f9 100644 --- a/Documentation/dev-tools/kunit/kunit-tool.rst +++ b/Documentation/dev-tools/kunit/kunit-tool.rst @@ -114,9 +114,12 @@ results in TAP format, you can pass the ``--raw_output`` argument. ./tools/testing/kunit/kunit.py run --raw_output -.. note:: - The raw output from test runs may contain other, non-KUnit kernel log - lines. +The raw output from test runs may contain other, non-KUnit kernel log +lines. You can see just KUnit output with ``--raw_output=kunit``: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run --raw_output=kunit If you have KUnit results in their raw TAP format, you can parse them and print the human-readable summary with the ``parse`` command for kunit_tool. This diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst index 7d99386cf94a..30d2147eb5b5 100644 --- a/Documentation/dev-tools/kunit/running_tips.rst +++ b/Documentation/dev-tools/kunit/running_tips.rst @@ -80,25 +80,23 @@ file ``.kunitconfig``, you can just pass in the dir, e.g. automagically, but tests could theoretically depend on incompatible options, so handling that would be tricky. +Setting kernel commandline parameters +------------------------------------- + +You can use ``--kernel_args`` to pass arbitrary kernel arguments, e.g. + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run --kernel_args=param=42 --kernel_args=param2=false + + Generating code coverage reports under UML ------------------------------------------ .. note:: TODO(brendanhiggins@google.com): There are various issues with UML and versions of gcc 7 and up. You're likely to run into missing ``.gcda`` - files or compile errors. We know one `faulty GCC commit - <https://github.com/gcc-mirror/gcc/commit/8c9434c2f9358b8b8bad2c1990edf10a21645f9d>`_ - but not how we'd go about getting this fixed. The compile errors still - need some investigation. - -.. note:: - TODO(brendanhiggins@google.com): for recent versions of Linux - (5.10-5.12, maybe earlier), there's a bug with gcov counters not being - flushed in UML. This translates to very low (<1%) reported coverage. This is - related to the above issue and can be worked around by replacing the - one call to ``uml_abort()`` (it's in ``os_dump_core()``) with a plain - ``exit()``. - + files or compile errors. This is different from the "normal" way of getting coverage information that is documented in Documentation/dev-tools/gcov.rst. diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index 5ccfed90cc70..a072e95de626 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -28,7 +28,7 @@ find_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \ quiet_cmd_yamllint = LINT $(src) cmd_yamllint = ($(find_cmd) | \ - xargs $(DT_SCHEMA_LINT) -f parsable -c $(srctree)/$(src)/.yamllint) || true + xargs $(DT_SCHEMA_LINT) -f parsable -c $(srctree)/$(src)/.yamllint >&2) || true quiet_cmd_chk_bindings = CHKDT $@ cmd_chk_bindings = ($(find_cmd) | \ diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml index 6fc5a22ad962..fba071b9af1d 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml @@ -146,6 +146,11 @@ properties: - const: atmel,sama5 - items: + - const: microchip,sama7g5ek # SAMA7G5 Evaluation Kit + - const: microchip,sama7g5 + - const: microchip,sama7 + + - items: - enum: - atmel,sams70j19 - atmel,sams70j20 diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index 807264a78edc..16eef600d599 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -45,7 +45,8 @@ RAMC SDRAM/DDR Controller required properties: "atmel,at91sam9260-sdramc", "atmel,at91sam9g45-ddramc", "atmel,sama5d3-ddramc", - "microchip,sam9x60-ddramc" + "microchip,sam9x60-ddramc", + "microchip,sama7g5-uddrc" - reg: Should contain registers location and length Examples: @@ -55,6 +56,17 @@ Examples: reg = <0xffffe800 0x200>; }; +RAMC PHY Controller required properties: +- compatible: Should be "microchip,sama7g5-ddr3phy", "syscon" +- reg: Should contain registers location and length + +Example: + + ddr3phy: ddr3phy@e3804000 { + compatible = "microchip,sama7g5-ddr3phy", "syscon"; + reg = <0xe3804000 0x1000>; +}; + SHDWC Shutdown Controller required properties: diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 1c827c1954dc..60f4862ba15e 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -221,9 +221,13 @@ properties: - prt,prti6q # Protonic PRTI6Q board - prt,prtwd2 # Protonic WD2 board - rex,imx6q-rex-pro # Rex Pro i.MX6 Quad Board + - skov,imx6q-skov-revc-lt2 # SKOV IMX6 CPU QuadCore lt2 + - skov,imx6q-skov-revc-lt6 # SKOV IMX6 CPU QuadCore lt6 + - skov,imx6q-skov-reve-mi1010ait-1cp1 # SKOV IMX6 CPU QuadCore mi1010ait-1cp1 - solidrun,cubox-i/q # SolidRun Cubox-i Dual/Quad - solidrun,hummingboard/q - solidrun,hummingboard2/q + - solidrun,solidsense/q # SolidRun SolidSense Dual/Quad - tbs,imx6q-tbs2910 # TBS2910 Matrix ARM mini PC - technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf - technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit @@ -377,9 +381,12 @@ properties: - prt,prtvt7 # Protonic VT7 board - rex,imx6dl-rex-basic # Rex Basic i.MX6 Dual Lite Board - riot,imx6s-riotboard # RIoTboard i.MX6S + - skov,imx6dl-skov-revc-lt2 # SKOV IMX6 CPU SoloCore lt2 + - skov,imx6dl-skov-revc-lt6 # SKOV IMX6 CPU SoloCore lt6 - solidrun,cubox-i/dl # SolidRun Cubox-i Solo/DualLite - solidrun,hummingboard/dl - solidrun,hummingboard2/dl # SolidRun HummingBoard2 Solo/DualLite + - solidrun,solidsense/dl # SolidRun SolidSense Solo/DualLite - technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf - technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit - technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph @@ -418,6 +425,12 @@ properties: - const: dfi,fs700e-m60 - const: fsl,imx6dl + - description: i.MX6DL DHCOM PicoITX Board + items: + - const: dh,imx6dl-dhcom-picoitx + - const: dh,imx6dl-dhcom-som + - const: fsl,imx6dl + - description: i.MX6DL Gateworks Ventana Boards items: - enum: @@ -469,6 +482,12 @@ properties: - const: toradex,colibri_imx6dl # Colibri iMX6 Module - const: fsl,imx6dl + - description: i.MX6S DHCOM DRC02 Board + items: + - const: dh,imx6s-dhcom-drc02 + - const: dh,imx6s-dhcom-som + - const: fsl,imx6dl + - description: i.MX6SL based Boards items: - enum: @@ -698,6 +717,7 @@ properties: - gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw73xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw7901 # i.MX8MM Gateworks Board + - gw,imx8mm-gw7902 # i.MX8MM Gateworks Board - kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM - variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module - const: fsl,imx8mm @@ -728,6 +748,7 @@ properties: - beacon,imx8mn-beacon-kit # i.MX8MN Beacon Development Kit - fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board - fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board + - gw,imx8mn-gw7902 # i.MX8MM Gateworks Board - const: fsl,imx8mn - description: Variscite VAR-SOM-MX8MN based boards @@ -752,10 +773,12 @@ properties: items: - enum: - boundary,imx8mq-nitrogen8m # i.MX8MQ NITROGEN Board + - boundary,imx8mq-nitrogen8m-som # i.MX8MQ NITROGEN SoM - einfochips,imx8mq-thor96 # i.MX8MQ Thor96 Board - fsl,imx8mq-evk # i.MX8MQ EVK Board - google,imx8mq-phanbell # Google Coral Edge TPU - kontron,pitx-imx8m # Kontron pITX-imx8m Board + - mntre,reform2 # MNT Reform2 Laptop - purism,librem5-devkit # Purism Librem5 devkit - solidrun,hummingboard-pulse # SolidRun Hummingboard Pulse - technexion,pico-pi-imx8m # TechNexion PICO-PI-8M evk @@ -973,6 +996,12 @@ properties: - fsl,s32v234-evb # S32V234-EVB2 Customer Evaluation Board - const: fsl,s32v234 + - description: Traverse LS1088A based Boards + items: + - enum: + - traverse,ten64 # Ten64 Networking Appliance / Board + - const: fsl,ls1088a + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/gemini.txt b/Documentation/devicetree/bindings/arm/gemini.txt deleted file mode 100644 index 55bf7ce96c44..000000000000 --- a/Documentation/devicetree/bindings/arm/gemini.txt +++ /dev/null @@ -1,108 +0,0 @@ -Cortina systems Gemini platforms - -The Gemini SoC is the project name for an ARMv4 FA525-based SoC originally -produced by Storlink Semiconductor around 2005. The company was renamed -later renamed Storm Semiconductor. The chip product name is Storlink SL3516. -It was derived from earlier products from Storm named SL3316 (Centroid) and -SL3512 (Bulverde). - -Storm Semiconductor was acquired by Cortina Systems in 2008 and the SoC was -produced and used for NAS and similar usecases. In 2014 Cortina Systems was -in turn acquired by Inphi, who seem to have discontinued this product family. - -Many of the IP blocks used in the SoC comes from Faraday Technology. - -Required properties (in root node): - compatible = "cortina,gemini"; - -Required nodes: - -- soc: the SoC should be represented by a simple bus encompassing all the - onchip devices, this is referred to as the soc bus node. - -- syscon: the soc bus node must have a system controller node pointing to the - global control registers, with the compatible string - "cortina,gemini-syscon", "syscon"; - - Required properties on the syscon: - - reg: syscon register location and size. - - #clock-cells: should be set to <1> - the system controller is also a - clock provider. - - #reset-cells: should be set to <1> - the system controller is also a - reset line provider. - - The clock sources have shorthand defines in the include file: - <dt-bindings/clock/cortina,gemini-clock.h> - - The reset lines have shorthand defines in the include file: - <dt-bindings/reset/cortina,gemini-reset.h> - -- timer: the soc bus node must have a timer node pointing to the SoC timer - block, with the compatible string "cortina,gemini-timer" - See: clocksource/cortina,gemini-timer.txt - -- interrupt-controller: the sob bus node must have an interrupt controller - node pointing to the SoC interrupt controller block, with the compatible - string "cortina,gemini-interrupt-controller" - See interrupt-controller/cortina,gemini-interrupt-controller.txt - -Example: - -/ { - model = "Foo Gemini Machine"; - compatible = "cortina,gemini"; - #address-cells = <1>; - #size-cells = <1>; - - memory { - device_type = "memory"; - reg = <0x00000000 0x8000000>; - }; - - soc { - #address-cells = <1>; - #size-cells = <1>; - ranges; - compatible = "simple-bus"; - interrupt-parent = <&intcon>; - - syscon: syscon@40000000 { - compatible = "cortina,gemini-syscon", "syscon"; - reg = <0x40000000 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - - uart0: serial@42000000 { - compatible = "ns16550a"; - reg = <0x42000000 0x100>; - resets = <&syscon GEMINI_RESET_UART>; - clocks = <&syscon GEMINI_CLK_UART>; - interrupts = <18 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - }; - - timer@43000000 { - compatible = "cortina,gemini-timer"; - reg = <0x43000000 0x1000>; - interrupt-parent = <&intcon>; - interrupts = <14 IRQ_TYPE_EDGE_FALLING>, /* Timer 1 */ - <15 IRQ_TYPE_EDGE_FALLING>, /* Timer 2 */ - <16 IRQ_TYPE_EDGE_FALLING>; /* Timer 3 */ - resets = <&syscon GEMINI_RESET_TIMER>; - /* APB clock or RTC clock */ - clocks = <&syscon GEMINI_CLK_APB>, - <&syscon GEMINI_CLK_RTC>; - clock-names = "PCLK", "EXTCLK"; - syscon = <&syscon>; - }; - - intcon: interrupt-controller@48000000 { - compatible = "cortina,gemini-interrupt-controller"; - reg = <0x48000000 0x1000>; - resets = <&syscon GEMINI_RESET_INTCON0>; - interrupt-controller; - #interrupt-cells = <2>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/arm/gemini.yaml b/Documentation/devicetree/bindings/arm/gemini.yaml new file mode 100644 index 000000000000..f6a0b675830f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/gemini.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/gemini.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cortina systems Gemini platforms + +description: | + The Gemini SoC is the project name for an ARMv4 FA525-based SoC originally + produced by Storlink Semiconductor around 2005. The company was renamed + later renamed Storm Semiconductor. The chip product name is Storlink SL3516. + It was derived from earlier products from Storm named SL3316 (Centroid) and + SL3512 (Bulverde). + + Storm Semiconductor was acquired by Cortina Systems in 2008 and the SoC was + produced and used for NAS and similar usecases. In 2014 Cortina Systems was + in turn acquired by Inphi, who seem to have discontinued this product family. + + Many of the IP blocks used in the SoC comes from Faraday Technology. + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +properties: + $nodename: + const: '/' + compatible: + oneOf: + + - description: Storlink Semiconductor Gemini324 EV-Board also known + as Storm Semiconductor SL93512R_BRD + items: + - const: storlink,gemini324 + - const: storm,sl93512r + - const: cortina,gemini + + - description: D-Link DIR-685 Xtreme N Storage Router + items: + - const: dlink,dir-685 + - const: cortina,gemini + + - description: D-Link DNS-313 1-Bay Network Storage Enclosure + items: + - const: dlink,dns-313 + - const: cortina,gemini + + - description: Edimax NS-2502 + items: + - const: edimax,ns-2502 + - const: cortina,gemini + + - description: ITian Square One SQ201 + items: + - const: itian,sq201 + - const: cortina,gemini + + - description: Raidsonic NAS IB-4220-B + items: + - const: raidsonic,ib-4220-b + - const: cortina,gemini + + - description: SSI 1328 + items: + - const: ssi,1328 + - const: cortina,gemini + + - description: Teltonika RUT1xx Mobile Router + items: + - const: teltonika,rut1xx + - const: cortina,gemini + + - description: Wiligear Wiliboard WBD-111 + items: + - const: wiligear,wiliboard-wbd111 + - const: cortina,gemini + + - description: Wiligear Wiliboard WBD-222 + items: + - const: wiligear,wiliboard-wbd222 + - const: cortina,gemini + + - description: Wiligear Wiliboard WBD-111 - old incorrect binding + items: + - const: wiliboard,wbd111 + - const: cortina,gemini + deprecated: true + + - description: Wiligear Wiliboard WBD-222 - old incorrect binding + items: + - const: wiliboard,wbd222 + - const: cortina,gemini + deprecated: true + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt index b32d374193c7..699776be1dd3 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt @@ -13,6 +13,7 @@ Required Properties: - "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon" - "mediatek,mt8167-audiosys", "syscon" - "mediatek,mt8183-audiosys", "syscon" + - "mediatek,mt8192-audsys", "syscon" - "mediatek,mt8516-audsys", "syscon" - #clock-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt deleted file mode 100644 index 78c50733985c..000000000000 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt +++ /dev/null @@ -1,31 +0,0 @@ -Mediatek mmsys controller -============================ - -The Mediatek mmsys system controller provides clock control, routing control, -and miscellaneous control in mmsys partition. - -Required Properties: - -- compatible: Should be one of: - - "mediatek,mt2701-mmsys", "syscon" - - "mediatek,mt2712-mmsys", "syscon" - - "mediatek,mt6765-mmsys", "syscon" - - "mediatek,mt6779-mmsys", "syscon" - - "mediatek,mt6797-mmsys", "syscon" - - "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon" - - "mediatek,mt8167-mmsys", "syscon" - - "mediatek,mt8173-mmsys", "syscon" - - "mediatek,mt8183-mmsys", "syscon" -- #clock-cells: Must be 1 - -For the clock control, the mmsys 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: - -mmsys: syscon@14000000 { - compatible = "mediatek,mt8173-mmsys", "syscon"; - reg = <0 0x14000000 0 0x1000>; - #clock-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml new file mode 100644 index 000000000000..f9ffa5b703a5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -0,0 +1,59 @@ +# 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#" + +title: MediaTek mmsys controller + +maintainers: + - Matthias Brugger <matthias.bgg@gmail.com> + +description: + The MediaTek mmsys system controller provides clock control, routing control, + and miscellaneous control in mmsys partition. + +properties: + $nodename: + pattern: "^syscon@[0-9a-f]+$" + + compatible: + oneOf: + - items: + - enum: + - mediatek,mt2701-mmsys + - mediatek,mt2712-mmsys + - mediatek,mt6765-mmsys + - mediatek,mt6779-mmsys + - mediatek,mt6797-mmsys + - mediatek,mt8167-mmsys + - mediatek,mt8173-mmsys + - mediatek,mt8183-mmsys + - mediatek,mt8192-mmsys + - mediatek,mt8365-mmsys + - const: syscon + - items: + - const: mediatek,mt7623-mmsys + - const: mediatek,mt2701-mmsys + - const: syscon + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + +required: + - compatible + - reg + - "#clock-cells" + +additionalProperties: false + +examples: + - | + mmsys: syscon@14000000 { + compatible = "mediatek,mt8173-mmsys", "syscon"; + reg = <0x14000000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml new file mode 100644 index 000000000000..c8c67c033f8c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml @@ -0,0 +1,199 @@ +# 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#" + +title: MediaTek Functional Clock Controller for MT8192 + +maintainers: + - Chun-Jie Chen <chun-jie.chen@mediatek.com> + +description: + The Mediatek functional clock controller provides various clocks on MT8192. + +properties: + compatible: + items: + - enum: + - mediatek,mt8192-scp_adsp + - mediatek,mt8192-imp_iic_wrap_c + - mediatek,mt8192-imp_iic_wrap_e + - mediatek,mt8192-imp_iic_wrap_s + - mediatek,mt8192-imp_iic_wrap_ws + - mediatek,mt8192-imp_iic_wrap_w + - mediatek,mt8192-imp_iic_wrap_n + - mediatek,mt8192-msdc_top + - mediatek,mt8192-msdc + - mediatek,mt8192-mfgcfg + - mediatek,mt8192-imgsys + - mediatek,mt8192-imgsys2 + - mediatek,mt8192-vdecsys_soc + - mediatek,mt8192-vdecsys + - mediatek,mt8192-vencsys + - mediatek,mt8192-camsys + - mediatek,mt8192-camsys_rawa + - mediatek,mt8192-camsys_rawb + - mediatek,mt8192-camsys_rawc + - mediatek,mt8192-ipesys + - mediatek,mt8192-mdpsys + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + scp_adsp: clock-controller@10720000 { + compatible = "mediatek,mt8192-scp_adsp"; + reg = <0x10720000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_c: clock-controller@11007000 { + compatible = "mediatek,mt8192-imp_iic_wrap_c"; + reg = <0x11007000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_e: clock-controller@11cb1000 { + compatible = "mediatek,mt8192-imp_iic_wrap_e"; + reg = <0x11cb1000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_s: clock-controller@11d03000 { + compatible = "mediatek,mt8192-imp_iic_wrap_s"; + reg = <0x11d03000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_ws: clock-controller@11d23000 { + compatible = "mediatek,mt8192-imp_iic_wrap_ws"; + reg = <0x11d23000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_w: clock-controller@11e01000 { + compatible = "mediatek,mt8192-imp_iic_wrap_w"; + reg = <0x11e01000 0x1000>; + #clock-cells = <1>; + }; + + - | + imp_iic_wrap_n: clock-controller@11f02000 { + compatible = "mediatek,mt8192-imp_iic_wrap_n"; + reg = <0x11f02000 0x1000>; + #clock-cells = <1>; + }; + + - | + msdc_top: clock-controller@11f10000 { + compatible = "mediatek,mt8192-msdc_top"; + reg = <0x11f10000 0x1000>; + #clock-cells = <1>; + }; + + - | + msdc: clock-controller@11f60000 { + compatible = "mediatek,mt8192-msdc"; + reg = <0x11f60000 0x1000>; + #clock-cells = <1>; + }; + + - | + mfgcfg: clock-controller@13fbf000 { + compatible = "mediatek,mt8192-mfgcfg"; + reg = <0x13fbf000 0x1000>; + #clock-cells = <1>; + }; + + - | + imgsys: clock-controller@15020000 { + compatible = "mediatek,mt8192-imgsys"; + reg = <0x15020000 0x1000>; + #clock-cells = <1>; + }; + + - | + imgsys2: clock-controller@15820000 { + compatible = "mediatek,mt8192-imgsys2"; + reg = <0x15820000 0x1000>; + #clock-cells = <1>; + }; + + - | + vdecsys_soc: clock-controller@1600f000 { + compatible = "mediatek,mt8192-vdecsys_soc"; + reg = <0x1600f000 0x1000>; + #clock-cells = <1>; + }; + + - | + vdecsys: clock-controller@1602f000 { + compatible = "mediatek,mt8192-vdecsys"; + reg = <0x1602f000 0x1000>; + #clock-cells = <1>; + }; + + - | + vencsys: clock-controller@17000000 { + compatible = "mediatek,mt8192-vencsys"; + reg = <0x17000000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys: clock-controller@1a000000 { + compatible = "mediatek,mt8192-camsys"; + reg = <0x1a000000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_rawa: clock-controller@1a04f000 { + compatible = "mediatek,mt8192-camsys_rawa"; + reg = <0x1a04f000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_rawb: clock-controller@1a06f000 { + compatible = "mediatek,mt8192-camsys_rawb"; + reg = <0x1a06f000 0x1000>; + #clock-cells = <1>; + }; + + - | + camsys_rawc: clock-controller@1a08f000 { + compatible = "mediatek,mt8192-camsys_rawc"; + reg = <0x1a08f000 0x1000>; + #clock-cells = <1>; + }; + + - | + ipesys: clock-controller@1b000000 { + compatible = "mediatek,mt8192-ipesys"; + reg = <0x1b000000 0x1000>; + #clock-cells = <1>; + }; + + - | + mdpsys: clock-controller@1f000000 { + compatible = "mediatek,mt8192-mdpsys"; + reg = <0x1f000000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml new file mode 100644 index 000000000000..5705bcf1fe47 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml @@ -0,0 +1,65 @@ +# 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#" + +title: MediaTek System Clock Controller for MT8192 + +maintainers: + - Chun-Jie Chen <chun-jie.chen@mediatek.com> + +description: + The Mediatek system clock controller provides various clocks and system configuration + like reset and bus protection on MT8192. + +properties: + compatible: + items: + - enum: + - mediatek,mt8192-topckgen + - mediatek,mt8192-infracfg + - mediatek,mt8192-pericfg + - mediatek,mt8192-apmixedsys + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + topckgen: syscon@10000000 { + compatible = "mediatek,mt8192-topckgen", "syscon"; + reg = <0x10000000 0x1000>; + #clock-cells = <1>; + }; + + - | + infracfg: syscon@10001000 { + compatible = "mediatek,mt8192-infracfg", "syscon"; + reg = <0x10001000 0x1000>; + #clock-cells = <1>; + }; + + - | + pericfg: syscon@10003000 { + compatible = "mediatek,mt8192-pericfg", "syscon"; + reg = <0x10003000 0x1000>; + #clock-cells = <1>; + }; + + - | + apmixedsys: syscon@1000c000 { + compatible = "mediatek,mt8192-apmixedsys", "syscon"; + reg = <0x1000c000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 9720b00c41d2..880ddafc634e 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -31,6 +31,7 @@ description: | ipq6018 ipq8074 mdm9615 + msm8226 msm8916 msm8974 msm8992 @@ -116,6 +117,11 @@ properties: - items: - enum: + - samsung,s3ve3g + - const: qcom,msm8226 + + - items: + - enum: - qcom,msm8960-cdp - const: qcom,msm8960 @@ -129,6 +135,8 @@ properties: - const: qcom,msm8974 - items: + - enum: + - alcatel,idol347 - const: qcom,msm8916-mtp/1 - const: qcom,msm8916-mtp - const: qcom,msm8916 @@ -181,6 +189,8 @@ properties: - items: - enum: - qcom,sc7280-idp + - qcom,sc7280-idp2 + - google,piglin - google,senor - const: qcom,sc7280 diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index a0cce4e25039..8a11918866b8 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -238,17 +238,29 @@ properties: - const: renesas,r8a77961 - description: Kingfisher (SBEV-RCAR-KF-M03) - items: - - const: shimafuji,kingfisher - - enum: - - renesas,h3ulcb - - renesas,m3ulcb - - renesas,m3nulcb - - enum: - - renesas,r8a7795 - - renesas,r8a7796 - - renesas,r8a77961 - - renesas,r8a77965 + oneOf: + - items: + - const: shimafuji,kingfisher + - enum: + - renesas,h3ulcb + - renesas,m3ulcb + - renesas,m3nulcb + - enum: + - renesas,r8a7795 + - renesas,r8a7796 + - renesas,r8a77961 + - renesas,r8a77965 + - items: + - const: shimafuji,kingfisher + - enum: + - renesas,h3ulcb + - renesas,m3ulcb + - enum: + - renesas,r8a779m1 + - renesas,r8a779m3 + - enum: + - renesas,r8a7795 + - renesas,r8a77961 - description: R-Car M3-N (R8A77965) items: @@ -296,6 +308,22 @@ properties: - const: renesas,falcon-cpu - const: renesas,r8a779a0 + - description: R-Car H3e-2G (R8A779M1) + items: + - enum: + - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier) + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version) + - const: renesas,r8a779m1 + - const: renesas,r8a7795 + + - description: R-Car M3e-2G (R8A779M3) + items: + - enum: + - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro) + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version) + - const: renesas,r8a779m3 + - const: renesas,r8a77961 + - description: RZ/N1D (R9A06G032) items: - enum: diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index b9f75e20fef5..b962fa6d649c 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -111,6 +111,7 @@ properties: - items: - enum: - nvidia,p2771-0000 + - nvidia,p3509-0000+p3636-0001 - const: nvidia,tegra186 - items: - enum: diff --git a/Documentation/devicetree/bindings/ata/exynos-sata.txt b/Documentation/devicetree/bindings/ata/exynos-sata.txt deleted file mode 100644 index cb48448247ea..000000000000 --- a/Documentation/devicetree/bindings/ata/exynos-sata.txt +++ /dev/null @@ -1,30 +0,0 @@ -* Samsung AHCI SATA Controller - -SATA nodes are defined to describe on-chip Serial ATA controllers. -Each SATA controller should have its own node. - -Required properties: -- compatible : compatible list, contains "samsung,exynos5-sata" -- interrupts : <interrupt mapping for SATA IRQ> -- reg : <registers mapping> -- samsung,sata-freq : <frequency in MHz> -- phys : Must contain exactly one entry as specified - in phy-bindings.txt -- phy-names : Must be "sata-phy" - -Optional properties: -- clocks : Must contain an entry for each entry in clock-names. -- clock-names : Shall be "sata" for the external SATA bus clock, - and "sclk_sata" for the internal controller clock. - -Example: - sata@122f0000 { - compatible = "snps,dwc-ahci"; - samsung,sata-freq = <66>; - reg = <0x122f0000 0x1ff>; - interrupts = <0 115 0>; - clocks = <&clock 277>, <&clock 143>; - clock-names = "sata", "sclk_sata"; - phys = <&sata_phy>; - phy-names = "sata-phy"; - }; diff --git a/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml b/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml new file mode 100644 index 000000000000..52e18600ecff --- /dev/null +++ b/Documentation/devicetree/bindings/ata/intel,ixp4xx-compact-flash.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/intel,ixp4xx-compact-flash.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel IXP4xx CompactFlash Card Controller + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + The IXP4xx network processors have a CompactFlash interface that presents + a CompactFlash card to the system as a true IDE (parallel ATA) device. The + device is always connected to the expansion bus of the IXP4xx SoCs using one + or two chip select areas and address translating logic on the board. The + node must be placed inside a chip select node on the IXP4xx expansion bus. + +properties: + compatible: + const: intel,ixp4xx-compact-flash + + reg: + items: + - description: Command interface registers + - description: Control interface registers + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: pata-common.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + bus@c4000000 { + compatible = "intel,ixp43x-expansion-bus-controller", "syscon"; + reg = <0xc4000000 0x1000>; + native-endian; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x01000000>, <1 0x0 0x51000000 0x01000000>; + dma-ranges = <0 0x0 0x50000000 0x01000000>, <1 0x0 0x51000000 0x01000000>; + ide@1,0 { + compatible = "intel,ixp4xx-compact-flash"; + reg = <1 0x00000000 0x1000>, <1 0x00040000 0x1000>; + interrupt-parent = <&gpio0>; + interrupts = <12 IRQ_TYPE_EDGE_RISING>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml b/Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml new file mode 100644 index 000000000000..5d02bd032a85 --- /dev/null +++ b/Documentation/devicetree/bindings/auxdisplay/arm,versatile-lcd.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/auxdisplay/arm,versatile-lcd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Versatile Character LCD + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + - Rob Herring <robh@kernel.org> + +description: + This binding defines the character LCD interface found on ARM Versatile AB + and PB reference platforms. + +properties: + compatible: + const: arm,versatile-lcd + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + lcd@10008000 { + compatible = "arm,versatile-lcd"; + reg = <0x10008000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/auxdisplay/arm-charlcd.txt b/Documentation/devicetree/bindings/auxdisplay/arm-charlcd.txt deleted file mode 100644 index e28e2aac47f1..000000000000 --- a/Documentation/devicetree/bindings/auxdisplay/arm-charlcd.txt +++ /dev/null @@ -1,18 +0,0 @@ -ARM Versatile Character LCD ------------------------------------------------------ -This binding defines the character LCD interface found on ARM Versatile AB -and PB reference platforms. - -Required properties: -- compatible : "arm,versatile-clcd" -- reg : Location and size of character LCD registers - -Optional properties: -- interrupts - single interrupt for character LCD. The character LCD can - operate in polled mode without an interrupt. - -Example: - lcd@10008000 { - compatible = "arm,versatile-lcd"; - reg = <0x10008000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml b/Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml new file mode 100644 index 000000000000..1899b23de7d1 --- /dev/null +++ b/Documentation/devicetree/bindings/auxdisplay/img,ascii-lcd.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/auxdisplay/img,ascii-lcd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASCII LCD displays on Imagination Technologies boards + +maintainers: + - Paul Burton <paulburton@kernel.org> + +properties: + compatible: + enum: + - img,boston-lcd + - mti,malta-lcd + - mti,sead3-lcd + + reg: + maxItems: 1 + + offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Offset in bytes to the LCD registers within the system controller + +required: + - compatible + +oneOf: + - required: + - reg + - required: + - offset + +if: + properties: + compatible: + contains: + const: img,boston-lcd +then: + required: + - reg +else: + required: + - offset + +additionalProperties: false + +examples: + - | + lcd: lcd@17fff000 { + compatible = "img,boston-lcd"; + reg = <0x17fff000 0x8>; + }; diff --git a/Documentation/devicetree/bindings/auxdisplay/img-ascii-lcd.txt b/Documentation/devicetree/bindings/auxdisplay/img-ascii-lcd.txt deleted file mode 100644 index b69bb68992fd..000000000000 --- a/Documentation/devicetree/bindings/auxdisplay/img-ascii-lcd.txt +++ /dev/null @@ -1,17 +0,0 @@ -Binding for ASCII LCD displays on Imagination Technologies boards - -Required properties: -- compatible : should be one of: - "img,boston-lcd" - "mti,malta-lcd" - "mti,sead3-lcd" - -Required properties for "img,boston-lcd": -- reg : memory region locating the device registers - -Required properties for "mti,malta-lcd" or "mti,sead3-lcd": -- regmap: phandle of the system controller containing the LCD registers -- offset: offset in bytes to the LCD registers within the system controller - -The layout of the registers & properties of the display are determined -from the compatible string, making this binding somewhat trivial. diff --git a/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml new file mode 100644 index 000000000000..5fb4e7bfa4da --- /dev/null +++ b/Documentation/devicetree/bindings/bus/intel,ixp4xx-expansion-bus-controller.yaml @@ -0,0 +1,168 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/intel,ixp4xx-expansion-bus-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel IXP4xx Expansion Bus Controller + +description: | + The IXP4xx expansion bus controller handles access to devices on the + memory-mapped expansion bus on the Intel IXP4xx family of system on chips, + including IXP42x, IXP43x, IXP45x and IXP46x. + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +properties: + $nodename: + pattern: '^bus@[0-9a-f]+$' + + compatible: + items: + - enum: + - intel,ixp42x-expansion-bus-controller + - intel,ixp43x-expansion-bus-controller + - intel,ixp45x-expansion-bus-controller + - intel,ixp46x-expansion-bus-controller + - const: syscon + + reg: + description: Control registers for the expansion bus, these are not + inside the memory range handled by the expansion bus. + maxItems: 1 + + native-endian: + $ref: /schemas/types.yaml#/definitions/flag + description: The IXP4xx has a peculiar MMIO access scheme, as it changes + the access pattern for words (swizzling) on the bus depending on whether + the SoC is running in big-endian or little-endian mode. Thus the + registers must always be accessed using native endianness. + + "#address-cells": + description: | + The first cell is the chip select number. + The second cell is the address offset within the bank. + const: 2 + + "#size-cells": + const: 1 + + ranges: true + dma-ranges: true + +patternProperties: + "^.*@[0-7],[0-9a-f]+$": + description: Devices attached to chip selects are represented as + subnodes. + type: object + + properties: + intel,ixp4xx-eb-t1: + description: Address timing, extend address phase with n cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 3 + + intel,ixp4xx-eb-t2: + description: Setup chip select timing, extend setup phase with n cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 3 + + intel,ixp4xx-eb-t3: + description: Strobe timing, extend strobe phase with n cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + + intel,ixp4xx-eb-t4: + description: Hold timing, extend hold phase with n cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 3 + + intel,ixp4xx-eb-t5: + description: Recovery timing, extend recovery phase with n cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + + intel,ixp4xx-eb-cycle-type: + description: The type of cycles to use on the expansion bus for this + chip select. 0 = Intel cycles, 1 = Motorola cycles, 2 = HPI cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + intel,ixp4xx-eb-byte-access-on-halfword: + description: Allow byte read access on half word devices. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + intel,ixp4xx-eb-hpi-hrdy-pol-high: + description: Set HPI HRDY polarity to active high when using HPI. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + intel,ixp4xx-eb-mux-address-and-data: + description: Multiplex address and data on the data bus. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + intel,ixp4xx-eb-ahb-split-transfers: + description: Enable AHB split transfers. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + intel,ixp4xx-eb-write-enable: + description: Enable write cycles. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + intel,ixp4xx-eb-byte-access: + description: Expansion bus uses only 8 bits. The default is to use + 16 bits. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + +required: + - compatible + - reg + - native-endian + - "#address-cells" + - "#size-cells" + - ranges + - dma-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + bus@50000000 { + compatible = "intel,ixp42x-expansion-bus-controller", "syscon"; + reg = <0xc4000000 0x28>; + native-endian; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x01000000>, + <1 0x0 0x51000000 0x01000000>; + dma-ranges = <0 0x0 0x50000000 0x01000000>, + <1 0x0 0x51000000 0x01000000>; + flash@0,0 { + compatible = "intel,ixp4xx-flash", "cfi-flash"; + bank-width = <2>; + reg = <0 0x00000000 0x1000000>; + intel,ixp4xx-eb-t3 = <3>; + intel,ixp4xx-eb-cycle-type = <0>; + intel,ixp4xx-eb-byte-access-on-halfword = <1>; + intel,ixp4xx-eb-write-enable = <1>; + intel,ixp4xx-eb-byte-access = <0>; + }; + serial@1,0 { + compatible = "exar,xr16l2551", "ns8250"; + reg = <1 0x00000000 0x10>; + interrupt-parent = <&gpio0>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + clock-frequency = <1843200>; + intel,ixp4xx-eb-t3 = <3>; + intel,ixp4xx-eb-cycle-type = <1>; + intel,ixp4xx-eb-write-enable = <1>; + intel,ixp4xx-eb-byte-access = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt index 45e79172a646..1cc3aa10dcb1 100644 --- a/Documentation/devicetree/bindings/chosen.txt +++ b/Documentation/devicetree/bindings/chosen.txt @@ -79,9 +79,9 @@ a different secondary CPU release mechanism) linux,usable-memory-range ------------------------- -This property (arm64 only) holds a base address and size, describing a -limited region in which memory may be considered available for use by -the kernel. Memory outside of this range is not available for use. +This property holds a base address and size, describing a limited region in +which memory may be considered available for use by the kernel. Memory outside +of this range is not available for use. This property describes a limitation: memory within this range is only valid when also described through another mechanism that the kernel @@ -106,9 +106,9 @@ respectively, of the root node. linux,elfcorehdr ---------------- -This property (currently used only on arm64) holds the memory range, -the address and the size, of the elf core header which mainly describes -the panicked kernel's memory layout as PT_LOAD segments of elf format. +This property holds the memory range, the address and the size, of the elf +core header which mainly describes the panicked kernel's memory layout as +PT_LOAD segments of elf format. e.g. / { diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml index 8dc7b404ee12..5ad147d265e6 100644 --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.yaml @@ -50,7 +50,6 @@ properties: reg: minItems: 1 - maxItems: 3 items: - description: base register - description: power register @@ -62,7 +61,7 @@ properties: maxItems: 1 '#clock-cells': - const: 1 + true clock-output-names: minItems: 1 @@ -75,6 +74,23 @@ allOf: contains: enum: - brcm,cygnus-armpll + - brcm,nsp-armpll + then: + properties: + '#clock-cells': + const: 0 + else: + properties: + '#clock-cells': + const: 1 + required: + - clock-output-names + - if: + properties: + compatible: + contains: + enum: + - brcm,cygnus-armpll - brcm,cygnus-genpll - brcm,cygnus-lcpll0 - brcm,cygnus-mipipll @@ -359,7 +375,6 @@ required: - reg - clocks - '#clock-cells' - - clock-output-names additionalProperties: false @@ -393,3 +408,10 @@ examples: clocks = <&osc2>; clock-output-names = "keypad", "adc/touch", "pwm"; }; + - | + arm_clk@0 { + #clock-cells = <0>; + compatible = "brcm,nsp-armpll"; + clocks = <&osc>; + reg = <0x0 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt deleted file mode 100644 index 6030afb10b5c..000000000000 --- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt +++ /dev/null @@ -1,103 +0,0 @@ -* Samsung Audio Subsystem Clock Controller - -The Samsung Audio Subsystem clock controller generates and supplies clocks -to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock -binding described here is applicable to all SoCs in Exynos family. - -Required Properties: - -- compatible: should be one of the following: - - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs. - - "samsung,exynos5250-audss-clock" - controller compatible with Exynos5250 - SoCs. - - "samsung,exynos5410-audss-clock" - controller compatible with Exynos5410 - SoCs. - - "samsung,exynos5420-audss-clock" - controller compatible with Exynos5420 - SoCs. -- reg: physical base address and length of the controller's register set. - -- #clock-cells: should be 1. - -- clocks: - - pll_ref: Fixed rate PLL reference clock, parent of mout_audss. "fin_pll" - is used if not specified. - - pll_in: Input PLL to the AudioSS block, parent of mout_audss. "fout_epll" - is used if not specified. - - cdclk: External i2s clock, parent of mout_i2s. "cdclk0" is used if not - specified. - - sclk_audio: Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if - not specified. - - sclk_pcm_in: PCM clock, parent of sclk_pcm. "sclk_pcm0" is used if not - specified. - -- clock-names: Aliases for the above clocks. They should be "pll_ref", - "pll_in", "cdclk", "sclk_audio", and "sclk_pcm_in" respectively. - -Optional Properties: - - - power-domains: a phandle to respective power domain node as described by - generic PM domain bindings (see power/power_domain.txt for more - information). - -The following is the list of clocks generated by the controller. Each clock is -assigned an identifier and client nodes use this identifier to specify the -clock which they consume. Some of the clocks are available only on a particular -Exynos4 SoC and this is specified where applicable. - -Provided clocks: - -Clock ID SoC (if specific) ------------------------------------------------ - -mout_audss 0 -mout_i2s 1 -dout_srp 2 -dout_aud_bus 3 -dout_i2s 4 -srp_clk 5 -i2s_bus 6 -sclk_i2s 7 -pcm_bus 8 -sclk_pcm 9 -adma 10 Exynos5420 - -Example 1: An example of a clock controller node using the default input - clock names is listed below. - -clock_audss: audss-clock-controller@3810000 { - compatible = "samsung,exynos5250-audss-clock"; - reg = <0x03810000 0x0C>; - #clock-cells = <1>; -}; - -Example 2: An example of a clock controller node with the input clocks - specified. - -clock_audss: audss-clock-controller@3810000 { - compatible = "samsung,exynos5250-audss-clock"; - reg = <0x03810000 0x0C>; - #clock-cells = <1>; - clocks = <&clock 1>, <&clock 7>, <&clock 138>, <&clock 160>, - <&ext_i2s_clk>; - clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in", "cdclk"; -}; - -Example 3: I2S controller node that consumes the clock generated by the clock - controller. Refer to the standard clock bindings for information - about 'clocks' and 'clock-names' property. - -i2s0: i2s@3830000 { - compatible = "samsung,i2s-v5"; - reg = <0x03830000 0x100>; - dmas = <&pdma0 10 - &pdma0 9 - &pdma0 8>; - dma-names = "tx", "rx", "tx-sec"; - clocks = <&clock_audss EXYNOS_I2S_BUS>, - <&clock_audss EXYNOS_I2S_BUS>, - <&clock_audss EXYNOS_SCLK_I2S>, - <&clock_audss EXYNOS_MOUT_AUDSS>, - <&clock_audss EXYNOS_MOUT_I2S>; - clock-names = "iis", "i2s_opclk0", "i2s_opclk1", - "mout_audss", "mout_i2s"; -}; diff --git a/Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt b/Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt deleted file mode 100644 index f6272dcd96f4..000000000000 --- a/Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Samsung Audio Subsystem Clock Controller - -The Samsung Audio Subsystem clock controller generates and supplies clocks -to Audio Subsystem block available in the S5PV210 and compatible SoCs. - -Required Properties: - -- compatible: should be "samsung,s5pv210-audss-clock". -- reg: physical base address and length of the controller's register set. - -- #clock-cells: should be 1. - -- clocks: - - hclk: AHB bus clock of the Audio Subsystem. - - xxti: Optional fixed rate PLL reference clock, parent of mout_audss. If - not specified (i.e. xusbxti is used for PLL reference), it is fixed to - a clock named "xxti". - - fout_epll: Input PLL to the AudioSS block, parent of mout_audss. - - iiscdclk0: Optional external i2s clock, parent of mout_i2s. If not - specified, it is fixed to a clock named "iiscdclk0". - - sclk_audio0: Audio bus clock, parent of mout_i2s. - -- clock-names: Aliases for the above clocks. They should be "hclk", - "xxti", "fout_epll", "iiscdclk0", and "sclk_audio0" respectively. - -All available clocks are defined as preprocessor macros in -dt-bindings/clock/s5pv210-audss-clk.h header and can be used in device -tree sources. - -Example: Clock controller node. - - clk_audss: clock-controller@c0900000 { - compatible = "samsung,s5pv210-audss-clock"; - reg = <0xc0900000 0x1000>; - #clock-cells = <1>; - clock-names = "hclk", "xxti", - "fout_epll", "sclk_audio0"; - clocks = <&clocks DOUT_HCLKP>, <&xxti>, - <&clocks FOUT_EPLL>, <&clocks SCLK_AUDIO0>; - }; - -Example: I2S controller node that consumes the clock generated by the clock - controller. Refer to the standard clock bindings for information - about 'clocks' and 'clock-names' property. - - i2s0: i2s@3830000 { - /* ... */ - clock-names = "iis", "i2s_opclk0", - "i2s_opclk1"; - clocks = <&clk_audss CLK_I2S>, <&clk_audss CLK_I2S>, - <&clk_audss CLK_DOUT_AUD_BUS>; - /* ... */ - }; diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt deleted file mode 100644 index 7441ed519f02..000000000000 --- a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt +++ /dev/null @@ -1,57 +0,0 @@ -* Samsung Exynos3250 Clock Controller - -The Exynos3250 clock controller generates and supplies clock to various -controllers within the Exynos3250 SoC. - -Required Properties: - -- compatible: should be one of the following. - - "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC. - - "samsung,exynos3250-cmu-dmc" - controller compatible with - Exynos3250 SoC for Dynamic Memory Controller domain. - - "samsung,exynos3250-cmu-isp" - ISP block clock controller compatible - with Exynos3250 SOC - -- reg: physical base address of the controller and length of memory mapped - region. - -- #clock-cells: should be 1. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. - -All available clocks are defined as preprocessor macros in -dt-bindings/clock/exynos3250.h header and can be used in device -tree sources. - -Example 1: Examples of clock controller nodes are listed below. - - cmu: clock-controller@10030000 { - compatible = "samsung,exynos3250-cmu"; - reg = <0x10030000 0x20000>; - #clock-cells = <1>; - }; - - cmu_dmc: clock-controller@105c0000 { - compatible = "samsung,exynos3250-cmu-dmc"; - reg = <0x105C0000 0x2000>; - #clock-cells = <1>; - }; - - cmu_isp: clock-controller@10048000 { - compatible = "samsung,exynos3250-cmu-isp"; - reg = <0x10048000 0x1000>; - #clock-cells = <1>; - }; - -Example 2: UART controller node that consumes the clock generated by the clock - controller. Refer to the standard clock bindings for information - about 'clocks' and 'clock-names' property. - - serial@13800000 { - compatible = "samsung,exynos4210-uart"; - reg = <0x13800000 0x100>; - interrupts = <0 109 0>; - clocks = <&cmu CLK_UART0>, <&cmu CLK_SCLK_UART0>; - clock-names = "uart", "clk_uart_baud0"; - }; diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt deleted file mode 100644 index 17bb11365354..000000000000 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt +++ /dev/null @@ -1,86 +0,0 @@ -* Samsung Exynos4 Clock Controller - -The Exynos4 clock controller generates and supplies clock to various controllers -within the Exynos4 SoC. The clock binding described here is applicable to all -SoC's in the Exynos4 family. - -Required Properties: - -- compatible: should be one of the following. - - "samsung,exynos4210-clock" - controller compatible with Exynos4210 SoC. - - "samsung,exynos4412-clock" - controller compatible with Exynos4412 SoC. - -- reg: physical base address of the controller and length of memory mapped - region. - -- #clock-cells: should be 1. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. - -All available clocks are defined as preprocessor macros in -dt-bindings/clock/exynos4.h header and can be used in device -tree sources. - -Example 1: An example of a clock controller node is listed below. - - clock: clock-controller@10030000 { - compatible = "samsung,exynos4210-clock"; - reg = <0x10030000 0x20000>; - #clock-cells = <1>; - }; - -Example 2: UART controller node that consumes the clock generated by the clock - controller. Refer to the standard clock bindings for information - about 'clocks' and 'clock-names' property. - - serial@13820000 { - compatible = "samsung,exynos4210-uart"; - reg = <0x13820000 0x100>; - interrupts = <0 54 0>; - clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>; - clock-names = "uart", "clk_uart_baud0"; - }; - -Exynos4412 SoC contains some additional clocks for FIMC-ISP (Camera ISP) -subsystem. Registers for those clocks are located in the ISP power domain. -Because those registers are also located in a different memory region than -the main clock controller, a separate clock controller has to be defined for -handling them. - -Required Properties: - -- compatible: should be "samsung,exynos4412-isp-clock". - -- reg: physical base address of the ISP clock controller and length of memory - mapped region. - -- #clock-cells: should be 1. - -- clocks: list of the clock controller input clock identifiers, - from common clock bindings, should point to CLK_ACLK200 and - CLK_ACLK400_MCUISP clocks from the main clock controller. - -- clock-names: list of the clock controller input clock names, - as described in clock-bindings.txt, should be "aclk200" and - "aclk400_mcuisp". - -- power-domains: a phandle to ISP power domain node as described by - generic PM domain bindings. - -Example 3: The clock controllers bindings for Exynos4412 SoCs. - - clock: clock-controller@10030000 { - compatible = "samsung,exynos4412-clock"; - reg = <0x10030000 0x18000>; - #clock-cells = <1>; - }; - - isp_clock: clock-controller@10048000 { - compatible = "samsung,exynos4412-isp-clock"; - reg = <0x10048000 0x1000>; - #clock-cells = <1>; - power-domains = <&pd_isp>; - clocks = <&clock CLK_ACLK200>, <&clock CLK_ACLK400_MCUISP>; - clock-names = "aclk200", "aclk400_mcuisp"; - }; diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt deleted file mode 100644 index aff266a12eeb..000000000000 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++ /dev/null @@ -1,41 +0,0 @@ -* Samsung Exynos5250 Clock Controller - -The Exynos5250 clock controller generates and supplies clock to various -controllers within the Exynos5250 SoC. - -Required Properties: - -- compatible: should be one of the following. - - "samsung,exynos5250-clock" - controller compatible with Exynos5250 SoC. - -- reg: physical base address of the controller and length of memory mapped - region. - -- #clock-cells: should be 1. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. - -All available clocks are defined as preprocessor macros in -dt-bindings/clock/exynos5250.h header and can be used in device -tree sources. - -Example 1: An example of a clock controller node is listed below. - - clock: clock-controller@10010000 { - compatible = "samsung,exynos5250-clock"; - reg = <0x10010000 0x30000>; - #clock-cells = <1>; - }; - -Example 2: UART controller node that consumes the clock generated by the clock - controller. Refer to the standard clock bindings for information - about 'clocks' and 'clock-names' property. - - serial@13820000 { - compatible = "samsung,exynos4210-uart"; - reg = <0x13820000 0x100>; - interrupts = <0 54 0>; - clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>; - clock-names = "uart", "clk_uart_baud0"; - }; diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt deleted file mode 100644 index 717a7b1531c7..000000000000 --- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt +++ /dev/null @@ -1,42 +0,0 @@ -* Samsung Exynos5420 Clock Controller - -The Exynos5420 clock controller generates and supplies clock to various -controllers within the Exynos5420 SoC and for the Exynos5800 SoC. - -Required Properties: - -- compatible: should be one of the following. - - "samsung,exynos5420-clock" - controller compatible with Exynos5420 SoC. - - "samsung,exynos5800-clock" - controller compatible with Exynos5800 SoC. - -- reg: physical base address of the controller and length of memory mapped - region. - -- #clock-cells: should be 1. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. - -All available clocks are defined as preprocessor macros in -dt-bindings/clock/exynos5420.h header and can be used in device -tree sources. - -Example 1: An example of a clock controller node is listed below. - - clock: clock-controller@10010000 { - compatible = "samsung,exynos5420-clock"; - reg = <0x10010000 0x30000>; - #clock-cells = <1>; - }; - -Example 2: UART controller node that consumes the clock generated by the clock - controller. Refer to the standard clock bindings for information - about 'clocks' and 'clock-names' property. - - serial@13820000 { - compatible = "samsung,exynos4210-uart"; - reg = <0x13820000 0x100>; - interrupts = <0 54 0>; - clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>; - clock-names = "uart", "clk_uart_baud0"; - }; diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index 26ed040bc717..ffd6ae0eed64 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -30,6 +30,20 @@ description: | 3 -- OUT3 4 -- OUT4 + The idt,shutdown and idt,output-enable-active properties control the + SH (en_global_shutdown) and SP bits of the Primary Source and Shutdown + Register, respectively. Their behavior is summarized by the following + table: + + SH SP Output when the SD/OE pin is Low/High + == == ===================================== + 0 0 Active/Inactive + 0 1 Inactive/Active + 1 0 Active/Shutdown + 1 1 Inactive/Shutdown + + The case where SH and SP are both 1 is likely not very interesting. + maintainers: - Luca Ceresoli <luca@lucaceresoli.net> @@ -64,6 +78,26 @@ properties: maximum: 22760 description: Optional load capacitor for XTAL1 and XTAL2 + idt,shutdown: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + If 1, this enables the shutdown functionality: the chip will be + shut down if the SD/OE pin is driven high. If 0, this disables the + shutdown functionality: the chip will never be shut down based on + the value of the SD/OE pin. This property corresponds to the SH + bit of the Primary Source and Shutdown Register. + + idt,output-enable-active: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + If 1, this enables output when the SD/OE pin is high, and disables + output when the SD/OE pin is low. If 0, this disables output when + the SD/OE pin is high, and enables output when the SD/OE pin is + low. This corresponds to the SP bit of the Primary Source and + Shutdown Register. + patternProperties: "^OUT[1-4]$": type: object @@ -90,6 +124,8 @@ required: - compatible - reg - '#clock-cells' + - idt,shutdown + - idt,output-enable-active allOf: - if: @@ -139,6 +175,10 @@ examples: clocks = <&ref25m>; clock-names = "xin"; + /* Set the SD/OE pin's settings */ + idt,shutdown = <0>; + idt,output-enable-active = <0>; + OUT1 { idt,mode = <VC5_CMOSD>; idt,voltage-microvolt = <1800000>; diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml index db3d0ea6bc7a..fbd758470b88 100644 --- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml @@ -18,6 +18,7 @@ properties: enum: - qcom,ipq6018-a53pll - qcom,msm8916-a53pll + - qcom,msm8939-a53pll reg: maxItems: 1 @@ -33,6 +34,8 @@ properties: items: - const: xo + operating-points-v2: true + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6115.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6115.yaml new file mode 100644 index 000000000000..26050da844d5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6115.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,gcc-sm6115.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for SM6115 and SM4250 + +maintainers: + - Iskren Chernev <iskren.chernev@gmail.com> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on SM4250/6115. + + See also: + - dt-bindings/clock/qcom,gcc-sm6115.h + +properties: + compatible: + const: qcom,gcc-sm6115 + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + + clock-names: + items: + - const: bi_tcxo + - const: sleep_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + + protected-clocks: + description: + Protected clock specifier list as per common clock binding. + +required: + - compatible + - clocks + - clock-names + - reg + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmcc.h> + clock-controller@1400000 { + compatible = "qcom,gcc-sm6115"; + reg = <0x01400000 0x1f0000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + clock-names = "bi_tcxo", "sleep_clk"; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&sleep_clk>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml new file mode 100644 index 000000000000..20926cd8293e --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-sm6350.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for SM6350 + +maintainers: + - Konrad Dybcio <konrad.dybcio@somainline.org> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on SM6350. + + See also: + - dt-bindings/clock/qcom,gcc-sm6350.h + +properties: + compatible: + const: qcom,gcc-sm6350 + + clocks: + items: + - description: Board XO source + - description: Board active XO source + - description: Sleep clock source + + clock-names: + items: + - const: bi_tcxo + - const: bi_tcxo_ao + - const: sleep_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + + protected-clocks: + description: + Protected clock specifier list as per common clock binding. + +required: + - compatible + - clocks + - clock-names + - reg + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@100000 { + compatible = "qcom,gcc-sm6350"; + reg = <0x00100000 0x1f0000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&rpmhcc RPMH_CXO_CLK_A>, + <&sleep_clk>; + clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index 8453eeddf30e..2f20f8aa932a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -23,6 +23,7 @@ description: | - dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) - dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) - dt-bindings/clock/qcom,gcc-msm8939.h + - dt-bindings/clock/qcom,gcc-msm8953.h - dt-bindings/reset/qcom,gcc-msm8939.h - dt-bindings/clock/qcom,gcc-msm8660.h - dt-bindings/reset/qcom,gcc-msm8660.h @@ -46,6 +47,7 @@ properties: - qcom,gcc-msm8660 - qcom,gcc-msm8916 - qcom,gcc-msm8939 + - qcom,gcc-msm8953 - qcom,gcc-msm8960 - qcom,gcc-msm8974 - qcom,gcc-msm8974pro diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index df943c4c3234..46dff46d5760 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/clock/qcom,gpucc.yaml# @@ -11,11 +11,12 @@ maintainers: description: | Qualcomm graphics clock control module which supports the clocks, resets and - power domains on SDM845/SC7180/SM8150/SM8250. + power domains on Qualcomm SoCs. See also: dt-bindings/clock/qcom,gpucc-sdm845.h dt-bindings/clock/qcom,gpucc-sc7180.h + dt-bindings/clock/qcom,gpucc-sc7280.h dt-bindings/clock/qcom,gpucc-sm8150.h dt-bindings/clock/qcom,gpucc-sm8250.h @@ -24,6 +25,8 @@ properties: enum: - qcom,sdm845-gpucc - qcom,sc7180-gpucc + - qcom,sc7280-gpucc + - qcom,sc8180x-gpucc - qcom,sm8150-gpucc - qcom,sm8250-gpucc diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml index 8b0b1c56f354..68fdc3d4982a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml @@ -22,6 +22,8 @@ properties: - qcom,mmcc-msm8660 - qcom,mmcc-msm8960 - qcom,mmcc-msm8974 + - qcom,mmcc-msm8992 + - qcom,mmcc-msm8994 - qcom,mmcc-msm8996 - qcom,mmcc-msm8998 - qcom,mmcc-sdm630 diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt index 6cf5a7ec2b4c..a4877881f1d8 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -10,11 +10,13 @@ Required properties : - compatible : shall contain only one of the following. The generic compatible "qcom,rpmcc" should be also included. + "qcom,rpmcc-mdm9607", "qcom,rpmcc" "qcom,rpmcc-msm8660", "qcom,rpmcc" "qcom,rpmcc-apq8060", "qcom,rpmcc" "qcom,rpmcc-msm8226", "qcom,rpmcc" "qcom,rpmcc-msm8916", "qcom,rpmcc" "qcom,rpmcc-msm8936", "qcom,rpmcc" + "qcom,rpmcc-msm8953", "qcom,rpmcc" "qcom,rpmcc-msm8974", "qcom,rpmcc" "qcom,rpmcc-msm8976", "qcom,rpmcc" "qcom,rpmcc-apq8064", "qcom,rpmcc" @@ -25,6 +27,8 @@ Required properties : "qcom,rpmcc-msm8998", "qcom,rpmcc" "qcom,rpmcc-qcs404", "qcom,rpmcc" "qcom,rpmcc-sdm660", "qcom,rpmcc" + "qcom,rpmcc-sm6115", "qcom,rpmcc" + "qcom,rpmcc-sm6125", "qcom,rpmcc" - #clock-cells : shall contain 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index 9ea0b3f5a4f2..72212970e6f5 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -22,6 +22,7 @@ properties: - qcom,sc8180x-rpmh-clk - qcom,sdm845-rpmh-clk - qcom,sdx55-rpmh-clk + - qcom,sm6350-rpmh-clk - qcom,sm8150-rpmh-clk - qcom,sm8250-rpmh-clk - qcom,sm8350-rpmh-clk diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml new file mode 100644 index 000000000000..2178666fb697 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-dispcc.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sc7280-dispcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display Clock & Reset Controller Binding for SC7280 + +maintainers: + - Taniya Das <tdas@codeaurora.org> + +description: | + Qualcomm display clock control module which supports the clocks, resets and + power domains on SC7280. + + See also dt-bindings/clock/qcom,dispcc-sc7280.h. + +properties: + compatible: + const: qcom,sc7280-dispcc + + clocks: + items: + - description: Board XO source + - description: GPLL0 source from GCC + - description: Byte clock from DSI PHY + - description: Pixel clock from DSI PHY + - description: Link clock from DP PHY + - description: VCO DIV clock from DP PHY + - description: Link clock from EDP PHY + - description: VCO DIV clock from EDP PHY + + clock-names: + items: + - const: bi_tcxo + - const: gcc_disp_gpll0_clk + - const: dsi0_phy_pll_out_byteclk + - const: dsi0_phy_pll_out_dsiclk + - const: dp_phy_pll_link_clk + - const: dp_phy_pll_vco_div_clk + - const: edp_phy_pll_link_clk + - const: edp_phy_pll_vco_div_clk + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sc7280.h> + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@af00000 { + compatible = "qcom,sc7280-dispcc"; + reg = <0x0af00000 0x200000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_DISP_GPLL0_CLK_SRC>, + <&dsi_phy 0>, + <&dsi_phy 1>, + <&dp_phy 0>, + <&dp_phy 1>, + <&edp_phy 0>, + <&edp_phy 1>; + clock-names = "bi_tcxo", + "gcc_disp_gpll0_clk", + "dsi0_phy_pll_out_byteclk", + "dsi0_phy_pll_out_dsiclk", + "dp_phy_pll_link_clk", + "dp_phy_pll_vco_div_clk", + "edp_phy_pll_link_clk", + "edp_phy_pll_vco_div_clk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml index 567202942b88..0d224f114b5b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-only +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/clock/qcom,videocc.yaml# @@ -11,10 +11,11 @@ maintainers: description: | Qualcomm video clock control module which supports the clocks, resets and - power domains on SDM845/SC7180/SM8150/SM8250. + power domains on Qualcomm SoCs. See also: dt-bindings/clock/qcom,videocc-sc7180.h + dt-bindings/clock/qcom,videocc-sc7280.h dt-bindings/clock/qcom,videocc-sdm845.h dt-bindings/clock/qcom,videocc-sm8150.h dt-bindings/clock/qcom,videocc-sm8250.h @@ -23,6 +24,7 @@ properties: compatible: enum: - qcom,sc7180-videocc + - qcom,sc7280-videocc - qcom,sdm845-videocc - qcom,sm8150-videocc - qcom,sm8250-videocc diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt deleted file mode 100644 index 3bc56fae90ac..000000000000 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt +++ /dev/null @@ -1,68 +0,0 @@ -* Rockchip RK3399 Clock and Reset Unit - -The RK3399 clock controller generates and supplies clock to various -controllers within the SoC and also implements a reset controller for SoC -peripherals. - -Required Properties: - -- compatible: PMU for CRU should be "rockchip,rk3399-pmucru" -- compatible: CRU should be "rockchip,rk3399-cru" -- reg: physical base address of the controller and length of memory mapped - region. -- #clock-cells: should be 1. -- #reset-cells: should be 1. - -Optional Properties: - -- rockchip,grf: phandle to the syscon managing the "general register files". - It is used for GRF muxes, if missing any muxes present in the GRF will not - be available. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be -used in device tree sources. Similar macros exist for the reset sources in -these files. - -External clocks: - -There are several clocks that are generated outside the SoC. It is expected -that they are defined using standard clock bindings with following -clock-output-names: - - "xin24m" - crystal input - required, - - "xin32k" - rtc clock - optional, - - "clkin_gmac" - external GMAC clock - optional, - - "clkin_i2s" - external I2S clock - optional, - - "pclkin_cif" - external ISP clock - optional, - - "clk_usbphy0_480m" - output clock of the pll in the usbphy0 - - "clk_usbphy1_480m" - output clock of the pll in the usbphy1 - -Example: Clock controller node: - - pmucru: pmu-clock-controller@ff750000 { - compatible = "rockchip,rk3399-pmucru"; - reg = <0x0 0xff750000 0x0 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - - cru: clock-controller@ff760000 { - compatible = "rockchip,rk3399-cru"; - reg = <0x0 0xff760000 0x0 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart0: serial@ff1a0000 { - compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart"; - reg = <0x0 0xff180000 0x0 0x100>; - clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>; - clock-names = "baudclk", "apb_pclk"; - interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - reg-io-width = <4>; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml new file mode 100644 index 000000000000..72b286a1beba --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rk3399-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3399 Clock and Reset Unit + +maintainers: + - Xing Zheng <zhengxing@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: | + The RK3399 clock controller generates and supplies clock to various + controllers within the SoC and also implements a reset controller for SoC + peripherals. + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All available clocks are defined as + preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be + used in device tree sources. Similar macros exist for the reset sources in + these files. + There are several clocks that are generated outside the SoC. It is expected + that they are defined using standard clock bindings with following + clock-output-names: + - "xin24m" - crystal input - required, + - "xin32k" - rtc clock - optional, + - "clkin_gmac" - external GMAC clock - optional, + - "clkin_i2s" - external I2S clock - optional, + - "pclkin_cif" - external ISP clock - optional, + - "clk_usbphy0_480m" - output clock of the pll in the usbphy0 + - "clk_usbphy1_480m" - output clock of the pll in the usbphy1 + +properties: + compatible: + enum: + - rockchip,rk3399-pmucru + - rockchip,rk3399-cru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + minItems: 1 + + assigned-clocks: + minItems: 1 + maxItems: 64 + + assigned-clock-parents: + minItems: 1 + maxItems: 64 + + assigned-clock-rates: + minItems: 1 + maxItems: 64 + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: > + phandle to the syscon managing the "general register files". It is used + for GRF muxes, if missing any muxes present in the GRF will not be + available. + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + pmucru: pmu-clock-controller@ff750000 { + compatible = "rockchip,rk3399-pmucru"; + reg = <0xff750000 0x1000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + - | + cru: clock-controller@ff760000 { + compatible = "rockchip,rk3399-cru"; + reg = <0xff760000 0x1000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos-audss-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos-audss-clock.yaml new file mode 100644 index 000000000000..f14f1d39da36 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos-audss-clock.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,exynos-audss-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC Audio SubSystem clock controller + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Tomasz Figa <tomasz.figa@gmail.com> + +description: | + All available clocks are defined as preprocessor macros in + include/dt-bindings/clock/exynos-audss-clk.h header. + +properties: + compatible: + enum: + - samsung,exynos4210-audss-clock + - samsung,exynos5250-audss-clock + - samsung,exynos5410-audss-clock + - samsung,exynos5420-audss-clock + + clocks: + minItems: 2 + items: + - description: + Fixed rate PLL reference clock, parent of mout_audss. "fin_pll" is + used if not specified. + - description: + Input PLL to the AudioSS block, parent of mout_audss. "fout_epll" is + used if not specified. + - description: + Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if not + specified. + - description: + PCM clock, parent of sclk_pcm. "sclk_pcm0" is used if not specified. + - description: + External i2s clock, parent of mout_i2s. "cdclk0" is used if not + specified. + + clock-names: + minItems: 2 + items: + - const: pll_ref + - const: pll_in + - const: sclk_audio + - const: sclk_pcm_in + - const: cdclk + + "#clock-cells": + const: 1 + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - "#clock-cells" + - reg + +additionalProperties: false + +examples: + - | + clock-controller@3810000 { + compatible = "samsung,exynos5250-audss-clock"; + reg = <0x03810000 0x0c>; + #clock-cells = <1>; + clocks = <&clock 1>, <&clock 7>, <&clock 138>, <&clock 160>, <&ext_i2s_clk>; + clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in", "cdclk"; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos-clock.yaml new file mode 100644 index 000000000000..4e8062860986 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos-clock.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/samsung,exynos-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC clock controller + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Tomasz Figa <tomasz.figa@gmail.com> + +description: | + All available clocks are defined as preprocessor macros in + dt-bindings/clock/ headers. + +properties: + compatible: + oneOf: + - enum: + - samsung,exynos3250-cmu + - samsung,exynos3250-cmu-dmc + - samsung,exynos3250-cmu-isp + - samsung,exynos4210-clock + - samsung,exynos4412-clock + - samsung,exynos5250-clock + - items: + - enum: + - samsung,exynos5420-clock + - samsung,exynos5800-clock + - const: syscon + + clocks: + minItems: 1 + maxItems: 4 + + "#clock-cells": + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - "#clock-cells" + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5250.h> + clock: clock-controller@10010000 { + compatible = "samsung,exynos5250-clock"; + reg = <0x10010000 0x30000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos-ext-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos-ext-clock.yaml new file mode 100644 index 000000000000..64d027dbe3b2 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos-ext-clock.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,exynos-ext-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung SoC external/osc/XXTI/XusbXTI clock + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Tomasz Figa <tomasz.figa@gmail.com> + +description: | + Samsung SoCs require an external clock supplied through XXTI or XusbXTI pins. + +properties: + compatible: + enum: + - samsung,clock-xxti + - samsung,clock-xusbxti + - samsung,exynos5420-oscclk + + "#clock-cells": + const: 0 + + clock-frequency: true + + clock-output-names: + maxItems: 1 + +required: + - compatible + - clock-frequency + +additionalProperties: false + +examples: + - | + fixed-rate-clocks { + clock { + compatible = "samsung,clock-xxti"; + clock-frequency = <24000000>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml new file mode 100644 index 000000000000..1ed64add4355 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos4412-isp-clock.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,exynos4412-isp-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos4412 SoC ISP clock controller + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Tomasz Figa <tomasz.figa@gmail.com> + +description: | + Clock controller for Samsung Exynos4412 SoC FIMC-ISP (Camera ISP) + All available clocks are defined as preprocessor macros in + dt-bindings/clock/ headers. + +properties: + compatible: + const: samsung,exynos4412-isp-clock + + clocks: + items: + - description: CLK_ACLK200 from the main clock controller + - description: CLK_ACLK400_MCUISP from the main clock controller + + clock-names: + items: + - const: aclk200 + - const: aclk400_mcuisp + + "#clock-cells": + const: 1 + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - "#clock-cells" + - clocks + - clock-names + - power-domains + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + clock-controller@10048000 { + compatible = "samsung,exynos4412-isp-clock"; + reg = <0x10048000 0x1000>; + #clock-cells = <1>; + power-domains = <&pd_isp>; + clocks = <&clock CLK_ACLK200>, <&clock CLK_ACLK400_MCUISP>; + clock-names = "aclk200", "aclk400_mcuisp"; + }; + diff --git a/Documentation/devicetree/bindings/clock/samsung,s5pv210-audss-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,s5pv210-audss-clock.yaml new file mode 100644 index 000000000000..ae8f8fc93233 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s5pv210-audss-clock.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,s5pv210-audss-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5Pv210 SoC Audio SubSystem clock controller + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Tomasz Figa <tomasz.figa@gmail.com> + +description: | + All available clocks are defined as preprocessor macros in + include/dt-bindings/clock/s5pv210-audss.h header. + +properties: + compatible: + const: samsung,s5pv210-audss-clock + + clocks: + minItems: 4 + items: + - description: + AHB bus clock of the Audio Subsystem. + - description: + Optional fixed rate PLL reference clock, parent of mout_audss. If not + specified (i.e. xusbxti is used for PLL reference), it is fixed to a + clock named "xxti". + - description: + Input PLL to the AudioSS block, parent of mout_audss. + - description: + Audio bus clock, parent of mout_i2s. + - description: + Optional external i2s clock, parent of mout_i2s. If not specified, it + is fixed to a clock named "iiscdclk0". + + clock-names: + minItems: 4 + items: + - const: hclk + - const: xxti + - const: fout_epll + - const: sclk_audio0 + - const: iiscdclk0 + + "#clock-cells": + const: 1 + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - "#clock-cells" + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/s5pv210.h> + + clock-controller@c0900000 { + compatible = "samsung,s5pv210-audss-clock"; + reg = <0xc0900000 0x1000>; + #clock-cells = <1>; + clock-names = "hclk", "xxti", "fout_epll", "sclk_audio0"; + clocks = <&clocks DOUT_HCLKP>, <&xxti>, <&clocks FOUT_EPLL>, + <&clocks SCLK_AUDIO0>; + }; diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 92b49bc37939..7eb8659fa610 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -111,6 +111,10 @@ properties: - 1.5A - 3.0A + pd-disable: + description: Set this property if the Type-C connector has no power delivery support. + type: boolean + # The following are optional properties for "usb-c-connector" with power # delivery support. source-pdos: diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt b/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt deleted file mode 100644 index aeaebd425d1f..000000000000 --- a/Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt +++ /dev/null @@ -1,26 +0,0 @@ - -* Samsung Exynos NoC (Network on Chip) Probe device - -The Samsung Exynos542x SoC has NoC (Network on Chip) Probe for NoC bus. -NoC provides the primitive values to get the performance data. The packets -that the Network on Chip (NoC) probes detects are transported over -the network infrastructure to observer units. You can configure probes to -capture packets with header or data on the data request response network, -or as traffic debug or statistic collectors. Exynos542x bus has multiple -NoC probes to provide bandwidth information about behavior of the SoC -that you can use while analyzing system performance. - -Required properties: -- compatible: Should be "samsung,exynos5420-nocp" -- reg: physical base address of each NoC Probe and length of memory mapped region. - -Optional properties: -- clock-names : the name of clock used by the NoC Probe, "nocp" -- clocks : phandles for clock specified in "clock-names" property - -Example : NoC Probe nodes in Device Tree are listed below. - - nocp_mem0_0: nocp@10ca1000 { - compatible = "samsung,exynos5420-nocp"; - reg = <0x10CA1000 0x200>; - }; diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt deleted file mode 100644 index fb46b491791c..000000000000 --- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt +++ /dev/null @@ -1,169 +0,0 @@ - -* Samsung Exynos PPMU (Platform Performance Monitoring Unit) device - -The Samsung Exynos SoC has PPMU (Platform Performance Monitoring Unit) for -each IP. PPMU provides the primitive values to get performance data. These -PPMU events provide information of the SoC's behaviors so that you may -use to analyze system performance, to make behaviors visible and to count -usages of each IP (DMC, CPU, RIGHTBUS, LEFTBUS, CAM interface, LCD, G3D, MFC). -The Exynos PPMU driver uses the devfreq-event class to provide event data -to various devfreq devices. The devfreq devices would use the event data when -derterming the current state of each IP. - -Required properties for PPMU device: -- compatible: Should be "samsung,exynos-ppmu" or "samsung,exynos-ppmu-v2. -- reg: physical base address of each PPMU and length of memory mapped region. - -Optional properties for PPMU device: -- clock-names : the name of clock used by the PPMU, "ppmu" -- clocks : phandles for clock specified in "clock-names" property - -Required properties for 'events' child node of PPMU device: -- event-name : the unique event name among PPMU device -Optional properties for 'events' child node of PPMU device: -- event-data-type : Define the type of data which shell be counted -by the counter. You can check include/dt-bindings/pmu/exynos_ppmu.h for -all possible type, i.e. count read requests, count write data in bytes, -etc. This field is optional and when it is missing, the driver code -will use default data type. - -Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below. - - ppmu_dmc0: ppmu_dmc0@106a0000 { - compatible = "samsung,exynos-ppmu"; - reg = <0x106a0000 0x2000>; - status = "disabled"; - }; - - ppmu_dmc1: ppmu_dmc1@106b0000 { - compatible = "samsung,exynos-ppmu"; - reg = <0x106b0000 0x2000>; - status = "disabled"; - }; - - ppmu_cpu: ppmu_cpu@106c0000 { - compatible = "samsung,exynos-ppmu"; - reg = <0x106c0000 0x2000>; - status = "disabled"; - }; - - ppmu_rightbus: ppmu_rightbus@112a0000 { - compatible = "samsung,exynos-ppmu"; - reg = <0x112a0000 0x2000>; - clocks = <&cmu CLK_PPMURIGHT>; - clock-names = "ppmu"; - status = "disabled"; - }; - - ppmu_leftbus: ppmu_leftbus0@116a0000 { - compatible = "samsung,exynos-ppmu"; - reg = <0x116a0000 0x2000>; - clocks = <&cmu CLK_PPMULEFT>; - clock-names = "ppmu"; - status = "disabled"; - }; - -Example2 : Events of each PPMU node in exynos3250-rinato.dts are listed below. - - &ppmu_dmc0 { - status = "okay"; - - events { - ppmu_dmc0_3: ppmu-event3-dmc0 { - event-name = "ppmu-event3-dmc0"; - }; - - ppmu_dmc0_2: ppmu-event2-dmc0 { - event-name = "ppmu-event2-dmc0"; - }; - - ppmu_dmc0_1: ppmu-event1-dmc0 { - event-name = "ppmu-event1-dmc0"; - }; - - ppmu_dmc0_0: ppmu-event0-dmc0 { - event-name = "ppmu-event0-dmc0"; - }; - }; - }; - - &ppmu_dmc1 { - status = "okay"; - - events { - ppmu_dmc1_3: ppmu-event3-dmc1 { - event-name = "ppmu-event3-dmc1"; - }; - }; - }; - - &ppmu_leftbus { - status = "okay"; - - events { - ppmu_leftbus_3: ppmu-event3-leftbus { - event-name = "ppmu-event3-leftbus"; - }; - }; - }; - - &ppmu_rightbus { - status = "okay"; - - events { - ppmu_rightbus_3: ppmu-event3-rightbus { - event-name = "ppmu-event3-rightbus"; - }; - }; - }; - -Example3 : PPMUv2 nodes in exynos5433.dtsi are listed below. - - ppmu_d0_cpu: ppmu_d0_cpu@10480000 { - compatible = "samsung,exynos-ppmu-v2"; - reg = <0x10480000 0x2000>; - status = "disabled"; - }; - - ppmu_d0_general: ppmu_d0_general@10490000 { - compatible = "samsung,exynos-ppmu-v2"; - reg = <0x10490000 0x2000>; - status = "disabled"; - }; - - ppmu_d0_rt: ppmu_d0_rt@104a0000 { - compatible = "samsung,exynos-ppmu-v2"; - reg = <0x104a0000 0x2000>; - status = "disabled"; - }; - - ppmu_d1_cpu: ppmu_d1_cpu@104b0000 { - compatible = "samsung,exynos-ppmu-v2"; - reg = <0x104b0000 0x2000>; - status = "disabled"; - }; - - ppmu_d1_general: ppmu_d1_general@104c0000 { - compatible = "samsung,exynos-ppmu-v2"; - reg = <0x104c0000 0x2000>; - status = "disabled"; - }; - - ppmu_d1_rt: ppmu_d1_rt@104d0000 { - compatible = "samsung,exynos-ppmu-v2"; - reg = <0x104d0000 0x2000>; - status = "disabled"; - }; - -Example4 : 'event-data-type' in exynos4412-ppmu-common.dtsi are listed below. - - &ppmu_dmc0 { - status = "okay"; - events { - ppmu_dmc0_3: ppmu-event3-dmc0 { - event-name = "ppmu-event3-dmc0"; - event-data-type = <(PPMU_RO_DATA_CNT | - PPMU_WO_DATA_CNT)>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-nocp.yaml b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-nocp.yaml new file mode 100644 index 000000000000..d318fccf78f1 --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-nocp.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/devfreq/event/samsung,exynos-nocp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos NoC (Network on Chip) Probe + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + The Samsung Exynos542x SoC has a NoC (Network on Chip) Probe for NoC bus. + NoC provides the primitive values to get the performance data. The packets + that the Network on Chip (NoC) probes detects are transported over the + network infrastructure to observer units. You can configure probes to capture + packets with header or data on the data request response network, or as + traffic debug or statistic collectors. Exynos542x bus has multiple NoC probes + to provide bandwidth information about behavior of the SoC that you can use + while analyzing system performance. + +properties: + compatible: + const: samsung,exynos5420-nocp + + clock-names: + items: + - const: nocp + + clocks: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + nocp_mem0_0: nocp@10ca1000 { + compatible = "samsung,exynos5420-nocp"; + reg = <0x10ca1000 0x200>; + }; diff --git a/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml new file mode 100644 index 000000000000..c9a8cb5fd555 --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/event/samsung,exynos-ppmu.yaml @@ -0,0 +1,169 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/devfreq/event/samsung,exynos-ppmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC PPMU (Platform Performance Monitoring Unit) + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + The Samsung Exynos SoC has PPMU (Platform Performance Monitoring Unit) for + each IP. PPMU provides the primitive values to get performance data. These + PPMU events provide information of the SoC's behaviors so that you may use to + analyze system performance, to make behaviors visible and to count usages of + each IP (DMC, CPU, RIGHTBUS, LEFTBUS, CAM interface, LCD, G3D, MFC). The + Exynos PPMU driver uses the devfreq-event class to provide event data to + various devfreq devices. The devfreq devices would use the event data when + derterming the current state of each IP. + +properties: + compatible: + enum: + - samsung,exynos-ppmu + - samsung,exynos-ppmu-v2 + + clock-names: + items: + - const: ppmu + + clocks: + maxItems: 1 + + reg: + maxItems: 1 + + events: + type: object + + patternProperties: + '^ppmu-event[0-9]+(-[a-z0-9]+){,2}$': + type: object + properties: + event-name: + description: | + The unique event name among PPMU device + $ref: /schemas/types.yaml#/definitions/string + + event-data-type: + description: | + Define the type of data which shell be counted by the counter. + You can check include/dt-bindings/pmu/exynos_ppmu.h for all + possible type, i.e. count read requests, count write data in + bytes, etc. This field is optional and when it is missing, the + driver code will use default data type. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - event-name + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + // PPMUv1 nodes for Exynos3250 (although the board DTS defines events) + #include <dt-bindings/clock/exynos3250.h> + + ppmu_dmc0: ppmu@106a0000 { + compatible = "samsung,exynos-ppmu"; + reg = <0x106a0000 0x2000>; + + events { + ppmu_dmc0_3: ppmu-event3-dmc0 { + event-name = "ppmu-event3-dmc0"; + }; + + ppmu_dmc0_2: ppmu-event2-dmc0 { + event-name = "ppmu-event2-dmc0"; + }; + + ppmu_dmc0_1: ppmu-event1-dmc0 { + event-name = "ppmu-event1-dmc0"; + }; + + ppmu_dmc0_0: ppmu-event0-dmc0 { + event-name = "ppmu-event0-dmc0"; + }; + }; + }; + + ppmu_rightbus: ppmu@112a0000 { + compatible = "samsung,exynos-ppmu"; + reg = <0x112a0000 0x2000>; + clocks = <&cmu CLK_PPMURIGHT>; + clock-names = "ppmu"; + + events { + ppmu_rightbus_3: ppmu-event3-rightbus { + event-name = "ppmu-event3-rightbus"; + }; + }; + }; + + - | + // PPMUv2 nodes in Exynos5433 + ppmu_d0_cpu: ppmu@10480000 { + compatible = "samsung,exynos-ppmu-v2"; + reg = <0x10480000 0x2000>; + }; + + ppmu_d0_general: ppmu@10490000 { + compatible = "samsung,exynos-ppmu-v2"; + reg = <0x10490000 0x2000>; + + events { + ppmu_event0_d0_general: ppmu-event0-d0-general { + event-name = "ppmu-event0-d0-general"; + }; + }; + }; + + ppmu_d0_rt: ppmu@104a0000 { + compatible = "samsung,exynos-ppmu-v2"; + reg = <0x104a0000 0x2000>; + }; + + ppmu_d1_cpu: ppmu@104b0000 { + compatible = "samsung,exynos-ppmu-v2"; + reg = <0x104b0000 0x2000>; + }; + + ppmu_d1_general: ppmu@104c0000 { + compatible = "samsung,exynos-ppmu-v2"; + reg = <0x104c0000 0x2000>; + }; + + ppmu_d1_rt: ppmu@104d0000 { + compatible = "samsung,exynos-ppmu-v2"; + reg = <0x104d0000 0x2000>; + }; + + - | + // PPMUv1 nodes with event-data-type for Exynos4412 + #include <dt-bindings/pmu/exynos_ppmu.h> + + ppmu@106a0000 { + compatible = "samsung,exynos-ppmu"; + reg = <0x106a0000 0x2000>; + clocks = <&clock 400>; + clock-names = "ppmu"; + + events { + ppmu-event3-dmc0 { + event-name = "ppmu-event3-dmc0"; + event-data-type = <(PPMU_RO_DATA_CNT | + PPMU_WO_DATA_CNT)>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml index 5d42d36608d9..4951b5ef5c6a 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml @@ -174,7 +174,6 @@ examples: phy-names = "phy"; pinctrl-names = "default"; pinctrl-0 = <&hdmi_pins>; - status = "disabled"; ports { #address-cells = <1>; @@ -233,7 +232,6 @@ examples: phy-names = "phy"; pinctrl-names = "default"; pinctrl-0 = <&hdmi_pins>; - status = "disabled"; ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml index 6c7b577fd471..43cf4df9811a 100644 --- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml +++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml @@ -22,6 +22,9 @@ properties: - ti,ths8134a - ti,ths8134b - const: ti,ths8134 + - items: + - const: corpro,gm7123 + - const: adi,adv7123 - enum: - adi,adv7123 - dumb-vga-dac diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index d101233ae17f..07b20383cbca 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -37,7 +37,8 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Video port for MIPI DSI Channel-A input properties: @@ -57,7 +58,8 @@ properties: - const: 4 port@1: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Video port for MIPI DSI Channel-B input properties: diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 26932d2e86ab..1c2daf7c24cc 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -70,6 +70,9 @@ properties: const: 1 description: See ../../pwm/pwm.yaml for description of the cell formats. + aux-bus: + $ref: /schemas/display/dp-aux-bus.yaml# + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -150,7 +153,6 @@ properties: required: - compatible - reg - - enable-gpios - vccio-supply - vpll-supply - vcca-supply @@ -201,11 +203,26 @@ examples: port@1 { reg = <1>; - endpoint { + sn65dsi86_out: endpoint { remote-endpoint = <&panel_in_edp>; }; }; }; + + aux-bus { + panel { + compatible = "boe,nv133fhm-n62"; + power-supply = <&pp3300_dx_edp>; + backlight = <&backlight>; + hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>; + + port { + panel_in_edp: endpoint { + remote-endpoint = <&sn65dsi86_out>; + }; + }; + }; + }; }; }; - | diff --git a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml new file mode 100644 index 000000000000..5e4afe9f98fb --- /dev/null +++ b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/dp-aux-bus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DisplayPort AUX bus + +maintainers: + - Douglas Anderson <dianders@chromium.org> + +description: + DisplayPort controllers provide a control channel to the sinks that + are hooked up to them. This is the DP AUX bus. Over the DP AUX bus + we can query properties about a sink and also configure it. In + particular, DP sinks support DDC over DP AUX which allows tunneling + a standard I2C DDC connection over the AUX channel. + + To model this relationship, DP sinks should be placed as children + of the DP controller under the "aux-bus" node. + + At the moment, this binding only handles the eDP case. It is + possible it will be extended in the future to handle the DP case. + For DP, presumably a connector would be listed under the DP AUX + bus instead of a panel. + +properties: + $nodename: + const: "aux-bus" + + panel: + $ref: panel/panel-common.yaml# + +additionalProperties: false + +required: + - panel diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index a4c3064c778c..900a56cae80e 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -27,6 +27,7 @@ properties: - fsl,imx6ul-lcdif - fsl,imx7d-lcdif - fsl,imx8mm-lcdif + - fsl,imx8mn-lcdif - fsl,imx8mq-lcdif - const: fsl,imx6sx-lcdif diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt index 8238a86686be..d30428b9fb33 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt @@ -7,7 +7,7 @@ channel output. Required properties: - compatible: "mediatek,<chip>-dsi" -- the supported chips are mt2701, mt7623, mt8173 and mt8183. +- the supported chips are mt2701, mt7623, mt8167, mt8173 and mt8183. - reg: Physical base address and length of the controller's registers - interrupts: The interrupt signal from the function block. - clocks: device clocks diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 76348b71f736..35426fde8610 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -64,6 +64,18 @@ properties: Indicates if the DSI controller is driving a panel which needs 2 DSI links. + assigned-clocks: + minItems: 2 + maxItems: 2 + description: | + Parents of "byte" and "pixel" for the given platform. + + assigned-clock-parents: + minItems: 2 + maxItems: 2 + description: | + The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block. + power-domains: maxItems: 1 @@ -77,7 +89,8 @@ properties: properties: port@0: - $ref: "/schemas/graph.yaml#/properties/port" + $ref: "/schemas/graph.yaml#/$defs/port-base" + unevaluatedProperties: false description: | Input endpoints of the controller. properties: @@ -92,7 +105,8 @@ properties: enum: [ 0, 1, 2, 3 ] port@1: - $ref: "/schemas/graph.yaml#/properties/port" + $ref: "/schemas/graph.yaml#/$defs/port-base" + unevaluatedProperties: false description: | Output endpoints of the controller. properties: @@ -119,6 +133,8 @@ required: - clock-names - phys - phy-names + - assigned-clocks + - assigned-clock-parents - power-domains - operating-points-v2 - ports @@ -159,6 +175,9 @@ examples: phys = <&dsi0_phy>; phy-names = "dsi"; + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>; + assigned-clock-parents = <&dsi_phy 0>, <&dsi_phy 1>; + power-domains = <&rpmhpd SC7180_CX>; operating-points-v2 = <&dsi_opp_table>; diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml index 4a26bef19360..4399715953e1 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -14,9 +14,9 @@ allOf: properties: compatible: - oneOf: - - const: qcom,dsi-phy-10nm - - const: qcom,dsi-phy-10nm-8998 + enum: + - qcom,dsi-phy-10nm + - qcom,dsi-phy-10nm-8998 reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml index 72a00cce0147..064df50e21a5 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml @@ -14,9 +14,9 @@ allOf: properties: compatible: - oneOf: - - const: qcom,dsi-phy-14nm - - const: qcom,dsi-phy-14nm-660 + enum: + - qcom,dsi-phy-14nm + - qcom,dsi-phy-14nm-660 reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml index 743806d61afe..b8de785ce815 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml @@ -14,8 +14,7 @@ allOf: properties: compatible: - oneOf: - - const: qcom,dsi-phy-20nm + const: qcom,dsi-phy-20nm reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml index b106007116b4..69eecaa64b18 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -14,10 +14,10 @@ allOf: properties: compatible: - oneOf: - - const: qcom,dsi-phy-28nm-hpm - - const: qcom,dsi-phy-28nm-lp - - const: qcom,dsi-phy-28nm-8960 + enum: + - qcom,dsi-phy-28nm-hpm + - qcom,dsi-phy-28nm-lp + - qcom,dsi-phy-28nm-8960 reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml new file mode 100644 index 000000000000..4265399bb154 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-7nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 7nm PHY + +maintainers: + - Jonathan Marek <jonathan@marek.ca> + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-7nm + - const: qcom,dsi-phy-7nm-8150 + - const: qcom,sc7280-dsi-phy-7nm + + reg: + items: + - description: dsi phy register set + - description: dsi phy lane register set + - description: dsi pll register set + + reg-names: + items: + - const: dsi_phy + - const: dsi_phy_lane + - const: dsi_pll + + vdds-supply: + description: | + Connected to VDD_A_DSI_PLL_0P9 pin (or VDDA_DSI{0,1}_PLL_0P9 for sm8150) + + phy-type: + description: D-PHY (default) or C-PHY mode + enum: [ 10, 11 ] + default: 10 + +required: + - compatible + - reg + - reg-names + - vdds-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sm8250.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-7nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94900 0x260>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vdds-supply = <&vreg_l5a_0p88>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index 38bc1d1b511e..b87a2e28c866 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml @@ -70,7 +70,6 @@ examples: avee-supply = <&ppvarp_lcd>; pp1800-supply = <&pp1800_lcd>; backlight = <&backlight_lcd0>; - status = "okay"; port { panel_in: endpoint { remote-endpoint = <&dsi_out>; diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml new file mode 100644 index 000000000000..2ed010f91e2d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/ilitek,ili9341.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ilitek-9341 Display Panel + +maintainers: + - Dillon Min <dillon.minfei@gmail.com> + +description: | + Ilitek ILI9341 TFT panel driver with SPI control bus + This is a driver for 320x240 TFT panels, accepting a rgb input + streams with 16 bits or 18 bits. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + # ili9341 240*320 Color on stm32f429-disco board + - st,sf-tc240t-9370-t + - const: ilitek,ili9341 + + reg: true + + dc-gpios: + maxItems: 1 + description: Display data/command selection (D/CX) of this DBI panel + + spi-3wire: true + + spi-max-frequency: + const: 10000000 + + port: true + + vci-supply: + description: Analog voltage supply (2.5 .. 3.3V) + + vddi-supply: + description: Voltage supply for interface logic (1.65 .. 3.3 V) + + vddi-led-supply: + description: Voltage supply for the LED driver (1.65 .. 3.3 V) + +additionalProperties: false + +required: + - compatible + - reg + - dc-gpios + - port + +examples: + - |+ + spi { + #address-cells = <1>; + #size-cells = <0>; + panel: display@0 { + compatible = "st,sf-tc240t-9370-t", + "ilitek,ili9341"; + reg = <0>; + spi-3wire; + spi-max-frequency = <10000000>; + dc-gpios = <&gpiod 13 0>; + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + }; +... + diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml new file mode 100644 index 000000000000..cda36c04e85c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/innolux,ej030na.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Innolux EJ030NA 3.0" (320x480 pixels) 24-bit TFT LCD panel + +description: | + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: innolux,ej030na + + backlight: true + port: true + power-supply: true + reg: true + reset-gpios: true + +required: + - compatible + - reg + - power-supply + - reset-gpios + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "innolux,ej030na"; + reg = <0>; + + spi-max-frequency = <10000000>; + + reset-gpios = <&gpe 4 GPIO_ACTIVE_LOW>; + power-supply = <&lcd_power>; + + backlight = <&backlight>; + + port { + panel_input: endpoint { + remote-endpoint = <&panel_output>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index b3797ba2698b..335776c45474 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -46,9 +46,13 @@ properties: # AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel - auo,b116xw03 # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel + - auo,b133han05 + # AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel - auo,b133htn01 # AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel - auo,b133xtn01 + # AU Optronics Corporation 14.0" FHD (1920x1080) color TFT-LCD panel + - auo,b140han06 # AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel - auo,g070vvn01 # AU Optronics Corporation 10.1" (1280x800) color TFT LCD panel @@ -110,6 +114,9 @@ properties: # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel - edt,et057090dhu - edt,et070080dh6 + # Emerging Display Technology Corp. 3.5" WVGA TFT LCD panel with + # capacitive multitouch + - edt,etm0350g0dh6 # Emerging Display Technology Corp. 480x272 TFT Display with capacitive touch - edt,etm043080dh6gp # Emerging Display Technology Corp. 480x272 TFT Display @@ -128,6 +135,11 @@ properties: # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch - edt,etm0700g0dh6 - edt,etm0700g0edh6 + # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel with + # capacitive touch + - edt,etmv570g2dhu + # E Ink VB3300-KCA + - eink,vb3300-kca # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel - evervision,vgg804821 # Foxlink Group 5" WVGA TFT LCD panel @@ -202,8 +214,14 @@ properties: - logictechno,lt161010-2nhr # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod. - logictechno,lt170410-2whc + # Logic Technologies LTTD800x480 L2RT 7" 800x480 TFT Resistive Touch Module + - logictechno,lttd800480070-l2rt + # Logic Technologies LTTD800480070-L6WH-RT 7” 800x480 TFT Resistive Touch Module + - logictechno,lttd800480070-l6wh-rt # Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel - mitsubishi,aa070mc01-ca1 + # Multi-Inno Technology Co.,Ltd MI1010AIT-1CP 10.1" 1280x800 LVDS IPS Cap Touch Mod. + - multi-inno,mi1010ait-1cp # NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel - nec,nl12880bc20-05 # NEC LCD Technologies,Ltd. WQVGA TFT LCD panel @@ -238,10 +256,14 @@ properties: - powertip,ph800480t013-idf02 # QiaoDian XianShi Corporation 4"3 TFT LCD panel - qiaodian,qd43003c0-40 + # Shenzhen QiShenglong Industrialist Co., Ltd. Gopher 2b 4.3" 480(RGB)x272 TFT LCD panel + - qishenglong,gopher2b-lcd # Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800 - rocktech,rk101ii01d-ct # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel - rocktech,rk070er9427 + # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel + - samsung,atna33xc20 # Samsung 12.2" (2560x1600 pixels) TFT LCD panel - samsung,lsn122dl01-c01 # Samsung Electronics 10.1" WSVGA TFT LCD panel @@ -298,6 +320,8 @@ properties: enable-gpios: true port: true power-supply: true + no-hpd: true + hpd-gpios: true additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml new file mode 100644 index 000000000000..251f0c7115aa --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,lms380kf01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung LMS380KF01 display panel + +description: The LMS380KF01 is a 480x800 DPI display panel from Samsung Mobile + Displays (SMD) utilizing the WideChips WS2401 display controller. It can be + used with internal or external backlight control. + The panel must obey the rules for a SPI slave device as specified in + spi/spi-controller.yaml + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,lms380kf01 + + reg: true + + interrupts: + description: provides an optional ESD (electrostatic discharge) + interrupt that signals abnormalities in the display hardware. + This can also be raised for other reasons like erroneous + configuration. + maxItems: 1 + + reset-gpios: true + + vci-supply: + description: regulator that supplies the VCI analog voltage + usually around 3.0 V + + vccio-supply: + description: regulator that supplies the VCCIO voltage usually + around 1.8 V + + backlight: true + + spi-cpha: true + + spi-cpol: true + + spi-max-frequency: + maximum: 1200000 + + port: true + +required: + - compatible + - reg + - spi-cpha + - spi-cpol + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + compatible = "spi-gpio"; + sck-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; + miso-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + mosi-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>; + cs-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>; + num-chipselects = <1>; + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,lms380kf01"; + spi-max-frequency = <1200000>; + spi-cpha; + spi-cpol; + reg = <0>; + vci-supply = <&lcd_3v0_reg>; + vccio-supply = <&lcd_1v8_reg>; + reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; + interrupt-parent = <&gpio>; + interrupts = <5 IRQ_TYPE_EDGE_RISING>; + + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml index 4cb75a5f2e3a..cd62968426fb 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml @@ -33,8 +33,11 @@ properties: backlight: true + spi-cpha: true + + spi-cpol: true + spi-max-frequency: - $ref: /schemas/types.yaml#/definitions/uint32 description: inherited as a SPI client node, the datasheet specifies maximum 300 ns minimum cycle which gives around 3 MHz max frequency maximum: 3000000 @@ -44,6 +47,9 @@ properties: required: - compatible - reg + - spi-cpha + - spi-cpol + - port additionalProperties: false @@ -52,15 +58,23 @@ examples: #include <dt-bindings/gpio/gpio.h> spi { + compatible = "spi-gpio"; + sck-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; + miso-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + mosi-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>; + cs-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>; + num-chipselects = <1>; #address-cells = <1>; #size-cells = <0>; panel@0 { compatible = "samsung,lms397kf04"; spi-max-frequency = <3000000>; + spi-cpha; + spi-cpol; reg = <0>; vci-supply = <&lcd_3v0_reg>; vccio-supply = <&lcd_1v8_reg>; - reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; backlight = <&ktd259>; port { diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index 5f4345d43020..e3ca5389c17d 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -92,7 +92,6 @@ required: - reg - clocks - interrupts - - resets - ports allOf: diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 151be3bba06f..39792f051d2d 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -23,6 +23,7 @@ Required properties: Optional properties: - phys: from general PHY binding: the phandle for the PHY device. - phy-names: Should be "dphy" if phys references an external phy. +- #phy-cells: Defined when used as ISP phy, should be 0. - power-domains: a phandle to mipi dsi power domain node. - resets: list of phandle + reset specifier pairs, as described in [3]. - reset-names: string reset name, must be "apb". diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml new file mode 100644 index 000000000000..2ed2a7d0ca2f --- /dev/null +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -0,0 +1,208 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/solomon,ssd1307fb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Solomon SSD1307 OLED Controller Framebuffer + +maintainers: + - Maxime Ripard <mripard@kernel.org> + +properties: + compatible: + enum: + - solomon,ssd1305fb-i2c + - solomon,ssd1306fb-i2c + - solomon,ssd1307fb-i2c + - solomon,ssd1309fb-i2c + + reg: + maxItems: 1 + + pwms: + maxItems: 1 + + reset-gpios: + maxItems: 1 + + vbat-supply: + description: The supply for VBAT + + solomon,height: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 16 + description: + Height in pixel of the screen driven by the controller + + solomon,width: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 96 + description: + Width in pixel of the screen driven by the controller + + solomon,page-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 1 + description: + Offset of pages (band of 8 pixels) that the screen is mapped to + + solomon,segment-no-remap: + type: boolean + description: + Display needs normal (non-inverted) data column to segment mapping + + solomon,col-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: + Offset of columns (COL/SEG) that the screen is mapped to + + solomon,com-seq: + type: boolean + description: + Display uses sequential COM pin configuration + + solomon,com-lrremap: + type: boolean + description: + Display uses left-right COM pin remap + + solomon,com-invdir: + type: boolean + description: + Display uses inverted COM pin scan direction + + solomon,com-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: + Number of the COM pin wired to the first display line + + solomon,prechargep1: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 2 + description: + Length of deselect period (phase 1) in clock cycles + + solomon,prechargep2: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 2 + description: + Length of precharge period (phase 2) in clock cycles. This needs to be + the higher, the higher the capacitance of the OLED's pixels is. + + solomon,dclk-div: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 16 + description: + Clock divisor. The default value is controller-dependent. + + solomon,dclk-frq: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + Clock frequency, higher value means higher frequency. + The default value is controller-dependent. + + solomon,lookup-table: + $ref: /schemas/types.yaml#/definitions/uint8-array + maxItems: 4 + description: + 8 bit value array of current drive pulse widths for BANK0, and colors A, + B, and C. Each value in range of 31 to 63 for pulse widths of 32 to 64. + Color D is always width 64. + + solomon,area-color-enable: + type: boolean + description: + Display uses color mode + + solomon,low-power: + type: boolean + description: + Display runs in low power mode + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: solomon,ssd1305fb-i2c + then: + properties: + solomon,dclk-div: + default: 1 + solomon,dclk-frq: + default: 7 + + - if: + properties: + compatible: + contains: + const: solomon,ssd1306fb-i2c + then: + properties: + solomon,dclk-div: + default: 1 + solomon,dclk-frq: + default: 8 + + - if: + properties: + compatible: + contains: + const: solomon,ssd1307fb-i2c + then: + properties: + solomon,dclk-div: + default: 2 + solomon,dclk-frq: + default: 12 + required: + - pwms + + - if: + properties: + compatible: + contains: + const: solomon,ssd1309fb-i2c + then: + properties: + solomon,dclk-div: + default: 1 + solomon,dclk-frq: + default: 10 + +additionalProperties: false + +examples: + - | + i2c1 { + #address-cells = <1>; + #size-cells = <0>; + + ssd1307: oled@3c { + compatible = "solomon,ssd1307fb-i2c"; + reg = <0x3c>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + }; + + ssd1306: oled@3d { + compatible = "solomon,ssd1306fb-i2c"; + reg = <0x3c>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + solomon,com-lrremap; + solomon,com-invdir; + solomon,com-offset = <32>; + solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt b/Documentation/devicetree/bindings/display/ssd1307fb.txt deleted file mode 100644 index 2dcb6d12d137..000000000000 --- a/Documentation/devicetree/bindings/display/ssd1307fb.txt +++ /dev/null @@ -1,60 +0,0 @@ -* Solomon SSD1307 Framebuffer Driver - -Required properties: - - compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for - now is i2c, and the supported chips are ssd1305, ssd1306, ssd1307 and - ssd1309. - - reg: Should contain address of the controller on the I2C bus. Most likely - 0x3c or 0x3d - - pwm: Should contain the pwm to use according to the OF device tree PWM - specification [0]. Only required for the ssd1307. - - solomon,height: Height in pixel of the screen driven by the controller - - solomon,width: Width in pixel of the screen driven by the controller - - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is - mapped to. - -Optional properties: - - reset-gpios: The GPIO used to reset the OLED display, if available. See - Documentation/devicetree/bindings/gpio/gpio.txt for details. - - vbat-supply: The supply for VBAT - - solomon,segment-no-remap: Display needs normal (non-inverted) data column - to segment mapping - - solomon,col-offset: Offset of columns (COL/SEG) that the screen is mapped to. - - solomon,com-seq: Display uses sequential COM pin configuration - - solomon,com-lrremap: Display uses left-right COM pin remap - - solomon,com-invdir: Display uses inverted COM pin scan direction - - solomon,com-offset: Number of the COM pin wired to the first display line - - solomon,prechargep1: Length of deselect period (phase 1) in clock cycles. - - solomon,prechargep2: Length of precharge period (phase 2) in clock cycles. - This needs to be the higher, the higher the capacitance - of the OLED's pixels is - - solomon,dclk-div: Clock divisor 1 to 16 - - solomon,dclk-frq: Clock frequency 0 to 15, higher value means higher - frequency - - solomon,lookup-table: 8 bit value array of current drive pulse widths for - BANK0, and colors A, B, and C. Each value in range - of 31 to 63 for pulse widths of 32 to 64. Color D - is always width 64. - - solomon,area-color-enable: Display uses color mode - - solomon,low-power. Display runs in low power mode - -[0]: Documentation/devicetree/bindings/pwm/pwm.txt - -Examples: -ssd1307: oled@3c { - compatible = "solomon,ssd1307fb-i2c"; - reg = <0x3c>; - pwms = <&pwm 4 3000>; - reset-gpios = <&gpio2 7>; -}; - -ssd1306: oled@3c { - compatible = "solomon,ssd1306fb-i2c"; - reg = <0x3c>; - pwms = <&pwm 4 3000>; - reset-gpios = <&gpio2 7>; - solomon,com-lrremap; - solomon,com-invdir; - solomon,com-offset = <32>; - solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>; -}; diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt deleted file mode 100644 index 38476475fd60..000000000000 --- a/Documentation/devicetree/bindings/display/zte,vou.txt +++ /dev/null @@ -1,120 +0,0 @@ -ZTE VOU Display Controller - -This is a display controller found on ZTE ZX296718 SoC. It includes multiple -Graphic Layer (GL) and Video Layer (VL), two Mixers/Channels, and a few blocks -handling scaling, color space conversion etc. VOU also integrates the support -for typical output devices, like HDMI, TV Encoder, VGA, and RGB LCD. - -* Master VOU node - -It must be the parent node of all the sub-device nodes. - -Required properties: - - compatible: should be "zte,zx296718-vou" - - #address-cells: should be <1> - - #size-cells: should be <1> - - ranges: list of address translations between VOU and sub-devices - -* VOU DPC device - -Required properties: - - compatible: should be "zte,zx296718-dpc" - - reg: Physical base address and length of DPC register regions, one for each - entry in 'reg-names' - - reg-names: The names of register regions. The following regions are required: - "osd" - "timing_ctrl" - "dtrc" - "vou_ctrl" - "otfppu" - - interrupts: VOU DPC interrupt number to CPU - - clocks: A list of phandle + clock-specifier pairs, one for each entry - in 'clock-names' - - clock-names: A list of clock names. The following clocks are required: - "aclk" - "ppu_wclk" - "main_wclk" - "aux_wclk" - -* HDMI output device - -Required properties: - - compatible: should be "zte,zx296718-hdmi" - - reg: Physical base address and length of the HDMI device IO region - - interrupts : HDMI interrupt number to CPU - - clocks: A list of phandle + clock-specifier pairs, one for each entry - in 'clock-names' - - clock-names: A list of clock names. The following clocks are required: - "osc_cec" - "osc_clk" - "xclk" - -* TV Encoder output device - -Required properties: - - compatible: should be "zte,zx296718-tvenc" - - reg: Physical base address and length of the TVENC device IO region - - zte,tvenc-power-control: the phandle to SYSCTRL block followed by two - integer cells. The first cell is the offset of SYSCTRL register used - to control TV Encoder DAC power, and the second cell is the bit mask. - -* VGA output device - -Required properties: - - compatible: should be "zte,zx296718-vga" - - reg: Physical base address and length of the VGA device IO region - - interrupts : VGA interrupt number to CPU - - clocks: Phandle with clock-specifier pointing to VGA I2C clock. - - clock-names: Must be "i2c_wclk". - - zte,vga-power-control: the phandle to SYSCTRL block followed by two - integer cells. The first cell is the offset of SYSCTRL register used - to control VGA DAC power, and the second cell is the bit mask. - -Example: - -vou: vou@1440000 { - compatible = "zte,zx296718-vou"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x1440000 0x10000>; - - dpc: dpc@0 { - compatible = "zte,zx296718-dpc"; - reg = <0x0000 0x1000>, <0x1000 0x1000>, - <0x5000 0x1000>, <0x6000 0x1000>, - <0xa000 0x1000>; - reg-names = "osd", "timing_ctrl", - "dtrc", "vou_ctrl", - "otfppu"; - interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&topcrm VOU_ACLK>, <&topcrm VOU_PPU_WCLK>, - <&topcrm VOU_MAIN_WCLK>, <&topcrm VOU_AUX_WCLK>; - clock-names = "aclk", "ppu_wclk", - "main_wclk", "aux_wclk"; - }; - - vga: vga@8000 { - compatible = "zte,zx296718-vga"; - reg = <0x8000 0x1000>; - interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&topcrm VGA_I2C_WCLK>; - clock-names = "i2c_wclk"; - zte,vga-power-control = <&sysctrl 0x170 0xe0>; - }; - - hdmi: hdmi@c000 { - compatible = "zte,zx296718-hdmi"; - reg = <0xc000 0x4000>; - interrupts = <GIC_SPI 82 IRQ_TYPE_EDGE_RISING>; - clocks = <&topcrm HDMI_OSC_CEC>, - <&topcrm HDMI_OSC_CLK>, - <&topcrm HDMI_XCLK>; - clock-names = "osc_cec", "osc_clk", "xclk"; - }; - - tvenc: tvenc@2000 { - compatible = "zte,zx296718-tvenc"; - reg = <0x2000 0x1000>; - zte,tvenc-power-control = <&sysctrl 0x170 0x10>; - }; -}; diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml index c1676b96daac..a6df6f8b54db 100644 --- a/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml +++ b/Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml @@ -19,12 +19,12 @@ properties: description: The cell is the request line number. compatible: - oneOf: - - const: allwinner,sun6i-a31-dma - - const: allwinner,sun8i-a23-dma - - const: allwinner,sun8i-a83t-dma - - const: allwinner,sun8i-h3-dma - - const: allwinner,sun8i-v3s-dma + enum: + - allwinner,sun6i-a31-dma + - allwinner,sun8i-a23-dma + - allwinner,sun8i-a83t-dma + - allwinner,sun8i-h3-dma + - allwinner,sun8i-v3s-dma reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt index c9e97409e853..12c316ff4834 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt @@ -9,6 +9,7 @@ Required properties: "fsl,imx53-sdma" "fsl,imx6q-sdma" "fsl,imx7d-sdma" + "fsl,imx6ul-sdma" "fsl,imx8mq-sdma" "fsl,imx8mm-sdma" "fsl,imx8mn-sdma" diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index cebf6ffe70d5..5c4c6782e052 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -34,6 +34,10 @@ properties: - description: SCMI compliant firmware with ARM SMC/HVC transport items: - const: arm,scmi-smc + - description: SCMI compliant firmware with SCMI Virtio transport. + The virtio transport only supports a single device. + items: + - const: arm,scmi-virtio interrupts: description: @@ -172,6 +176,7 @@ patternProperties: Each sub-node represents a protocol supported. If the platform supports a dedicated communication channel for a particular protocol, then the corresponding transport properties must be present. + The virtio transport does not support a dedicated communication channel. properties: reg: @@ -195,7 +200,6 @@ patternProperties: required: - compatible - - shmem if: properties: @@ -209,6 +213,7 @@ then: required: - mboxes + - shmem else: if: @@ -219,6 +224,7 @@ else: then: required: - arm,smc-id + - shmem examples: - | diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml index d7113b06454b..23b346bd1252 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml @@ -131,9 +131,9 @@ properties: properties: compatible: - oneOf: - - const: arm,scpi-dvfs-clocks - - const: arm,scpi-variable-clocks + enum: + - arm,scpi-dvfs-clocks + - arm,scpi-variable-clocks '#clock-cells': const: 1 diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt deleted file mode 100644 index 18c3aea90df2..000000000000 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt +++ /dev/null @@ -1,44 +0,0 @@ ------------------------------------------------------------------ -Device Tree Bindings for the Xilinx Zynq MPSoC Firmware Interface ------------------------------------------------------------------ - -The zynqmp-firmware node describes the interface to platform firmware. -ZynqMP has an interface to communicate with secure firmware. Firmware -driver provides an interface to firmware APIs. Interface APIs can be -used by any driver to communicate to PMUFW(Platform Management Unit). -These requests include clock management, pin control, device control, -power management service, FPGA service and other platform management -services. - -Required properties: - - compatible: Must contain any of below: - "xlnx,zynqmp-firmware" for Zynq Ultrascale+ MPSoC - "xlnx,versal-firmware" for Versal - - method: The method of calling the PM-API firmware layer. - Permitted values are: - - "smc" : SMC #0, following the SMCCC - - "hvc" : HVC #0, following the SMCCC - -------- -Example -------- - -Zynq Ultrascale+ MPSoC ----------------------- -firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - ... - }; -}; - -Versal ------- -firmware { - versal_firmware: versal-firmware { - compatible = "xlnx,versal-firmware"; - method = "smc"; - ... - }; -}; diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml new file mode 100644 index 000000000000..f14f7b454f07 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/xilinx/xlnx,zynqmp-firmware.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx firmware driver + +maintainers: + - Nava kishore Manne <nava.manne@xilinx.com> + +description: The zynqmp-firmware node describes the interface to platform + firmware. ZynqMP has an interface to communicate with secure firmware. + Firmware driver provides an interface to firmware APIs. Interface APIs + can be used by any driver to communicate to PMUFW(Platform Management Unit). + These requests include clock management, pin control, device control, + power management service, FPGA service and other platform management + services. + +properties: + compatible: + oneOf: + - description: For implementations complying for Zynq Ultrascale+ MPSoC. + const: xlnx,zynqmp-firmware + + - description: For implementations complying for Versal. + const: xlnx,versal-firmware + + method: + description: | + The method of calling the PM-API firmware layer. + Permitted values are. + - "smc" : SMC #0, following the SMCCC + - "hvc" : HVC #0, following the SMCCC + + $ref: /schemas/types.yaml#/definitions/string-array + enum: + - smc + - hvc + + versal_fpga: + $ref: /schemas/fpga/xlnx,versal-fpga.yaml# + description: Compatible of the FPGA device. + type: object + + zynqmp-aes: + $ref: /schemas/crypto/xlnx,zynqmp-aes.yaml# + description: The ZynqMP AES-GCM hardened cryptographic accelerator is + used to encrypt or decrypt the data with provided key and initialization + vector. + type: object + + clock-controller: + $ref: /schemas/clock/xlnx,versal-clk.yaml# + description: The clock controller is a hardware block of Xilinx versal + clock tree. It reads required input clock frequencies from the devicetree + and acts as clock provider for all clock consumers of PS clocks.list of + clock specifiers which are external input clocks to the given clock + controller. + type: object + +required: + - compatible + +additionalProperties: false + +examples: + - | + versal-firmware { + compatible = "xlnx,versal-firmware"; + method = "smc"; + + versal_fpga: versal_fpga { + compatible = "xlnx,versal-fpga"; + }; + + xlnx_aes: zynqmp-aes { + compatible = "xlnx,zynqmp-aes"; + }; + + versal_clk: clock-controller { + #clock-cells = <1>; + compatible = "xlnx,versal-clk"; + clocks = <&ref>, <&alt_ref>, <&pl_alt_ref>; + clock-names = "ref", "alt_ref", "pl_alt_ref"; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml new file mode 100644 index 000000000000..ac6a207278d5 --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/xlnx,versal-fpga.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Versal FPGA driver. + +maintainers: + - Nava kishore Manne <nava.manne@xilinx.com> + +description: | + Device Tree Versal FPGA bindings for the Versal SoC, controlled + using firmware interface. + +properties: + compatible: + items: + - enum: + - xlnx,versal-fpga + +required: + - compatible + +additionalProperties: false + +examples: + - | + versal_fpga: versal_fpga { + compatible = "xlnx,versal-fpga"; + }; + +... diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt deleted file mode 100644 index 3052bf619dd5..000000000000 --- a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt +++ /dev/null @@ -1,25 +0,0 @@ -Devicetree bindings for Zynq Ultrascale MPSoC FPGA Manager. -The ZynqMP SoC uses the PCAP (Processor configuration Port) to configure the -Programmable Logic (PL). The configuration uses the firmware interface. - -Required properties: -- compatible: should contain "xlnx,zynqmp-pcap-fpga" - -Example for full FPGA configuration: - - fpga-region0 { - compatible = "fpga-region"; - fpga-mgr = <&zynqmp_pcap>; - #address-cells = <0x1>; - #size-cells = <0x1>; - }; - - firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - zynqmp_pcap: pcap { - compatible = "xlnx,zynqmp-pcap-fpga"; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml new file mode 100644 index 000000000000..6cd2bdc06b5f --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq Ultrascale MPSoC FPGA Manager Device Tree Bindings + +maintainers: + - Nava kishore Manne <navam@xilinx.com> + +description: | + Device Tree Bindings for Zynq Ultrascale MPSoC FPGA Manager. + The ZynqMP SoC uses the PCAP (Processor Configuration Port) to + configure the Programmable Logic (PL). The configuration uses the + firmware interface. + +properties: + compatible: + const: xlnx,zynqmp-pcap-fpga + +required: + - compatible + +additionalProperties: false + +examples: + - | + firmware { + zynqmp_firmware: zynqmp-firmware { + zynqmp_pcap: pcap { + compatible = "xlnx,zynqmp-pcap-fpga"; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml b/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml index e425278653f5..e2ca0b000471 100644 --- a/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml +++ b/Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml @@ -19,7 +19,6 @@ properties: compatible: enum: - ibm,fsi2spi - - ibm,fsi2spi-restricted reg: items: diff --git a/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml new file mode 100644 index 000000000000..46bb121360dc --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/aspeed,sgpio.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/aspeed,sgpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Aspeed SGPIO controller + +maintainers: + - Andrew Jeffery <andrew@aj.id.au> + +description: + This SGPIO controller is for ASPEED AST2400, AST2500 and AST2600 SoC, + AST2600 have two sgpio master one with 128 pins another one with 80 pins, + AST2500/AST2400 have one sgpio master with 80 pins. Each of the Serial + GPIO pins can be programmed to support the following options + - Support interrupt option for each input port and various interrupt + sensitivity option (level-high, level-low, edge-high, edge-low) + - Support reset tolerance option for each output port + - Directly connected to APB bus and its shift clock is from APB bus clock + divided by a programmable value. + - Co-work with external signal-chained TTL components (74LV165/74LV595) + +properties: + compatible: + enum: + - aspeed,ast2400-sgpio + - aspeed,ast2500-sgpio + - aspeed,ast2600-sgpiom + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + clocks: + maxItems: 1 + + ngpios: true + + bus-frequency: true + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - interrupts + - interrupt-controller + - ngpios + - clocks + - bus-frequency + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/aspeed-clock.h> + sgpio: sgpio@1e780200 { + #gpio-cells = <2>; + compatible = "aspeed,ast2500-sgpio"; + gpio-controller; + interrupts = <40>; + reg = <0x1e780200 0x0100>; + clocks = <&syscon ASPEED_CLK_APB>; + interrupt-controller; + ngpios = <80>; + bus-frequency = <12000000>; + }; diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml index d993e002cebe..0d62c28fb58d 100644 --- a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml @@ -22,7 +22,10 @@ properties: maxItems: 1 clocks: - maxItems: 1 + minItems: 1 + items: + - description: APB interface clock source + - description: GPIO debounce reference clock source gpio-controller: true diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt deleted file mode 100644 index be329ea4794f..000000000000 --- a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt +++ /dev/null @@ -1,46 +0,0 @@ -Aspeed SGPIO controller Device Tree Bindings --------------------------------------------- - -This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full -featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to -support the following options: -- Support interrupt option for each input port and various interrupt - sensitivity option (level-high, level-low, edge-high, edge-low) -- Support reset tolerance option for each output port -- Directly connected to APB bus and its shift clock is from APB bus clock - divided by a programmable value. -- Co-work with external signal-chained TTL components (74LV165/74LV595) - -Required properties: - -- compatible : Should be one of - "aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio" -- #gpio-cells : Should be 2, see gpio.txt -- reg : Address and length of the register set for the device -- gpio-controller : Marks the device node as a GPIO controller -- interrupts : Interrupt specifier, see interrupt-controller/interrupts.txt -- interrupt-controller : Mark the GPIO controller as an interrupt-controller -- ngpios : number of *hardware* GPIO lines, see gpio.txt. This will expose - 2 software GPIOs per hardware GPIO: one for hardware input, one for hardware - output. Up to 80 pins, must be a multiple of 8. -- clocks : A phandle to the APB clock for SGPM clock division -- bus-frequency : SGPM CLK frequency - -The sgpio and interrupt properties are further described in their respective -bindings documentation: - -- Documentation/devicetree/bindings/gpio/gpio.txt -- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - - Example: - sgpio: sgpio@1e780200 { - #gpio-cells = <2>; - compatible = "aspeed,ast2500-sgpio"; - gpio-controller; - interrupts = <40>; - reg = <0x1e780200 0x0100>; - clocks = <&syscon ASPEED_CLK_APB>; - interrupt-controller; - ngpios = <8>; - bus-frequency = <12000000>; - }; diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 0f73f436bea7..c5f6092a2855 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -20,6 +20,7 @@ properties: - mediatek,mt8183-mali - realtek,rtd1619-mali - rockchip,px30-mali + - rockchip,rk3568-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable reg: diff --git a/Documentation/devicetree/bindings/hwmon/adt7475.yaml b/Documentation/devicetree/bindings/hwmon/adt7475.yaml index ad0ec9f35bd8..7d9c083632b9 100644 --- a/Documentation/devicetree/bindings/hwmon/adt7475.yaml +++ b/Documentation/devicetree/bindings/hwmon/adt7475.yaml @@ -39,17 +39,7 @@ properties: reg: maxItems: 1 -patternProperties: - "^adi,bypass-attenuator-in[0-4]$": - description: | - Configures bypassing the individual voltage input attenuator. If - set to 1 the attenuator is bypassed if set to 0 the attenuator is - not bypassed. If the property is absent then the attenuator - retains it's configuration from the bios/bootloader. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1] - - "^adi,pwm-active-state$": + adi,pwm-active-state: description: | Integer array, represents the active state of the pwm outputs If set to 0 the pwm uses a logic low output for 100% duty cycle. If set to 1 the pwm @@ -61,6 +51,16 @@ patternProperties: enum: [0, 1] default: 1 +patternProperties: + "^adi,bypass-attenuator-in[0-4]$": + description: | + Configures bypassing the individual voltage input attenuator. If + set to 1 the attenuator is bypassed if set to 0 the attenuator is + not bypassed. If the property is absent then the attenuator + retains it's configuration from the bios/bootloader. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml new file mode 100644 index 000000000000..7598b083979c --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/amd,sbrmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: > + Sideband Remote Management Interface (SB-RMI) compliant + AMD SoC power device. + +maintainers: + - Akshay Gupta <Akshay.Gupta@amd.com> + +description: | + SB Remote Management Interface (SB-RMI) is an SMBus compatible + interface that reports AMD SoC's Power (normalized Power) using, + Mailbox Service Request and resembles a typical 8-pin remote power + sensor's I2C interface to BMC. The power attributes in hwmon + reports power in microwatts. + +properties: + compatible: + enum: + - amd,sbrmi + + reg: + maxItems: 1 + description: | + I2C bus address of the device as specified in Section SBI SMBus Address + of the SoC register reference. The SB-RMI address is normally 78h for + socket 0 and 70h for socket 1, but it could vary based on hardware + address select pins. + \[open source SoC register reference\] + https://www.amd.com/en/support/tech-docs?keyword=55898 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + sbrmi@3c { + compatible = "amd,sbrmi"; + reg = <0x3c>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/hwmon/max1619.txt b/Documentation/devicetree/bindings/hwmon/max1619.txt deleted file mode 100644 index c70dbbe1e56f..000000000000 --- a/Documentation/devicetree/bindings/hwmon/max1619.txt +++ /dev/null @@ -1,12 +0,0 @@ -Bindings for MAX1619 Temperature Sensor - -Required properties: -- compatible : "maxim,max1619" -- reg : I2C address, one of 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b, 0x4c, or - 0x4d, 0x4e - -Example: - temp@4c { - compatible = "maxim,max1619"; - reg = <0x4c>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml b/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml new file mode 100644 index 000000000000..31ce77a4b087 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/hwmon/winbond,w83781d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Winbond W83781 and compatible hardware monitor IC + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +properties: + compatible: + enum: + - winbond,w83781d + - winbond,w83781g + - winbond,w83782d + - winbond,w83783s + - asus,as99127f + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + temperature-sensor@28 { + compatible = "winbond,w83781d"; + reg = <0x28>; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt deleted file mode 100644 index d12cc33cca6c..000000000000 --- a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt +++ /dev/null @@ -1,46 +0,0 @@ -Broadcom iProc I2C controller - -Required properties: - -- compatible: - Must be "brcm,iproc-i2c" or "brcm,iproc-nic-i2c" - -- reg: - Define the base and range of the I/O address space that contain the iProc - I2C controller registers - -- clock-frequency: - This is the I2C bus clock. Need to be either 100000 or 400000 - -- #address-cells: - Always 1 (for I2C addresses) - -- #size-cells: - Always 0 - -Optional properties: - -- interrupts: - Should contain the I2C interrupt. For certain revisions of the I2C - controller, I2C interrupt is unwired to the interrupt controller. In such - case, this property should be left unspecified, and driver will fall back - to polling mode - -- brcm,ape-hsls-addr-mask: - Required for "brcm,iproc-nic-i2c". Host view of address mask into the - 'APE' co-processor. Value must be unsigned, 32-bit - -Example: - i2c0: i2c@18008000 { - compatible = "brcm,iproc-i2c"; - reg = <0x18008000 0x100>; - #address-cells = <1>; - #size-cells = <0>; - interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>; - clock-frequency = <100000>; - - codec: wm8750@1a { - compatible = "wlf,wm8750"; - reg = <0x1a>; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.yaml b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.yaml new file mode 100644 index 000000000000..2aa75b7add7b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/brcm,iproc-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom iProc I2C controller + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +properties: + compatible: + enum: + - brcm,iproc-i2c + - brcm,iproc-nic-i2c + + reg: + maxItems: 1 + + clock-frequency: + enum: [ 100000, 400000 ] + + interrupts: + description: | + Should contain the I2C interrupt. For certain revisions of the I2C + controller, I2C interrupt is unwired to the interrupt controller. In such + case, this property should be left unspecified, and driver will fall back + to polling mode + maxItems: 1 + + brcm,ape-hsls-addr-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Host view of address mask into the 'APE' co-processor + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + - if: + properties: + compatible: + contains: + const: brcm,iproc-nic-i2c + then: + required: + - brcm,ape-hsls-addr-mask + +unevaluatedProperties: false + +required: + - reg + - clock-frequency + - '#address-cells' + - '#size-cells' + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2c@18008000 { + compatible = "brcm,iproc-i2c"; + reg = <0x18008000 0x100>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>; + clock-frequency = <100000>; + + wm8750@1a { + compatible = "wlf,wm8750"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml index 52d92ec7ec0b..402fd125e010 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -27,14 +27,25 @@ properties: interrupts: items: - - description: Transmit End Interrupt (TEI) - - description: Receive Data Full Interrupt (RI) - - description: Transmit Data Empty Interrupt (TI) - - description: Stop Condition Detection Interrupt (SPI) - - description: Start Condition Detection Interrupt (STI) - - description: NACK Reception Interrupt (NAKI) - - description: Arbitration-Lost Interrupt (ALI) - - description: Timeout Interrupt (TMOI) + - description: Transmit End Interrupt + - description: Receive Data Full Interrupt + - description: Transmit Data Empty Interrupt + - description: Stop Condition Detection Interrupt + - description: Start Condition Detection Interrupt + - description: NACK Reception Interrupt + - description: Arbitration-Lost Interrupt + - description: Timeout Interrupt + + interrupt-names: + items: + - const: tei + - const: ri + - const: ti + - const: spi + - const: sti + - const: naki + - const: ali + - const: tmoi clock-frequency: description: @@ -51,6 +62,7 @@ required: - compatible - reg - interrupts + - interrupt-names - clocks - clock-frequency - power-domains @@ -85,6 +97,8 @@ examples: <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "tei", "ri", "ti", "spi", "sti", "naki", "ali", + "tmoi"; clocks = <&mstp9_clks R7S72100_CLK_I2C0>; clock-frequency = <100000>; power-domains = <&cpg_clocks>; diff --git a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml index ff165ad1bee8..db0843be91c5 100644 --- a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml @@ -72,11 +72,11 @@ additionalProperties: false if: properties: compatible: - oneOf: - - const: ti,omap2420-i2c - - const: ti,omap2430-i2c - - const: ti,omap3-i2c - - const: ti,omap4-i2c + enum: + - ti,omap2420-i2c + - ti,omap2430-i2c + - ti,omap3-i2c + - ti,omap4-i2c then: properties: diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml deleted file mode 100644 index a7e84089cc3d..000000000000 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml +++ /dev/null @@ -1,61 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/iio/accel/bosch,bma180.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Bosch BMA023 / BMA150/ BMA180 / BMA250 / SMB380 triaxial accelerometers - -maintainers: - - Jonathan Cameron <jic23@kernel.org> - -description: | - https://media.digikey.com/pdf/Data%20Sheets/Bosch/BMA150.pdf - http://omapworld.com/BMA180_111_1002839.pdf - http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/bst-bma250-ds002-05.pdf - -properties: - compatible: - enum: - - bosch,bma023 - - bosch,bma150 - - bosch,bma180 - - bosch,bma250 - - bosch,smb380 - - reg: - maxItems: 1 - - vdd-supply: true - - vddio-supply: true - - interrupts: - minItems: 1 - maxItems: 2 - description: | - Type should be either IRQ_TYPE_LEVEL_HIGH or IRQ_TYPE_EDGE_RISING. - For the bma250 the first interrupt listed must be the one - connected to the INT1 pin, the second (optional) interrupt - listed must be the one connected to the INT2 pin. - -required: - - compatible - - reg - -additionalProperties: false - -examples: - - | - #include <dt-bindings/interrupt-controller/irq.h> - i2c { - #address-cells = <1>; - #size-cells = <0>; - accel@40 { - compatible = "bosch,bma180"; - reg = <0x40>; - interrupt-parent = <&gpio6>; - interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>; - }; - }; -... diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index e830d5295b92..478e75ae0885 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -8,6 +8,7 @@ title: Bosch BMA255 and Similar Accelerometers maintainers: - Linus Walleij <linus.walleij@linaro.org> + - Stephan Gerhold <stephan@gerhold.net> description: 3 axis accelerometers with varying range and I2C or SPI @@ -16,15 +17,24 @@ description: properties: compatible: enum: - - bosch,bmc150_accel - - bosch,bmi055_accel + # bmc150-accel driver in Linux + - bosch,bma222 + - bosch,bma222e + - bosch,bma250e - bosch,bma253 - bosch,bma254 - bosch,bma255 - - bosch,bma250e - - bosch,bma222 - - bosch,bma222e - bosch,bma280 + - bosch,bmc150_accel + - bosch,bmc156_accel + - bosch,bmi055_accel + + # bma180 driver in Linux + - bosch,bma023 + - bosch,bma150 + - bosch,bma180 + - bosch,bma250 + - bosch,smb380 reg: maxItems: 1 @@ -36,9 +46,21 @@ properties: minItems: 1 maxItems: 2 description: | - The first interrupt listed must be the one connected to the INT1 pin, - the second (optional) interrupt listed must be the one connected to the - INT2 pin (if available). + Without interrupt-names, the first interrupt listed must be the one + connected to the INT1 pin, the second (optional) interrupt listed must be + the one connected to the INT2 pin (if available). The type should be + IRQ_TYPE_EDGE_RISING. + + BMC156 does not have an INT1 pin, therefore the first interrupt pin is + always treated as INT2. + + interrupt-names: + minItems: 1 + maxItems: 2 + items: + enum: + - INT1 + - INT2 mount-matrix: description: an optional 3x3 mounting rotation matrix. @@ -63,7 +85,22 @@ examples: reg = <0x08>; vddio-supply = <&vddio>; vdd-supply = <&vdd>; - interrupts = <57 IRQ_TYPE_EDGE_FALLING>; + interrupts = <57 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "INT1"; + }; + }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + accelerometer@10 { + compatible = "bosch,bmc156_accel"; + reg = <0x10>; + vddio-supply = <&vddio>; + vdd-supply = <&vdd>; + interrupts = <116 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "INT2"; }; }; - | diff --git a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml index 433a3fb55a2e..3eb7aa8822c3 100644 --- a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml @@ -23,6 +23,8 @@ properties: enum: - ingenic,jz4725b-adc - ingenic,jz4740-adc + - ingenic,jz4760-adc + - ingenic,jz4760b-adc - ingenic,jz4770-adc '#io-channel-cells': @@ -43,6 +45,23 @@ properties: interrupts: maxItems: 1 + ingenic,use-internal-divider: + description: + If present, battery voltage is read from the VBAT_IR pin, which has an + internal 1/4 divider. If absent, it is read through the VBAT_ER pin, + which does not have such a divider. + type: boolean + +if: + not: + properties: + compatible: + contains: + const: ingenic,jz4760b-adc +then: + properties: + ingenic,use-internal-divider: false + required: - compatible - '#io-channel-cells' diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml new file mode 100644 index 000000000000..c80201d6a716 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/renesas,rzg2l-adc.yaml @@ -0,0 +1,134 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/renesas,rzg2l-adc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/G2L ADC + +maintainers: + - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> + +description: | + A/D Converter block is a successive approximation analog-to-digital converter + with a 12-bit accuracy. Up to eight analog input channels can be selected. + Conversions can be performed in single or repeat mode. Result of the ADC is + stored in a 32-bit data register corresponding to each channel. + +properties: + compatible: + items: + - enum: + - renesas,r9a07g044-adc # RZ/G2{L,LC} + - const: renesas,rzg2l-adc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: converter clock + - description: peripheral clock + + clock-names: + items: + - const: adclk + - const: pclk + + power-domains: + maxItems: 1 + + resets: + maxItems: 2 + + reset-names: + items: + - const: presetn + - const: adrst-n + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - resets + - reset-names + +patternProperties: + "^channel@[0-7]$": + $ref: "adc.yaml" + type: object + description: | + Represents the external channels which are connected to the ADC. + + properties: + reg: + description: | + The channel number. It can have up to 8 channels numbered from 0 to 7. + items: + - minimum: 0 + maximum: 7 + + required: + - reg + + additionalProperties: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r9a07g044-cpg.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + adc: adc@10059000 { + compatible = "renesas,r9a07g044-adc", "renesas,rzg2l-adc"; + reg = <0x10059000 0x400>; + interrupts = <GIC_SPI 347 IRQ_TYPE_EDGE_RISING>; + clocks = <&cpg CPG_MOD R9A07G044_ADC_ADCLK>, + <&cpg CPG_MOD R9A07G044_ADC_PCLK>; + clock-names = "adclk", "pclk"; + power-domains = <&cpg>; + resets = <&cpg R9A07G044_ADC_PRESETN>, + <&cpg R9A07G044_ADC_ADRST_N>; + reset-names = "presetn", "adrst-n"; + + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + }; + channel@1 { + reg = <1>; + }; + channel@2 { + reg = <2>; + }; + channel@3 { + reg = <3>; + }; + channel@4 { + reg = <4>; + }; + channel@5 { + reg = <5>; + }; + channel@6 { + reg = <6>; + }; + channel@7 { + reg = <7>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml index 1bb76197787b..e512a14e41b4 100644 --- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml @@ -20,6 +20,7 @@ properties: - rockchip,px30-saradc - rockchip,rk3308-saradc - rockchip,rk3328-saradc + - rockchip,rk3568-saradc - rockchip,rv1108-saradc - const: rockchip,rk3399-saradc diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml new file mode 100644 index 000000000000..05ed4e0ec364 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5064.yaml @@ -0,0 +1,268 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5064.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5064 and similar DACs + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + - Jonathan Cameron <jic23@kernel.org> + +description: | + A range of similar DAC devices with between 1 and 12 channels. Some parts + have internal references, others require a single shared external reference + and the remainder have a separate reference pin for each DAC. + +properties: + compatible: + oneOf: + - description: I2C devics + enum: + - adi,ad5024 + - adi,ad5025 + - adi,ad5044 + - adi,ad5045 + - adi,ad5064 + - adi,ad5064-1 + - adi,ad5065 + - adi,ad5628-1 + - adi,ad5628-2 + - adi,ad5648-1 + - adi,ad5648-2 + - adi,ad5666-1 + - adi,ad5666-2 + - adi,ad5668-1 + - adi,ad5668-2 + - adi,ad5668-3 + - description: SPI devices + enum: + - adi,ad5625 + - adi,ad5625r-1v25 + - adi,ad5625r-2v5 + - adi,ad5627 + - adi,ad5627r-1v25 + - adi,ad5627r-2v5 + - adi,ad5629-1 + - adi,ad5629-2 + - adi,ad5629-3 + - adi,ad5645r-1v25 + - adi,ad5645r-2v5 + - adi,ad5665 + - adi,ad5665r-1v25 + - adi,ad5665r-2v5 + - adi,ad5667 + - adi,ad5667r-1v25 + - adi,ad5667r-2v5 + - adi,ad5669-1 + - adi,ad5669-2 + - adi,ad5669-3 + - lltc,ltc2606 + - lltc,ltc2607 + - lltc,ltc2609 + - lltc,ltc2616 + - lltc,ltc2617 + - lltc,ltc2619 + - lltc,ltc2626 + - lltc,ltc2627 + - lltc,ltc2629 + - lltc,ltc2631-l12 + - lltc,ltc2631-h12 + - lltc,ltc2631-l10 + - lltc,ltc2631-h10 + - lltc,ltc2631-l8 + - lltc,ltc2631-h8 + - lltc,ltc2633-l12 + - lltc,ltc2633-h12 + - lltc,ltc2633-l10 + - lltc,ltc2633-h10 + - lltc,ltc2633-l8 + - lltc,ltc2633-h8 + - lltc,ltc2635-l12 + - lltc,ltc2635-h12 + - lltc,ltc2635-l10 + - lltc,ltc2635-h10 + - lltc,ltc2635-l8 + - lltc,ltc2635-h8 + + reg: + maxItems: 1 + + vrefA-supply: true + vrefB-supply: true + vrefC-supply: true + vrefD-supply: true + vref-supply: true + + spi-max-frequency: true + +additionalProperties: false + +required: + - compatible + - reg + +allOf: + - # Shared external vref, no internal reference + if: + properties: + compatible: + contains: + enum: + - adi,ad5064-1 + - adi,ad5625 + - adi,ad5627 + - adi,ad5665 + - adi,ad5667 + - lltc,ltc2606 + - lltc,ltc2607 + - lltc,ltc2616 + - lltc,ltc2617 + - lltc,ltc2626 + - lltc,ltc2627 + then: + properties: + vref-supply: true + vrefA-supply: false + vrefB-supply: false + vrefC-supply: false + vrefD-supply: false + required: + - vref-supply + - # Shared external vref, internal reference available + if: + properties: + compatible: + contains: + enum: + - adi,ad5625r-1v25 + - adi,ad5625r-2v5 + - adi,ad5627r-1v25 + - adi,ad5627r-2v5 + - adi,ad5628-1 + - adi,ad5628-2 + - adi,ad5629-1 + - adi,ad5629-2 + - adi,ad5629-3 + - adi,ad5645r-1v25 + - adi,ad5645r-2v5 + - adi,ad5647r-1v25 + - adi,ad5647r-2v5 + - adi,ad5648-1 + - adi,ad5648-2 + - adi,ad5665r-1v25 + - adi,ad5665r-2v5 + - adi,ad5666-1 + - adi,ad5666-2 + - adi,ad5667r-1v25 + - adi,ad5667r-2v5 + - adi,ad5668-1 + - adi,ad5668-2 + - adi,ad5668-3 + - adi,ad5669-1 + - adi,ad5669-2 + - adi,ad5669-3 + - lltc,ltc2631-l12 + - lltc,ltc2631-h12 + - lltc,ltc2631-l10 + - lltc,ltc2631-h10 + - lltc,ltc2631-l8 + - lltc,ltc2631-h8 + - lltc,ltc2633-l12 + - lltc,ltc2633-h12 + - lltc,ltc2633-l10 + - lltc,ltc2633-h10 + - lltc,ltc2633-l8 + - lltc,ltc2633-h8 + - lltc,ltc2635-l12 + - lltc,ltc2635-h12 + - lltc,ltc2635-l10 + - lltc,ltc2635-h10 + - lltc,ltc2635-l8 + - lltc,ltc2635-h8 + then: + properties: + vref-supply: true + vrefA-supply: false + vrefB-supply: false + vrefC-supply: false + vrefD-supply: false + - # 4 input devices, separate vrefs, no internal reference + if: + properties: + compatible: + contains: + enum: + - adi,ad5024 + - adi,ad5044 + - adi,ad5064 + - lltc,ltc2609 + - lltc,ltc2619 + - lltc,ltc2629 + then: + properties: + vrefA-supply: true + vrefB-supply: true + vrefC-supply: true + vrefD-supply: true + vref-supply: false + required: + - vrefA-supply + - vrefB-supply + - vrefC-supply + - vrefD-supply + - # 2 input devices, separate vrefs, no internal reference + if: + properties: + compatible: + contains: + enum: + - adi,ad5025 + - adi,ad5045 + - adi,ad5065 + then: + properties: + vrefA-supply: true + vrefB-supply: true + vrefC-supply: false + vrefD-supply: false + vref-supply: false + required: + - vrefA-supply + - vrefB-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5625"; + vref-supply = <&dac_vref>; + }; + }; + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5625r-1v25"; + }; + }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + dac@42 { + reg = <0x42>; + compatible = "adi,ad5024"; + vrefA-supply = <&dac_vref>; + vrefB-supply = <&dac_vref>; + vrefC-supply = <&dac_vref2>; + vrefD-supply = <&dac_vref2>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml new file mode 100644 index 000000000000..0d8fb56f4b09 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5360.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5360.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5360 and similar DACs + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + - Jonathan Cameron <jic23@kernel.org> + +properties: + compatible: + enum: + - adi,ad5360 + - adi,ad5361 + - adi,ad5363 + - adi,ad5370 + - adi,ad5371 + - adi,ad5372 + - adi,ad5373 + + reg: + maxItems: 1 + + vref0-supply: true + vref1-supply: true + vref2-supply: true + + spi-max-frequency: true + +additionalProperties: false + +required: + - compatible + - reg + - vref0-supply + - vref1-supply + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,ad5360 + - adi,ad5361 + - adi,ad5363 + - adi,ad5370 + - adi,ad5372 + - adi,ad5373 + then: + properties: + vref2-supply: false + - if: + properties: + compatible: + contains: + enum: + - adi,ad5371 + then: + required: + - vref2-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5371"; + vref0-supply = <&dac_vref0>; + vref1-supply = <&dac_vref1>; + vref2-supply = <&dac_vref2>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml new file mode 100644 index 000000000000..d599b418a020 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5380.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5380 and similar DACs + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + - Jonathan Cameron <jic23@kernel.org> + +description: | + DAC devices supporting both SPI and I2C interfaces. +properties: + compatible: + enum: + - adi,ad5380-3 + - adi,ad5380-5 + - adi,ad5381-3 + - adi,ad5381-5 + - adi,ad5382-3 + - adi,ad5382-5 + - adi,ad5383-3 + - adi,ad5383-5 + - adi,ad5384-3 + - adi,ad5384-5 + - adi,ad5390-3 + - adi,ad5390-5 + - adi,ad5391-3 + - adi,ad5391-5 + - adi,ad5392-3 + - adi,ad5392-5 + + reg: + maxItems: 1 + + vref-supply: + description: + If not supplied devices will use internal regulators. + + spi-max-frequency: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5390-5"; + vref-supply = <&dacvref>; + }; + }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + dac@42 { + reg = <0x42>; + compatible = "adi,ad5380-3"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml new file mode 100644 index 000000000000..188f656617e3 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5421.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5421.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5421 DAC + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + - Jonathan Cameron <jic23@kernel.org> + +description: | + AD5421 is designed for us in loop-powered, 4 mA to 20 mA smart transmitter + applications. It provides a 16-bit DAC, current amplifier, voltage regulator + to drive the loop and a voltage reference. + +properties: + compatible: + const: adi,ad5421 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + description: Fault signal. + + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "adi,ad5421"; + reg = <0>; + spi-max-frequency = <30000000>; + interrupts = <55 IRQ_TYPE_LEVEL_HIGH>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml new file mode 100644 index 000000000000..044332c97743 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5449.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5449.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5449 and similar DACs + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + - Jonathan Cameron <jic23@kernel.org> + +description: + Family of multiplying DACs from Analog Devices + +properties: + compatible: + enum: + - adi,ad5415 + - adi,ad5426 + - adi,ad5429 + - adi,ad5432 + - adi,ad5439 + - adi,ad5443 + - adi,ad5449 + + reg: + maxItems: 1 + + spi-max-frequency: true + + VREF-supply: true + VREFA-supply: true + VREFB-supply: true + +additionalProperties: false + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,ad5415 + - adi,ad5426 + - adi,ad5432 + then: + properties: + VREF-supply: true + VREFA-supply: false + VREFB-supply: false + required: + - VREF-supply + - if: + properties: + compatible: + contains: + enum: + - adi,ad5429 + - adi,ad5439 + - adi,ad5449 + then: + properties: + VREF-supply: false + VREFA-supply: true + VREFB-supply: true + required: + - VREFA-supply + - VREFB-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5415"; + VREF-supply = <&dac_ref>; + }; + }; + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5429"; + VREFA-supply = <&dac_refA>; + VREFB-supply = <&dac_refB>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5504.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5504.yaml new file mode 100644 index 000000000000..9c2c038683b4 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5504.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5504.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5501 and AD5504 DACs + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + - Jonathan Cameron <jic23@kernel.org> + +description: + High voltage (up to 60V) DACs with temperature sensor alarm function + +properties: + compatible: + enum: + - adi,ad5501 + - adi,ad5504 + + reg: + maxItems: 1 + + interrupts: + description: Used for temperature alarm. + maxItems: 1 + + vcc-supply: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5504"; + vcc-supply = <&dac_vcc>; + interrupts = <55 IRQ_TYPE_EDGE_FALLING>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml new file mode 100644 index 000000000000..330383b85eeb --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5624r.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5624r.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5624r and similar DACs + +maintainers: + - Jonathan Cameron <jic23@kernel.org> + +properties: + compatible: + enum: + - adi,ad5624r3 + - adi,ad5644r3 + - adi,ad5664r3 + - adi,ad5624r5 + - adi,ad5644r5 + - adi,ad5664r5 + + reg: + maxItems: 1 + + spi-max-frequency: true + + vref-supply: + description: If not present, internal reference will be used. + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5624r3"; + vref-supply = <&vref>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml new file mode 100644 index 000000000000..5c26441eae9f --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5686.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5360 and similar DACs + +maintainers: + - Michael Hennerich <michael.hennerich@analog.com> + - Jonathan Cameron <jic23@kernel.org> + +properties: + compatible: + oneOf: + - description: SPI devices + enum: + - adi,ad5310r + - adi,ad5672r + - adi,ad5674r + - adi,ad5676 + - adi,ad5676r + - adi,ad5679r + - adi,ad5681r + - adi,ad5682r + - adi,ad5683 + - adi,ad5683r + - adi,ad5684 + - adi,ad5684r + - adi,ad5685r + - adi,ad5686 + - adi,ad5686r + - description: I2C devices + enum: + - adi,ad5311r + - adi,ad5338r + - adi,ad5671r + - adi,ad5675r + - adi,ad5691r + - adi,ad5692r + - adi,ad5693 + - adi,ad5693r + - adi,ad5694 + - adi,ad5694r + - adi,ad5695r + - adi,ad5696 + - adi,ad5696r + + + reg: + maxItems: 1 + + vcc-supply: + description: If not supplied the internal reference is used. + + spi-max-frequency: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + dac@0 { + reg = <0>; + compatible = "adi,ad5310r"; + vcc-supply = <&dac_vref0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml new file mode 100644 index 000000000000..7f95a9ed55fe --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5761.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5761.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5761 and similar DACs + +maintainers: + - Ricardo Ribalda <ribalda@kernel.org> + - Jonathan Cameron <jic23@kernel.org> + +properties: + + compatible: + enum: + - adi,ad5721 + - adi,ad5721r + - adi,ad5761 + - adi,ad5761r + + reg: + maxItems: 1 + + spi-max-frequency: true + + vref-supply: + description: If not supplied, internal reference will be used. + +additionalProperties: false + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,ad5721 + - adi,ad5761 + then: + required: + - vref-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "adi,ad5721"; + reg = <0>; + vref-supply = <&dac_vref>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml new file mode 100644 index 000000000000..8e893d52bfb1 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5764.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5764.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5744 and AD5764 DAC families + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + - Jonathan Cameron <jic23@kernel.org> + +properties: + + compatible: + enum: + - adi,ad5744 + - adi,ad5744r + - adi,ad5764 + - adi,ad5764r + + reg: + maxItems: 1 + + spi-max-frequency: true + + vrefAB-supply: true + vrefCD-supply: true + +additionalProperties: false + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,ad5744 + - adi,ad5764 + then: + required: + - vrefAB-supply + - vrefCD-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "adi,ad5744"; + reg = <0>; + vrefAB-supply = <&dac_vref>; + vrefCD-supply = <&dac_vref>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml new file mode 100644 index 000000000000..650d1ebdcec3 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5791.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5791 and similar DACs + +maintainers: + - Michael Hennerich <michael.hennerich@analog.com> + - Jonathan Cameron <jic23@kernel.org> + +properties: + + compatible: + enum: + - adi,ad5760 + - adi,ad5780 + - adi,ad5781 + - adi,ad5790 + - adi,ad5791 + + reg: + maxItems: 1 + + spi-max-frequency: true + + vdd-supply: true + vss-supply: true + +additionalProperties: false + +required: + - compatible + - reg + - vdd-supply + - vss-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "adi,ad5791"; + reg = <0>; + vss-supply = <&dac_vss>; + vdd-supply = <&dac_vdd>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml new file mode 100644 index 000000000000..6a3990a8d0ad --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad8801.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad8801.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD8801 and AD8803 DACs + +maintainers: + - Jonathan Cameron <jic23@kernel.org> + +properties: + + compatible: + enum: + - adi,ad8801 + - adi,ad8803 + + reg: + maxItems: 1 + + spi-max-frequency: true + + vrefh-supply: true + vrefl-supply: true + +additionalProperties: false + +required: + - compatible + - reg + - vrefh-supply + +allOf: + - if: + properties: + compatible: + contains: + const: adi,ad8803 + then: + required: + - vrefl-supply + else: + properties: + vrefl-supply: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "adi,ad8803"; + reg = <0>; + vrefl-supply = <&dac_vrefl>; + vrefh-supply = <&dac_vrefh>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml new file mode 100644 index 000000000000..12a14b3f36cb --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp4922.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/microchip,mcp4922.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MCP4902, MCP4912 and MPC4922 dual output SPI DACs + +maintainers: + - Jonathan Cameron <jic23@kernel.org> + - Michael Welling <mwelling@ieee.org> + +properties: + compatible: + enum: + - microchip,mcp4902 + - microchip,mcp4912 + - microchip,mcp4922 + + reg: + maxItems: 1 + + spi-max-frequency: true + + vref-supply: true + +additionalProperties: false + +required: + - compatible + - reg + - vref-supply + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "microchip,mcp4912"; + reg = <0>; + vref-supply = <&dac_vref>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index b2a1e42c56fa..71de5631ebae 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -152,47 +152,6 @@ allOf: maxItems: 1 st,drdy-int-pin: false - - if: - properties: - compatible: - enum: - # Two intertial interrupts i.e. accelerometer/gyro interrupts - - st,h3lis331dl-accel - - st,l3g4200d-gyro - - st,l3g4is-gyro - - st,l3gd20-gyro - - st,l3gd20h-gyro - - st,lis2de12 - - st,lis2dw12 - - st,lis2hh12 - - st,lis2dh12-accel - - st,lis331dl-accel - - st,lis331dlh-accel - - st,lis3de - - st,lis3dh-accel - - st,lis3dhh - - st,lis3mdl-magn - - st,lng2dm-accel - - st,lps331ap-press - - st,lsm303agr-accel - - st,lsm303dlh-accel - - st,lsm303dlhc-accel - - st,lsm303dlm-accel - - st,lsm330-accel - - st,lsm330-gyro - - st,lsm330d-accel - - st,lsm330d-gyro - - st,lsm330dl-accel - - st,lsm330dl-gyro - - st,lsm330dlc-accel - - st,lsm330dlc-gyro - - st,lsm9ds0-gyro - - st,lsm9ds1-magn - then: - properties: - interrupts: - maxItems: 2 - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index d6a95c3cb26f..e701524ee811 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,sc7180-osm-l3 + - qcom,sc8180x-osm-l3 - qcom,sdm845-osm-l3 - qcom,sm8150-osm-l3 - qcom,sm8250-epss-l3 diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 5accc0d113be..3fd1a134162d 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -49,6 +49,17 @@ properties: - qcom,sc7280-mmss-noc - qcom,sc7280-nsp-noc - qcom,sc7280-system-noc + - qcom,sc8180x-aggre1-noc + - qcom,sc8180x-aggre2-noc + - qcom,sc8180x-camnoc-virt + - qcom,sc8180x-compute-noc + - qcom,sc8180x-config-noc + - qcom,sc8180x-dc-noc + - qcom,sc8180x-gem-noc + - qcom,sc8180x-ipa-virt + - qcom,sc8180x-mc-virt + - qcom,sc8180x-mmss-noc + - qcom,sc8180x-system-noc - qcom,sdm845-aggre1-noc - qcom,sdm845-aggre2-noc - qcom,sdm845-config-noc diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml index edf26452dc72..750cc44628e9 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml @@ -19,10 +19,10 @@ allOf: properties: compatible: - oneOf: - - const: loongson,liointc-1.0 - - const: loongson,liointc-1.0a - - const: loongson,liointc-2.0 + enum: + - loongson,liointc-1.0 + - loongson,liointc-1.0a + - loongson,liointc-2.0 reg: minItems: 1 diff --git a/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt b/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt deleted file mode 100644 index 19af687858a1..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt +++ /dev/null @@ -1,50 +0,0 @@ -* Samsung Exynos Interrupt Combiner Controller - -Samsung's Exynos4 architecture includes a interrupt combiner controller which -can combine interrupt sources as a group and provide a single interrupt request -for the group. The interrupt request from each group are connected to a parent -interrupt controller, such as GIC in case of Exynos4210. - -The interrupt combiner controller consists of multiple combiners. Up to eight -interrupt sources can be connected to a combiner. The combiner outputs one -combined interrupt for its eight interrupt sources. The combined interrupt -is usually connected to a parent interrupt controller. - -A single node in the device tree is used to describe the interrupt combiner -controller module (which includes multiple combiners). A combiner in the -interrupt controller module shares config/control registers with other -combiners. For example, a 32-bit interrupt enable/disable config register -can accommodate up to 4 interrupt combiners (with each combiner supporting -up to 8 interrupt sources). - -Required properties: -- compatible: should be "samsung,exynos4210-combiner". -- interrupt-controller: Identifies the node as an interrupt controller. -- #interrupt-cells: should be <2>. The meaning of the cells are - * First Cell: Combiner Group Number. - * Second Cell: Interrupt number within the group. -- reg: Base address and size of interrupt combiner registers. -- interrupts: The list of interrupts generated by the combiners which are then - connected to a parent interrupt controller. The format of the interrupt - specifier depends in the interrupt parent controller. - -Optional properties: -- samsung,combiner-nr: The number of interrupt combiners supported. If this - property is not specified, the default number of combiners is assumed - to be 16. - - -Example: - - The following is a an example from the Exynos4210 SoC dtsi file. - - combiner:interrupt-controller@10440000 { - compatible = "samsung,exynos4210-combiner"; - interrupt-controller; - #interrupt-cells = <2>; - reg = <0x10440000 0x1000>; - interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, - <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, - <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, - <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.yaml b/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.yaml new file mode 100644 index 000000000000..d631b7589d50 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/samsung,exynos4210-combiner.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC Interrupt Combiner Controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + Samsung's Exynos4 architecture includes a interrupt combiner controller which + can combine interrupt sources as a group and provide a single interrupt + request for the group. The interrupt request from each group are connected to + a parent interrupt controller, such as GIC in case of Exynos4210. + + The interrupt combiner controller consists of multiple combiners. Up to eight + interrupt sources can be connected to a combiner. The combiner outputs one + combined interrupt for its eight interrupt sources. The combined interrupt is + usually connected to a parent interrupt controller. + + A single node in the device tree is used to describe the interrupt combiner + controller module (which includes multiple combiners). A combiner in the + interrupt controller module shares config/control registers with other + combiners. For example, a 32-bit interrupt enable/disable config register can + accommodate up to 4 interrupt combiners (with each combiner supporting up to + 8 interrupt sources). + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + const: samsung,exynos4210-combiner + + interrupt-controller: true + + interrupts: + minItems: 8 + maxItems: 32 + + "#interrupt-cells": + description: | + The meaning of the cells are: + * First Cell: Combiner Group Number. + * Second Cell: Interrupt number within the group. + const: 2 + + reg: + maxItems: 1 + + samsung,combiner-nr: + description: | + The number of interrupt combiners supported. Should match number + of interrupts set in "interrupts" property. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 8 + maximum: 32 + default: 16 + +required: + - compatible + - interrupt-controller + - interrupts + - "#interrupt-cells" + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + interrupt-controller@10440000 { + compatible = "samsung,exynos4210-combiner"; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0x10440000 0x1000>; + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml index 051beb45d998..65523d9459d8 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml @@ -46,7 +46,7 @@ properties: AM437x family of SoCs, AM57xx family of SoCs 66AK2G family of SoCs - Use "ti,icssg-intc" for K3 AM65x & J721E family of SoCs + Use "ti,icssg-intc" for K3 AM65x, J721E and AM64x family of SoCs reg: maxItems: 1 @@ -95,6 +95,8 @@ properties: - AM65x and J721E SoCs have "host_intr5", "host_intr6" and "host_intr7" interrupts connected to MPU, and other ICSSG instances. + - AM64x SoCs have all the 8 host interrupts connected to various + other SoC entities required: - compatible diff --git a/Documentation/devicetree/bindings/iommu/apple,dart.yaml b/Documentation/devicetree/bindings/iommu/apple,dart.yaml new file mode 100644 index 000000000000..94aa9e9afa59 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/apple,dart.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/apple,dart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple DART IOMMU + +maintainers: + - Sven Peter <sven@svenpeter.dev> + +description: |+ + Apple SoCs may contain an implementation of their Device Address + Resolution Table which provides a mandatory layer of address + translations for various masters. + + Each DART instance is capable of handling up to 16 different streams + with individual pagetables and page-level read/write protection flags. + + This DART IOMMU also raises interrupts in response to various + fault conditions. + +properties: + compatible: + const: apple,t8103-dart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: + Reference to the gate clock phandle if required for this IOMMU. + Optional since not all IOMMUs are attached to a clock gate. + + '#iommu-cells': + const: 1 + description: + Has to be one. The single cell describes the stream id emitted by + a master to the IOMMU. + +required: + - compatible + - reg + - '#iommu-cells' + - interrupts + +additionalProperties: false + +examples: + - |+ + dart1: iommu@82f80000 { + compatible = "apple,t8103-dart"; + reg = <0x82f80000 0x4000>; + interrupts = <1 781 4>; + #iommu-cells = <1>; + }; + + master1 { + iommus = <&dart1 0>; + }; + + - |+ + dart2a: iommu@82f00000 { + compatible = "apple,t8103-dart"; + reg = <0x82f00000 0x4000>; + interrupts = <1 781 4>; + #iommu-cells = <1>; + }; + dart2b: iommu@82f80000 { + compatible = "apple,t8103-dart"; + reg = <0x82f80000 0x4000>; + interrupts = <1 781 4>; + #iommu-cells = <1>; + }; + + master2 { + iommus = <&dart2a 0>, <&dart2b 1>; + }; diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 1181b590db71..03f2b2d4db30 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -52,16 +52,14 @@ properties: items: - const: marvell,ap806-smmu-500 - const: arm,mmu-500 - - description: NVIDIA SoCs that program two ARM MMU-500s identically - items: - description: NVIDIA SoCs that require memory controller interaction and may program multiple ARM MMU-500s identically with the memory controller interleaving translations between multiple instances for improved performance. items: - enum: - - const: nvidia,tegra194-smmu - - const: nvidia,tegra186-smmu + - nvidia,tegra194-smmu + - nvidia,tegra186-smmu - const: nvidia,smmu-500 - items: - const: arm,mmu-500 diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml index d2e28a9e3545..ba9124f721f1 100644 --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml @@ -28,14 +28,12 @@ properties: - description: configuration registers for MMU instance 0 - description: configuration registers for MMU instance 1 minItems: 1 - maxItems: 2 interrupts: items: - description: interruption for MMU instance 0 - description: interruption for MMU instance 1 minItems: 1 - maxItems: 2 clocks: items: diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index b1f363747a62..697102707703 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -128,6 +128,12 @@ properties: as a panic indicator. type: boolean + retain-state-shutdown: + description: + This property specifies that the LED should not be turned off or changed + when the system shuts down. + type: boolean + trigger-sources: description: | List of devices which should be used as a source triggering this LED diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 7771ecaac586..89a59b9c81f9 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -9,8 +9,8 @@ CMDQ driver uses mailbox framework for communication. Please refer to mailbox.txt for generic information about mailbox device-tree bindings. Required properties: -- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce" or - "mediatek,mt6779-gce". +- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce", + "mediatek,mt8192-gce", "mediatek,mt8195-gce" or "mediatek,mt6779-gce". - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -35,9 +35,14 @@ Optional properties for a client device: start_offset: the start offset of register address that GCE can access. size: the total size of register address that GCE can access. +Optional properties for a client mutex node: +- mediatek,gce-events: GCE events used by clients. The event numbers are + defined in 'dt-bindings/gce/<chip>-gce.h'. + Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h', -'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as -sub-system ids, thread priority, event ids. +'dt-binding/gce/mt8183-gce.h', 'dt-binding/gce/mt8192-gce.h', +'dt-binding/gce/mt8195-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. +Such as sub-system ids, thread priority, event ids. Example: @@ -62,3 +67,14 @@ Example for a client device: <&gce SUBSYS_1401XXXX 0x2000 0x100>; ... }; + +Example for a client mutex node: + mutex: mutex@14020000 { + compatible = "mediatek,mt8173-disp-mutex"; + reg = <0 0x14020000 0 0x1000>; + interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_MUTEX_32K>; + mediatek,gce-events = <CMDQ_EVENT_MUTEX0_STREAM_EOF>, + <CMDQ_EVENT_MUTEX1_STREAM_EOF>; + }; diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 8878ec00820e..6395281b0cec 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -20,6 +20,7 @@ properties: - qcom,ipq8074-apcs-apps-global - qcom,msm8916-apcs-kpss-global - qcom,msm8939-apcs-kpss-global + - qcom,msm8953-apcs-kpss-global - qcom,msm8994-apcs-kpss-global - qcom,msm8996-apcs-hmss-global - qcom,msm8998-apcs-hmss-global @@ -29,6 +30,7 @@ properties: - qcom,sdm660-apcs-hmss-global - qcom,sdm845-apss-shared - qcom,sm6125-apcs-hmss-global + - qcom,sm6115-apcs-hmss-global - qcom,sm8150-apss-shared reg: diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml index b222f993b232..866efb278813 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml @@ -24,6 +24,7 @@ properties: compatible: items: - enum: + - qcom,sm6350-ipcc - qcom,sm8250-ipcc - qcom,sm8350-ipcc - qcom,sc7280-ipcc diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml new file mode 100644 index 000000000000..4432fea32650 --- /dev/null +++ b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/amlogic,meson-ir-tx.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson IR transmitter + +maintainers: + - Viktor Prutyanov <viktor.prutyanov@phystech.edu> + +description: | + Some Amlogic SoCs such as A311D and T950D4 have IR transmitter + (also called blaster) controller onboard. It is capable of + sending IR signals with arbitrary carrier frequency and duty cycle. + +properties: + compatible: + oneOf: + - const: amlogic,meson-ir-tx + - items: + - const: amlogic,meson-g12a-ir-tx + - const: amlogic,meson-ir-tx + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: sysclk + - const: xtal + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/g12a-clkc.h> + + ir@ff80014c { + compatible = "amlogic,meson-g12a-ir-tx", "amlogic,meson-ir-tx"; + reg = <0xff80014c 0x10>; + interrupts = <0 198 IRQ_TYPE_EDGE_RISING>; + clocks = <&clkc CLKID_CLK81>, <&xtal>; + clock-names = "sysclk", "xtal"; + }; diff --git a/Documentation/devicetree/bindings/media/atmel,isc.yaml b/Documentation/devicetree/bindings/media/atmel,isc.yaml index 3e4bb8892d94..cd6d7af0c768 100644 --- a/Documentation/devicetree/bindings/media/atmel,isc.yaml +++ b/Documentation/devicetree/bindings/media/atmel,isc.yaml @@ -44,7 +44,8 @@ properties: const: isc-mck port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Input port node, single endpoint describing the input pad. diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml index 3ce4af143a3a..c8d887eee3bb 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml @@ -35,6 +35,14 @@ properties: powerdown-gpios: maxItems: 1 + reset-gpios: + maxItems: 1 + + adv,force-bt656-4: + description: + Indicates that the output is a BT.656-4 compatible stream. + type: boolean + port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml index 701f4e0d138f..39395ea8c318 100644 --- a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml +++ b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml @@ -83,10 +83,10 @@ properties: link-frequencies: true data-lanes: true bus-type: - oneOf: - - const: 1 # CSI-2 C-PHY - - const: 3 # CCP2 - - const: 4 # CSI-2 D-PHY + enum: + - 1 # CSI-2 C-PHY + - 3 # CCP2 + - 4 # CSI-2 D-PHY required: - link-frequencies diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml new file mode 100644 index 000000000000..ad42992c6da3 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov9282.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Intel Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov9282.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OmniVision OV9282 Sensor + +maintainers: + - Paul J. Murphy <paul.j.murphy@intel.com> + - Daniele Alessandrelli <daniele.alessandrelli@intel.com> + +description: + OV9282 sensor is an OmniVision black & white CMOS active pixel digital image + sensor with an active array size of 1296H x 816V. It is programmable through + I2C interface. The I2C client address is fixed to 0x60/0x70 as per sensor data + sheet. Image data is sent through MIPI CSI-2. + +properties: + compatible: + const: ovti,ov9282 + reg: + description: I2C address + maxItems: 1 + + assigned-clocks: true + assigned-clock-parents: true + assigned-clock-rates: true + + clocks: + description: Clock frequency from 6 to 27MHz + maxItems: 1 + + reset-gpios: + description: Reference to the GPIO connected to the XCLR pin, if any. + maxItems: 1 + + port: + additionalProperties: false + $ref: /schemas/graph.yaml#/properties/port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: true + link-frequencies: true + + required: + - data-lanes + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - port + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + camera@60 { + compatible = "ovti,ov9282"; + reg = <0x60>; + clocks = <&ov9282_clk>; + + assigned-clocks = <&ov9282_clk>; + assigned-clock-parents = <&ov9282_clk_parent>; + assigned-clock-rates = <24000000>; + + port { + ov9282: endpoint { + remote-endpoint = <&cam>; + data-lanes = <1 2>; + link-frequencies = /bits/ 64 <800000000>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml new file mode 100644 index 000000000000..881f79532501 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Intel Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/sony,imx335.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sony IMX335 Sensor + +maintainers: + - Paul J. Murphy <paul.j.murphy@intel.com> + - Daniele Alessandrelli <daniele.alessandrelli@intel.com> + +description: + IMX335 sensor is a Sony CMOS active pixel digital image sensor with an active + array size of 2592H x 1944V. It is programmable through I2C interface. The + I2C client address is fixed to 0x1a as per sensor data sheet. Image data is + sent through MIPI CSI-2. + +properties: + compatible: + const: sony,imx335 + reg: + description: I2C address + maxItems: 1 + + assigned-clocks: true + assigned-clock-parents: true + assigned-clock-rates: true + + clocks: + description: Clock frequency from 6 to 27 MHz, 37.125MHz, 74.25MHz + maxItems: 1 + + reset-gpios: + description: Reference to the GPIO connected to the XCLR pin, if any. + maxItems: 1 + + port: + additionalProperties: false + $ref: /schemas/graph.yaml#/properties/port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: true + link-frequencies: true + + required: + - data-lanes + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - port + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + camera@1a { + compatible = "sony,imx335"; + reg = <0x1a>; + clocks = <&imx335_clk>; + + assigned-clocks = <&imx335_clk>; + assigned-clock-parents = <&imx335_clk_parent>; + assigned-clock-rates = <24000000>; + + port { + imx335: endpoint { + remote-endpoint = <&cam>; + data-lanes = <1 2 3 4>; + link-frequencies = /bits/ 64 <594000000>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml new file mode 100644 index 000000000000..1edeabf39e6a --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Intel Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/sony,imx412.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sony IMX412 Sensor + +maintainers: + - Paul J. Murphy <paul.j.murphy@intel.com> + - Daniele Alessandrelli <daniele.alessandrelli@intel.com> + +description: + IMX412 sensor is a Sony CMOS active pixel digital image sensor with an active + array size of 4072H x 3176V. It is programmable through I2C interface. The + I2C client address is fixed to 0x1a as per sensor data sheet. Image data is + sent through MIPI CSI-2. + +properties: + compatible: + const: sony,imx412 + reg: + description: I2C address + maxItems: 1 + + assigned-clocks: true + assigned-clock-parents: true + assigned-clock-rates: true + + clocks: + description: Clock frequency 6MHz, 12MHz, 18MHz, 24MHz or 27MHz + maxItems: 1 + + reset-gpios: + description: Reference to the GPIO connected to the XCLR pin, if any. + maxItems: 1 + + port: + additionalProperties: false + $ref: /schemas/graph.yaml#/properties/port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: true + link-frequencies: true + + required: + - data-lanes + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - port + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + camera@1a { + compatible = "sony,imx412"; + reg = <0x1a>; + clocks = <&imx412_clk>; + + assigned-clocks = <&imx412_clk>; + assigned-clock-parents = <&imx412_clk_parent>; + assigned-clock-rates = <24000000>; + + port { + imx412: endpoint { + remote-endpoint = <&cam>; + data-lanes = <1 2 3 4>; + link-frequencies = /bits/ 64 <600000000>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml index 41afe2e5f133..086e1430af4f 100644 --- a/Documentation/devicetree/bindings/media/microchip,xisc.yaml +++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml @@ -52,7 +52,7 @@ properties: of the data and clock lines. port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base description: Input port node, single endpoint describing the input pad. diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml index d91575b8ebb9..5922a2795167 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/media/nxp,imx7-csi.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: i.MX7 CMOS Sensor Interface +title: i.MX7 and i.MX8 CSI bridge (CMOS Sensor Interface) maintainers: - Rui Miguel Silva <rmfrfs@gmail.com> @@ -15,9 +15,13 @@ description: | properties: compatible: - enum: - - fsl,imx7-csi - - fsl,imx6ul-csi + oneOf: + - enum: + - fsl,imx7-csi + - fsl,imx6ul-csi + - items: + - const: fsl,imx8mm-csi + - const: fsl,imx7-csi reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml index 7c09eec78ce5..877183cf4278 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml @@ -200,8 +200,6 @@ examples: clock-names = "pclk", "wrap", "phy", "axi"; power-domains = <&mipi_pd>; - status = "disabled"; - ports { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml index 5d13cbb5251b..3cc6f42aeb76 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml @@ -16,12 +16,17 @@ description: |- properties: compatible: - items: - - enum: - # JPEG decoder - - nxp,imx8qxp-jpgdec - # JPEG encoder - - nxp,imx8qxp-jpgenc + oneOf: + - items: + enum: + - nxp,imx8qxp-jpgdec + - nxp,imx8qxp-jpgenc + - items: + - const: nxp,imx8qm-jpgdec + - const: nxp,imx8qxp-jpgdec + - items: + - const: nxp,imx8qm-jpgenc + - const: nxp,imx8qxp-jpgenc reg: maxItems: 1 @@ -69,7 +74,7 @@ examples: }; jpegenc: jpegenc@58450000 { - compatible = "nxp,imx8qxp-jpgenc"; + compatible = "nxp,imx8qm-jpgenc", "nxp,imx8qxp-jpgenc"; reg = <0x58450000 0x00050000 >; interrupts = <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>, diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml new file mode 100644 index 000000000000..9c04fa85ee5c --- /dev/null +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/nxp,imx8mq-mipi-csi2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8MQ MIPI CSI-2 receiver + +maintainers: + - Martin Kepplinger <martin.kepplinger@puri.sm> + +description: |- + This binding covers the CSI-2 RX PHY and host controller included in the + NXP i.MX8MQ SoC. It handles the sensor/image input and process for all the + input imaging devices. + +properties: + compatible: + enum: + - fsl,imx8mq-mipi-csi2 + + reg: + maxItems: 1 + + clocks: + items: + - description: core is the RX Controller Core Clock input. This clock + must be exactly equal to or faster than the receive + byteclock from the RX DPHY. + - description: esc is the Rx Escape Clock. This must be the same escape + clock that the RX DPHY receives. + - description: ui is the pixel clock (phy_ref up to 333Mhz). + See the reference manual for details. + + clock-names: + items: + - const: core + - const: esc + - const: ui + + power-domains: + maxItems: 1 + + resets: + items: + - description: CORE_RESET reset register bit definition + - description: PHY_REF_RESET reset register bit definition + - description: ESC_RESET reset register bit definition + + fsl,mipi-phy-gpr: + description: | + The phandle to the imx8mq syscon iomux-gpr with the register + for setting RX_ENABLE for the mipi receiver. + + The format should be as follows: + <gpr req_gpr> + gpr is the phandle to general purpose register node. + req_gpr is the gpr register offset of RX_ENABLE for the mipi phy. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + items: + - description: The 'gpr' is the phandle to general purpose register node. + - description: The 'req_gpr' is the gpr register offset containing + CSI2_1_RX_ENABLE or CSI2_2_RX_ENABLE respectively. + maximum: 0xff + + interconnects: + maxItems: 1 + + interconnect-names: + const: dram + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port node, single endpoint describing the CSI-2 transmitter. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + items: + minItems: 1 + maxItems: 4 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + required: + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Output port node + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + - resets + - fsl,mipi-phy-gpr + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mq-clock.h> + #include <dt-bindings/interconnect/imx8mq.h> + #include <dt-bindings/reset/imx8mq-reset.h> + + csi@30a70000 { + compatible = "fsl,imx8mq-mipi-csi2"; + reg = <0x30a70000 0x1000>; + clocks = <&clk IMX8MQ_CLK_CSI1_CORE>, + <&clk IMX8MQ_CLK_CSI1_ESC>, + <&clk IMX8MQ_CLK_CSI1_PHY_REF>; + clock-names = "core", "esc", "ui"; + assigned-clocks = <&clk IMX8MQ_CLK_CSI1_CORE>, + <&clk IMX8MQ_CLK_CSI1_PHY_REF>, + <&clk IMX8MQ_CLK_CSI1_ESC>; + assigned-clock-rates = <266000000>, <200000000>, <66000000>; + assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>, + <&clk IMX8MQ_SYS2_PLL_1000M>, + <&clk IMX8MQ_SYS1_PLL_800M>; + power-domains = <&pgc_mipi_csi1>; + resets = <&src IMX8MQ_RESET_MIPI_CSI1_CORE_RESET>, + <&src IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET>, + <&src IMX8MQ_RESET_MIPI_CSI1_ESC_RESET>; + fsl,mipi-phy-gpr = <&iomuxc_gpr 0x88>; + interconnects = <&noc IMX8MQ_ICM_CSI1 &noc IMX8MQ_ICS_DRAM>; + interconnect-names = "dram"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + imx8mm_mipi_csi_in: endpoint { + remote-endpoint = <&imx477_out>; + data-lanes = <1 2 3 4>; + }; + }; + + port@1 { + reg = <1>; + + imx8mm_mipi_csi_out: endpoint { + remote-endpoint = <&csi_in>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/renesas,drif.yaml b/Documentation/devicetree/bindings/media/renesas,drif.yaml index 817a6d566738..9403b235e976 100644 --- a/Documentation/devicetree/bindings/media/renesas,drif.yaml +++ b/Documentation/devicetree/bindings/media/renesas,drif.yaml @@ -96,7 +96,7 @@ properties: Indicates that the channel acts as primary among the bonded channels. port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false description: Child port node corresponding to the data input. The port node must @@ -242,7 +242,6 @@ examples: power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; resets = <&cpg 513>; renesas,bonding = <&drif11>; - status = "disabled"; }; drif11: rif@e6f70000 { diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index b88172a59de7..bacb60a34989 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -22,6 +22,7 @@ properties: - rockchip,rk3288-vpu - rockchip,rk3328-vpu - rockchip,rk3399-vpu + - rockchip,px30-vpu - items: - const: rockchip,rk3188-vpu - const: rockchip,rk3066-vpu diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml index 7a63c85ef8c5..01c9acf9275d 100644 --- a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml @@ -57,7 +57,6 @@ properties: ranges: minItems: 1 - maxItems: 3 description: | Memory bus areas for interacting with the devices. Reflects the memory layout with four integer values following: diff --git a/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt b/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt deleted file mode 100644 index c81af75bcd88..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/ath79-ddr-controller.txt +++ /dev/null @@ -1,35 +0,0 @@ -Binding for Qualcomm Atheros AR7xxx/AR9xxx DDR controller - -The DDR controller of the AR7xxx and AR9xxx families provides an interface -to flush the FIFO between various devices and the DDR. This is mainly used -by the IRQ controller to flush the FIFO before running the interrupt handler -of such devices. - -Required properties: - -- compatible: has to be "qca,<soc-type>-ddr-controller", - "qca,[ar7100|ar7240]-ddr-controller" as fallback. - On SoC with PCI support "qca,ar7100-ddr-controller" should be used as - fallback, otherwise "qca,ar7240-ddr-controller" should be used. -- reg: Base address and size of the controller's memory area -- #qca,ddr-wb-channel-cells: Specifies the number of cells needed to encode - the write buffer channel index, should be 1. - -Example: - - ddr_ctrl: memory-controller@18000000 { - compatible = "qca,ar9132-ddr-controller", - "qca,ar7240-ddr-controller"; - reg = <0x18000000 0x100>; - - #qca,ddr-wb-channel-cells = <1>; - }; - - ... - - interrupt-controller { - ... - qca,ddr-wb-channel-interrupts = <2>, <3>, <4>, <5>; - qca,ddr-wb-channels = <&ddr_ctrl 3>, <&ddr_ctrl 2>, - <&ddr_ctrl 0>, <&ddr_ctrl 1>; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt deleted file mode 100644 index 82d923ef413f..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt +++ /dev/null @@ -1,27 +0,0 @@ -DDR PHY Front End (DPFE) for Broadcom STB -========================================= - -DPFE and the DPFE firmware provide an interface for the host CPU to -communicate with the DCPU, which resides inside the DDR PHY. - -There are three memory regions for interacting with the DCPU. These are -specified in a single reg property. - -Required properties: - - compatible: must be "brcm,bcm7271-dpfe-cpu", "brcm,bcm7268-dpfe-cpu" - or "brcm,dpfe-cpu" - - reg: must reference three register ranges - - start address and length of the DCPU register space - - start address and length of the DCPU data memory space - - start address and length of the DCPU instruction memory space - - reg-names: must contain "dpfe-cpu", "dpfe-dmem", and "dpfe-imem"; - they must be in the same order as the register declarations - -Example: - dpfe_cpu0: dpfe-cpu@f1132000 { - compatible = "brcm,bcm7271-dpfe-cpu", "brcm,dpfe-cpu"; - reg = <0xf1132000 0x180 - 0xf1134000 0x1000 - 0xf1138000 0x4000>; - reg-names = "dpfe-cpu", "dpfe-dmem", "dpfe-imem"; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml new file mode 100644 index 000000000000..769f13250047 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/brcm,dpfe-cpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DDR PHY Front End (DPFE) for Broadcom STB + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Markus Mayer <mmayer@broadcom.com> + +properties: + compatible: + items: + - enum: + - brcm,bcm7271-dpfe-cpu + - brcm,bcm7268-dpfe-cpu + - const: brcm,dpfe-cpu + + reg: + items: + - description: DCPU register space + - description: DCPU data memory space + - description: DCPU instruction memory space + + reg-names: + items: + - const: dpfe-cpu + - const: dpfe-dmem + - const: dpfe-imem + +required: + - compatible + - reg + - reg-names + +additionalProperties: false + +examples: + - | + dpfe-cpu@f1132000 { + compatible = "brcm,bcm7271-dpfe-cpu", "brcm,dpfe-cpu"; + reg = <0xf1132000 0x180>, + <0xf1134000 0x1000>, + <0xf1138000 0x4000>; + reg-names = "dpfe-cpu", "dpfe-dmem", "dpfe-imem"; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt b/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt deleted file mode 100644 index 02e4a1f862f1..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/exynos5422-dmc.txt +++ /dev/null @@ -1,84 +0,0 @@ -* Exynos5422 frequency and voltage scaling for Dynamic Memory Controller device - -The Samsung Exynos5422 SoC has DMC (Dynamic Memory Controller) to which the DRAM -memory chips are connected. The driver is to monitor the controller in runtime -and switch frequency and voltage. To monitor the usage of the controller in -runtime, the driver uses the PPMU (Platform Performance Monitoring Unit), which -is able to measure the current load of the memory. -When 'userspace' governor is used for the driver, an application is able to -switch the DMC and memory frequency. - -Required properties for DMC device for Exynos5422: -- compatible: Should be "samsung,exynos5422-dmc". -- clocks : list of clock specifiers, must contain an entry for each - required entry in clock-names for CLK_FOUT_SPLL, CLK_MOUT_SCLK_SPLL, - CLK_FF_DOUT_SPLL2, CLK_FOUT_BPLL, CLK_MOUT_BPLL, CLK_SCLK_BPLL, - CLK_MOUT_MX_MSPLL_CCORE, CLK_MOUT_MX_MSPLL_CCORE_PHY, CLK_MOUT_MCLK_CDREX, -- clock-names : should include "fout_spll", "mout_sclk_spll", "ff_dout_spll2", - "fout_bpll", "mout_bpll", "sclk_bpll", "mout_mx_mspll_ccore", - "mout_mclk_cdrex" entries -- devfreq-events : phandles for PPMU devices connected to this DMC. -- vdd-supply : phandle for voltage regulator which is connected. -- reg : registers of two CDREX controllers. -- operating-points-v2 : phandle for OPPs described in v2 definition. -- device-handle : phandle of the connected DRAM memory device. For more - information please refer to documentation file: - Documentation/devicetree/bindings/ddr/lpddr3.txt -- devfreq-events : phandles of the PPMU events used by the controller. -- samsung,syscon-clk : phandle of the clock register set used by the controller, - these registers are used for enabling a 'pause' feature and are not - exposed by clock framework but they must be used in a safe way. - The register offsets are in the driver code and specyfic for this SoC - type. - -Optional properties for DMC device for Exynos5422: -- interrupt-parent : The parent interrupt controller. -- interrupts : Contains the IRQ line numbers for the DMC internal performance - event counters in DREX0 and DREX1 channels. Align with specification of the - interrupt line(s) in the interrupt-parent controller. -- interrupt-names : IRQ names "drex_0" and "drex_1", the order should be the - same as in the 'interrupts' list above. - -Example: - - ppmu_dmc0_0: ppmu@10d00000 { - compatible = "samsung,exynos-ppmu"; - reg = <0x10d00000 0x2000>; - clocks = <&clock CLK_PCLK_PPMU_DREX0_0>; - clock-names = "ppmu"; - events { - ppmu_event_dmc0_0: ppmu-event3-dmc0_0 { - event-name = "ppmu-event3-dmc0_0"; - }; - }; - }; - - dmc: memory-controller@10c20000 { - compatible = "samsung,exynos5422-dmc"; - reg = <0x10c20000 0x10000>, <0x10c30000 0x10000>; - clocks = <&clock CLK_FOUT_SPLL>, - <&clock CLK_MOUT_SCLK_SPLL>, - <&clock CLK_FF_DOUT_SPLL2>, - <&clock CLK_FOUT_BPLL>, - <&clock CLK_MOUT_BPLL>, - <&clock CLK_SCLK_BPLL>, - <&clock CLK_MOUT_MX_MSPLL_CCORE>, - <&clock CLK_MOUT_MCLK_CDREX>; - clock-names = "fout_spll", - "mout_sclk_spll", - "ff_dout_spll2", - "fout_bpll", - "mout_bpll", - "sclk_bpll", - "mout_mx_mspll_ccore", - "mout_mclk_cdrex"; - operating-points-v2 = <&dmc_opp_table>; - devfreq-events = <&ppmu_event3_dmc0_0>, <&ppmu_event3_dmc0_1>, - <&ppmu_event3_dmc1_0>, <&ppmu_event3_dmc1_1>; - device-handle = <&samsung_K3QF2F20DB>; - vdd-supply = <&buck1_reg>; - samsung,syscon-clk = <&clock>; - interrupt-parent = <&combiner>; - interrupts = <16 0>, <16 1>; - interrupt-names = "drex_0", "drex_1"; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/marvell,mvebu-sdram-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/marvell,mvebu-sdram-controller.yaml new file mode 100644 index 000000000000..14a6bc8f421f --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/marvell,mvebu-sdram-controller.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/marvell,mvebu-sdram-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell MVEBU SDRAM controller + +maintainers: + - Jan Luebbe <jlu@pengutronix.de> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: marvell,armada-xp-sdram-controller + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + memory-controller@1400 { + compatible = "marvell,armada-xp-sdram-controller"; + reg = <0x1400 0x500>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt deleted file mode 100644 index 89657d1d4cd4..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt +++ /dev/null @@ -1,21 +0,0 @@ -Device Tree bindings for MVEBU SDRAM controllers - -The Marvell EBU SoCs all have a SDRAM controller. The SDRAM controller -differs from one SoC variant to another, but they also share a number -of commonalities. - -For now, this Device Tree binding documentation only documents the -Armada XP SDRAM controller. - -Required properties: - - - compatible: for Armada XP, "marvell,armada-xp-sdram-controller" - - reg: a resource specifier for the register space, which should - include all SDRAM controller registers as per the datasheet. - -Example: - -sdramc@1400 { - compatible = "marvell,armada-xp-sdram-controller"; - reg = <0x1400 0x500>; -}; diff --git a/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml b/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml new file mode 100644 index 000000000000..9566b3421f03 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/qca,ath79-ddr-controller.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/qca,ath79-ddr-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Atheros AR7xxx/AR9xxx DDR controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + The DDR controller of the AR7xxx and AR9xxx families provides an interface to + flush the FIFO between various devices and the DDR. This is mainly used by + the IRQ controller to flush the FIFO before running the interrupt handler of + such devices. + +properties: + compatible: + oneOf: + - items: + - const: qca,ar9132-ddr-controller + - const: qca,ar7240-ddr-controller + - items: + - enum: + - qca,ar7100-ddr-controller + - qca,ar7240-ddr-controller + + "#qca,ddr-wb-channel-cells": + description: | + Specifies the number of cells needed to encode the write buffer channel + index. + $ref: /schemas/types.yaml#/definitions/uint32 + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - "#qca,ddr-wb-channel-cells" + - reg + +additionalProperties: false + +examples: + - | + ddr_ctrl: memory-controller@18000000 { + compatible = "qca,ar9132-ddr-controller", + "qca,ar7240-ddr-controller"; + reg = <0x18000000 0x100>; + + #qca,ddr-wb-channel-cells = <1>; + }; + + interrupt-controller { + // ... + qca,ddr-wb-channel-interrupts = <2>, <3>, <4>, <5>; + qca,ddr-wb-channels = <&ddr_ctrl 3>, <&ddr_ctrl 2>, + <&ddr_ctrl 0>, <&ddr_ctrl 1>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.txt b/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.txt deleted file mode 100644 index cdf406c902e2..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.txt +++ /dev/null @@ -1,12 +0,0 @@ -* H8/300 bus controller - -Required properties: - - compatible: Must be "renesas,h8300-bsc". - - reg: Base address and length of BSC registers. - -Example. - bsc: memory-controller@fee01e { - compatible = "renesas,h8300h-bsc", "renesas,h8300-bsc"; - reg = <0xfee01e 8>; - }; - diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml new file mode 100644 index 000000000000..2b18cef99511 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,h8300-bsc.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/renesas,h8300-bsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: H8/300 bus controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Yoshinori Sato <ysato@users.sourceforge.jp> + +properties: + compatible: + items: + - enum: + - renesas,h8300h-bsc + - renesas,h8s-bsc + - const: renesas,h8300-bsc + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + memory-controller@fee01e { + compatible = "renesas,h8300h-bsc", "renesas,h8300-bsc"; + reg = <0xfee01e 8>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 990489fdd2ac..d25072c414e4 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -61,12 +61,23 @@ patternProperties: type: object properties: compatible: - enum: - - cfi-flash - - jedec,spi-nor + contains: + enum: + - cfi-flash + - jedec,spi-nor unevaluatedProperties: false +required: + - compatible + - reg + - reg-names + - clocks + - power-domains + - resets + - '#address-cells' + - '#size-cells' + examples: - | #include <dt-bindings/clock/renesas-cpg-mssr.h> diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml new file mode 100644 index 000000000000..6f4fd5814bf4 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/samsung,exynos5422-dmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: | + Samsung Exynos5422 SoC frequency and voltage scaling for Dynamic Memory + Controller device + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Lukasz Luba <lukasz.luba@arm.com> + +description: | + The Samsung Exynos5422 SoC has DMC (Dynamic Memory Controller) to which the + DRAM memory chips are connected. The driver is to monitor the controller in + runtime and switch frequency and voltage. To monitor the usage of the + controller in runtime, the driver uses the PPMU (Platform Performance + Monitoring Unit), which is able to measure the current load of the memory. + When 'userspace' governor is used for the driver, an application is able to + switch the DMC and memory frequency. + +properties: + compatible: + items: + - const: samsung,exynos5422-dmc + + clock-names: + items: + - const: fout_spll + - const: mout_sclk_spll + - const: ff_dout_spll2 + - const: fout_bpll + - const: mout_bpll + - const: sclk_bpll + - const: mout_mx_mspll_ccore + - const: mout_mclk_cdrex + + clocks: + minItems: 8 + maxItems: 8 + + devfreq-events: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + minItems: 1 + maxItems: 16 + description: phandles of the PPMU events used by the controller. + + device-handle: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: | + phandle of the connected DRAM memory device. For more information please + refer to documentation file: Documentation/devicetree/bindings/ddr/lpddr3.txt + + operating-points-v2: true + + interrupts: + items: + - description: DMC internal performance event counters in DREX0 + - description: DMC internal performance event counters in DREX1 + + interrupt-names: + items: + - const: drex_0 + - const: drex_1 + + reg: + items: + - description: registers of DREX0 + - description: registers of DREX1 + + samsung,syscon-clk: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: | + Phandle of the clock register set used by the controller, these registers + are used for enabling a 'pause' feature and are not exposed by clock + framework but they must be used in a safe way. The register offsets are + in the driver code and specyfic for this SoC type. + + vdd-supply: true + +required: + - compatible + - clock-names + - clocks + - devfreq-events + - device-handle + - reg + - samsung,syscon-clk + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5420.h> + ppmu_dmc0_0: ppmu@10d00000 { + compatible = "samsung,exynos-ppmu"; + reg = <0x10d00000 0x2000>; + clocks = <&clock CLK_PCLK_PPMU_DREX0_0>; + clock-names = "ppmu"; + events { + ppmu_event_dmc0_0: ppmu-event3-dmc0-0 { + event-name = "ppmu-event3-dmc0_0"; + }; + }; + }; + + memory-controller@10c20000 { + compatible = "samsung,exynos5422-dmc"; + reg = <0x10c20000 0x10000>, <0x10c30000 0x10000>; + clocks = <&clock CLK_FOUT_SPLL>, + <&clock CLK_MOUT_SCLK_SPLL>, + <&clock CLK_FF_DOUT_SPLL2>, + <&clock CLK_FOUT_BPLL>, + <&clock CLK_MOUT_BPLL>, + <&clock CLK_SCLK_BPLL>, + <&clock CLK_MOUT_MX_MSPLL_CCORE>, + <&clock CLK_MOUT_MCLK_CDREX>; + clock-names = "fout_spll", + "mout_sclk_spll", + "ff_dout_spll2", + "fout_bpll", + "mout_bpll", + "sclk_bpll", + "mout_mx_mspll_ccore", + "mout_mclk_cdrex"; + operating-points-v2 = <&dmc_opp_table>; + devfreq-events = <&ppmu_event3_dmc0_0>, <&ppmu_event3_dmc0_1>, + <&ppmu_event3_dmc1_0>, <&ppmu_event3_dmc1_1>; + device-handle = <&samsung_K3QF2F20DB>; + vdd-supply = <&buck1_reg>; + samsung,syscon-clk = <&clock>; + interrupt-parent = <&combiner>; + interrupts = <16 0>, <16 1>; + interrupt-names = "drex_0", "drex_1"; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml b/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml new file mode 100644 index 000000000000..a24588474625 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/synopsys,ddrc-ecc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys IntelliDDR Multi Protocol memory controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Manish Narani <manish.narani@xilinx.com> + - Michal Simek <michal.simek@xilinx.com> + +description: | + The ZynqMP DDR ECC controller has an optional ECC support in 64-bit and + 32-bit bus width configurations. + + The Zynq DDR ECC controller has an optional ECC support in half-bus width + (16-bit) configuration. + + These both ECC controllers correct single bit ECC errors and detect double bit + ECC errors. + +properties: + compatible: + enum: + - xlnx,zynq-ddrc-a05 + - xlnx,zynqmp-ddrc-2.40a + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: xlnx,zynqmp-ddrc-2.40a + then: + required: + - interrupts + else: + properties: + interrupts: false + +additionalProperties: false + +examples: + - | + memory-controller@f8006000 { + compatible = "xlnx,zynq-ddrc-a05"; + reg = <0xf8006000 0x1000>; + }; + + - | + axi { + #address-cells = <2>; + #size-cells = <2>; + + memory-controller@fd070000 { + compatible = "xlnx,zynqmp-ddrc-2.40a"; + reg = <0x0 0xfd070000 0x0 0x30000>; + interrupt-parent = <&gic>; + interrupts = <0 112 4>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/synopsys.txt b/Documentation/devicetree/bindings/memory-controllers/synopsys.txt deleted file mode 100644 index 9d32762c47e1..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/synopsys.txt +++ /dev/null @@ -1,32 +0,0 @@ -Binding for Synopsys IntelliDDR Multi Protocol Memory Controller - -The ZynqMP DDR ECC controller has an optional ECC support in 64-bit and 32-bit -bus width configurations. - -The Zynq DDR ECC controller has an optional ECC support in half-bus width -(16-bit) configuration. - -These both ECC controllers correct single bit ECC errors and detect double bit -ECC errors. - -Required properties: - - compatible: One of: - - 'xlnx,zynq-ddrc-a05' : Zynq DDR ECC controller - - 'xlnx,zynqmp-ddrc-2.40a' : ZynqMP DDR ECC controller - - reg: Should contain DDR controller registers location and length. - -Required properties for "xlnx,zynqmp-ddrc-2.40a": - - interrupts: Property with a value describing the interrupt number. - -Example: - memory-controller@f8006000 { - compatible = "xlnx,zynq-ddrc-a05"; - reg = <0xf8006000 0x1000>; - }; - - mc: memory-controller@fd070000 { - compatible = "xlnx,zynqmp-ddrc-2.40a"; - reg = <0x0 0xfd070000 0x0 0x30000>; - interrupt-parent = <&gic>; - interrupts = <0 112 4>; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,da8xx-ddrctl.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,da8xx-ddrctl.yaml new file mode 100644 index 000000000000..9ed51185ff99 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ti,da8xx-ddrctl.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ti,da8xx-ddrctl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments da8xx DDR2/mDDR memory controller + +maintainers: + - Bartosz Golaszewski <bgolaszewski@baylibre.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + Documentation: + OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf + +properties: + compatible: + const: ti,da850-ddr-controller + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + memory-controller@b0000000 { + compatible = "ti,da850-ddr-controller"; + reg = <0xb0000000 0xe8>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt deleted file mode 100644 index ec1dd408d573..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller - -The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs features -a set of registers which allow to tweak the controller's behavior. - -Documentation: -OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf - -Required properties: - -- compatible: "ti,da850-ddr-controller" - for da850 SoC based boards -- reg: a tuple containing the base address of the memory - controller and the size of the memory area to map - -Example for da850 shown below. - -ddrctl { - compatible = "ti,da850-ddr-controller"; - reg = <0xb0000000 0xe8>; -}; diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index 4991a6415796..2b53dcc0ea61 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -26,10 +26,10 @@ Required properties: * "x-powers,axp803" * "x-powers,axp806" * "x-powers,axp805", "x-powers,axp806" + * "x-powers,axp305", "x-powers,axp805", "x-powers,axp806" * "x-powers,axp809" * "x-powers,axp813" - reg: The I2C slave address or RSB hardware address for the AXP chip -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin - interrupt-controller: The PMIC has its own internal IRQs - #interrupt-cells: Should be set to 1 @@ -43,6 +43,7 @@ more information: AXP20x/LDO3: software-based implementation Optional properties: +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz AXP152/20X: range: 750-1875, Default: 1.5 MHz AXP22X/8XX: range: 1800-4050, Default: 3 MHz diff --git a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml new file mode 100644 index 000000000000..fc1317ab3226 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/brcm,cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom CRU + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +description: | + Broadcom CRU ("Clock and Reset Unit" or "Central Resource Unit") is a hardware + block grouping smaller blocks. On Broadcom Northstar platform it contains e.g. + clocks, pinctrl, USB PHY and thermal. + +properties: + compatible: + items: + - enum: + - brcm,ns-cru + - const: simple-mfd + + reg: + description: CRU registers + + ranges: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + pinctrl: + $ref: ../pinctrl/brcm,ns-pinmux.yaml + +patternProperties: + '^clock-controller@[a-f0-9]+$': + $ref: ../clock/brcm,iproc-clocks.yaml + + '^thermal@[a-f0-9]+$': + $ref: ../thermal/brcm,ns-thermal.yaml + +additionalProperties: false + +required: + - reg + +examples: + - | + cru-bus@1800c100 { + compatible = "brcm,ns-cru", "simple-mfd"; + reg = <0x1800c100 0x1d0>; + ranges; + #address-cells = <1>; + #size-cells = <1>; + + clock-controller@100 { + #clock-cells = <1>; + compatible = "brcm,nsp-lcpll0"; + reg = <0x100 0x14>; + clocks = <&osc>; + clock-output-names = "lcpll0", "pcie_phy", "sdio", "ddr_phy"; + }; + + clock-controller@140 { + #clock-cells = <1>; + compatible = "brcm,nsp-genpll"; + reg = <0x140 0x24>; + clocks = <&osc>; + clock-output-names = "genpll", "phy", "ethernetclk", "usbclk", + "iprocfast", "sata1", "sata2"; + }; + + pinctrl { + compatible = "brcm,bcm4708-pinmux"; + offset = <0x1c0>; + }; + + thermal@2c0 { + compatible = "brcm,ns-thermal"; + reg = <0x2c0 0x10>; + #thermal-sensor-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml new file mode 100644 index 000000000000..22edcb4b212f --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/hisilicon,hi6421-spmi-pmic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HiSilicon 6421v600 SPMI PMIC + +maintainers: + - Mauro Carvalho Chehab <mchehab+huawei@kernel.org> + +description: | + HiSilicon 6421v600 should be connected inside a MIPI System Power Management + (SPMI) bus. It provides interrupts and power supply. + + The GPIO and interrupt settings are represented as part of the top-level PMIC + node. + + The SPMI controller part is provided by + Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml + +properties: + $nodename: + pattern: "pmic@[0-9a-f]" + + compatible: + const: hisilicon,hi6421v600-spmi + + reg: + maxItems: 1 + + '#interrupt-cells': + const: 2 + + interrupt-controller: true + + interrupts: + maxItems: 1 + + regulators: + type: object + + additionalProperties: false + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + patternProperties: + '^ldo[0-9]+$': + type: object + + $ref: "/schemas/regulator/regulator.yaml#" + + unevaluatedProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + + pmic: pmic@0 { + compatible = "hisilicon,hi6421v600-spmi"; + reg = <0 0>; + + #interrupt-cells = <2>; + interrupt-controller; + interrupt-parent = <&gpio28>; + interrupts = <0 0>; + + regulators { + #address-cells = <1>; + #size-cells = <0>; + + ldo3: ldo3 { + regulator-name = "ldo3"; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <2000000>; + regulator-boot-on; + }; + + ldo4: ldo4 { + regulator-name = "ldo4"; + regulator-min-microvolt = <1725000>; + regulator-max-microvolt = <1900000>; + regulator-boot-on; + }; + + ldo9: ldo9 { + regulator-name = "ldo9"; + regulator-min-microvolt = <1750000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + }; + + ldo15: ldo15 { + regulator-name = "ldo15"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3000000>; + regulator-always-on; + }; + + ldo16: ldo16 { + regulator-name = "ldo16"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3000000>; + regulator-boot-on; + }; + + ldo17: ldo17 { + regulator-name = "ldo17"; + regulator-min-microvolt = <2500000>; + regulator-max-microvolt = <3300000>; + }; + + ldo33: ldo33 { + regulator-name = "ldo33"; + regulator-min-microvolt = <2500000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + }; + + ldo34: ldo34 { + regulator-name = "ldo34"; + regulator-min-microvolt = <2600000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml index 779936850ee0..ec3138c1bbfc 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml @@ -53,7 +53,9 @@ patternProperties: properties: compatible: - const: qcom,pm8008-gpio + items: + - const: qcom,pm8008-gpio + - const: qcom,spmi-gpio reg: description: Peripheral address of one of the two GPIO peripherals. @@ -61,6 +63,9 @@ patternProperties: gpio-controller: true + gpio-ranges: + maxItems: 1 + interrupt-controller: true "#interrupt-cells": @@ -75,6 +80,7 @@ patternProperties: - gpio-controller - interrupt-controller - "#gpio-cells" + - gpio-ranges - "#interrupt-cells" additionalProperties: false @@ -107,10 +113,11 @@ examples: interrupt-parent = <&tlmm>; interrupts = <32 IRQ_TYPE_EDGE_RISING>; - gpio@c000 { - compatible = "qcom,pm8008-gpio"; + pm8008_gpios: gpio@c000 { + compatible = "qcom,pm8008-gpio", "qcom,spmi-gpio"; reg = <0xc000>; gpio-controller; + gpio-ranges = <&pm8008_gpios 0 0 2>; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index f14ae6da0068..abe3fd817e0b 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -45,9 +45,12 @@ properties: - microchip,sparx5-cpu-syscon - mstar,msc313-pmsleep - rockchip,px30-qos + - rockchip,rk3036-qos - rockchip,rk3066-qos + - rockchip,rk3228-qos - rockchip,rk3288-qos - rockchip,rk3399-qos + - rockchip,rk3568-qos - samsung,exynos3-sysreg - samsung,exynos4-sysreg - samsung,exynos5-sysreg diff --git a/Documentation/devicetree/bindings/mfd/ti,lp87565-q1.yaml b/Documentation/devicetree/bindings/mfd/ti,lp87565-q1.yaml index 48d4d53c25f9..012d25111054 100644 --- a/Documentation/devicetree/bindings/mfd/ti,lp87565-q1.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,lp87565-q1.yaml @@ -11,9 +11,9 @@ maintainers: properties: compatible: - oneOf: - - const: ti,lp87565 - - const: ti,lp87565-q1 + enum: + - ti,lp87565 + - ti,lp87565-q1 reg: description: I2C slave address diff --git a/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml b/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml new file mode 100644 index 000000000000..6aeedda3be15 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/ti,tps65086.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/ti,tps65086.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TPS65086 Power Management Integrated Circuit (PMIC) + +maintainers: + - Emil Renner Berthing <kernel@esmil.dk> + +properties: + compatible: + const: ti,tps65086 + + reg: + const: 0x5e + description: I2C slave address + + 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 trigger masks from ../interrupt-controller/interrupts.txt. + + gpio-controller: true + + '#gpio-cells': + const: 2 + description: | + The first cell is the pin number and the second cell is used to specify + flags. See ../gpio/gpio.txt for more information. + + regulators: + type: object + description: | + List of child nodes that specify the regulator initialization data. + Child nodes must be named after their hardware counterparts: + buck[1-6], ldoa[1-3], swa1, swb[1-2], and vtt. + Each child node is defined using the standard binding for regulators and + the optional regulator properties defined below. + + patternProperties: + "^buck[1-6]$": + type: object + $ref: ../regulator/regulator.yaml + + properties: + regulator-name: true + regulator-boot-on: true + regulator-always-on: true + regulator-min-microvolt: true + regulator-max-microvolt: true + ti,regulator-step-size-25mv: + type: boolean + description: | + Set this if the regulator is factory set with a 25mv step voltage + mapping. + ti,regulator-decay: + type: boolean + description: | + Set this if the output needs to decay, default is for the output + to slew down. + + additionalProperties: false + + "^(ldoa[1-3]|swa1|swb[1-2]|vtt)$": + type: object + $ref: ../regulator/regulator.yaml + + properties: + regulator-name: true + regulator-boot-on: true + regulator-always-on: true + regulator-min-microvolt: true + regulator-max-microvolt: true + + additionalProperties: false + +additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - regulators + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + pmic: pmic@5e { + compatible = "ti,tps65086"; + reg = <0x5e>; + interrupt-parent = <&gpio1>; + interrupts = <28 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + #gpio-cells = <2>; + + regulators { + buck1 { + regulator-name = "vcc1"; + regulator-min-microvolt = <1600000>; + regulator-max-microvolt = <1600000>; + regulator-boot-on; + ti,regulator-decay; + ti,regulator-step-size-25mv; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mfd/tps65086.txt b/Documentation/devicetree/bindings/mfd/tps65086.txt deleted file mode 100644 index 67eac0ed32df..000000000000 --- a/Documentation/devicetree/bindings/mfd/tps65086.txt +++ /dev/null @@ -1,54 +0,0 @@ -* TPS65086 Power Management Integrated Circuit (PMIC) bindings - -Required properties: - - compatible : Should be "ti,tps65086". - - reg : I2C slave address. - - interrupts : The interrupt line the device is connected to. - - interrupt-controller : Marks the device node as an interrupt controller. - - #interrupt-cells : The number of cells to describe an IRQ, should be 2. - The first cell is the IRQ number. - The second cell is the flags, encoded as trigger - masks from ../interrupt-controller/interrupts.txt. - - gpio-controller : Marks the device node as a GPIO Controller. - - #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify flags. - See ../gpio/gpio.txt for more information. - - regulators: : List of child nodes that specify the regulator - initialization data. Child nodes must be named - after their hardware counterparts: buck[1-6], - ldoa[1-3], swa1, swb[1-2], and vtt. Each child - node is defined using the standard binding for - regulators and the optional regulator properties - defined below. - -Optional regulator properties: - - ti,regulator-step-size-25mv : This is applicable for buck[1-6], set this - if the regulator is factory set with a 25mv - step voltage mapping. - - ti,regulator-decay : This is applicable for buck[1-6], set this if - the output needs to decay, default is for - the output to slew down. - -Example: - - pmic: tps65086@5e { - compatible = "ti,tps65086"; - reg = <0x5e>; - interrupt-parent = <&gpio1>; - interrupts = <28 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <2>; - gpio-controller; - #gpio-cells = <2>; - - regulators { - buck1 { - regulator-name = "vcc1"; - regulator-min-microvolt = <1600000>; - regulator-max-microvolt = <1600000>; - regulator-boot-on; - ti,regulator-decay; - ti,regulator-step-size-25mv; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt deleted file mode 100644 index 72ea0af368d4..000000000000 --- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt +++ /dev/null @@ -1,29 +0,0 @@ -EEPROMs (SPI) compatible with Microchip Technology 93xx46 family. - -Required properties: -- compatible : shall be one of: - "atmel,at93c46" - "atmel,at93c46d" - "atmel,at93c56" - "atmel,at93c66" - "eeprom-93xx46" - "microchip,93lc46b" -- data-size : number of data bits per word (either 8 or 16) - -Optional properties: -- read-only : parameter-less property which disables writes to the EEPROM -- select-gpios : if present, specifies the GPIO that will be asserted prior to - each access to the EEPROM (e.g. for SPI bus multiplexing) - -Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt -apply. In particular, "reg" and "spi-max-frequency" properties must be given. - -Example: - eeprom@0 { - compatible = "eeprom-93xx46"; - reg = <0>; - spi-max-frequency = <1000000>; - spi-cs-high; - data-size = <8>; - select-gpios = <&gpio4 4 GPIO_ACTIVE_HIGH>; - }; diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.yaml b/Documentation/devicetree/bindings/misc/eeprom-93xx46.yaml new file mode 100644 index 000000000000..44fd2f6f0d8a --- /dev/null +++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/eeprom-93xx46.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip 93xx46 SPI compatible EEPROM family dt bindings + +maintainers: + - Cory Tusar <cory.tusar@pid1solutions.com> + +properties: + compatible: + enum: + - atmel,at93c46 + - atmel,at93c46d + - atmel,at93c56 + - atmel,at93c66 + - eeprom-93xx46 + - microchip,93lc46b + + data-size: + description: number of data bits per word + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16] + + reg: + description: chip select of EEPROM + maxItems: 1 + + spi-max-frequency: true + spi-cs-high: true + + read-only: + description: + parameter-less property which disables writes to the EEPROM + type: boolean + + select-gpios: + description: + specifies the GPIO that needs to be asserted prior to each access + of EEPROM (e.g. for SPI bus multiplexing) + maxItems: 1 + + +required: + - compatible + - reg + - data-size + - spi-max-frequency + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + eeprom@0 { + compatible = "eeprom-93xx46"; + reg = <0>; + spi-max-frequency = <1000000>; + spi-cs-high; + data-size = <8>; + select-gpios = <&gpio4 4 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/misc/ge-achc.txt b/Documentation/devicetree/bindings/misc/ge-achc.txt deleted file mode 100644 index 77df94d7a32f..000000000000 --- a/Documentation/devicetree/bindings/misc/ge-achc.txt +++ /dev/null @@ -1,26 +0,0 @@ -* GE Healthcare USB Management Controller - -A device which handles data aquisition from compatible USB based peripherals. -SPI is used for device management. - -Note: This device does not expose the peripherals as USB devices. - -Required properties: - -- compatible : Should be "ge,achc" - -Required SPI properties: - -- reg : Should be address of the device chip select within - the controller. - -- spi-max-frequency : Maximum SPI clocking speed of device in Hz, should be - 1MHz for the GE ACHC. - -Example: - -spidev0: spi@0 { - compatible = "ge,achc"; - reg = <0>; - spi-max-frequency = <1000000>; -}; diff --git a/Documentation/devicetree/bindings/misc/ge-achc.yaml b/Documentation/devicetree/bindings/misc/ge-achc.yaml new file mode 100644 index 000000000000..ff07aa62ed57 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/ge-achc.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +# Copyright (C) 2021 GE Inc. +# Copyright (C) 2021 Collabora Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/ge-achc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GE Healthcare USB Management Controller + +description: | + A device which handles data acquisition from compatible USB based peripherals. + SPI is used for device management. + + Note: This device does not expose the peripherals as USB devices. + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +properties: + compatible: + items: + - const: ge,achc + - const: nxp,kinetis-k20 + + clocks: + maxItems: 1 + + vdd-supply: + description: Digital power supply regulator on VDD pin + + vdda-supply: + description: Analog power supply regulator on VDDA pin + + reg: + items: + - description: Control interface + - description: Firmware programming interface + + reset-gpios: + description: GPIO used for hardware reset. + maxItems: 1 + +required: + - compatible + - clocks + - reg + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + spi@1 { + compatible = "ge,achc", "nxp,kinetis-k20"; + reg = <1>, <0>; + clocks = <&achc_24M>; + reset-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index b5baf439fbac..a3412f221104 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -29,6 +29,7 @@ properties: - fsl,imx53-esdhc - fsl,imx6q-usdhc - fsl,imx6sl-usdhc + - fsl,imx6sll-usdhc - fsl,imx6sx-usdhc - fsl,imx6ull-usdhc - fsl,imx7d-usdhc @@ -115,12 +116,17 @@ properties: - const: per pinctrl-names: - minItems: 1 - items: - - const: default - - const: state_100mhz - - const: state_200mhz - - const: sleep + oneOf: + - minItems: 3 + items: + - const: default + - const: state_100mhz + - const: state_200mhz + - const: sleep + - minItems: 1 + items: + - const: default + - const: sleep required: - compatible diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml index e0169a285aa2..9e2396751030 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: mmc-pwrseq-sd8787 + enum: + - mmc-pwrseq-sd8787 + - mmc-pwrseq-wilc1000 powerdown-gpios: minItems: 1 diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index 677989bc5924..9f1e7092cf44 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -9,9 +9,6 @@ title: Renesas SDHI SD/MMC controller maintainers: - Wolfram Sang <wsa+renesas@sang-engineering.com> -allOf: - - $ref: "mmc-controller.yaml" - properties: compatible: oneOf: @@ -47,19 +44,20 @@ properties: - const: renesas,sdhi-mmc-r8a77470 # RZ/G1C (SDHI/MMC IP) - items: - enum: - - renesas,sdhi-r8a774a1 # RZ/G2M - - renesas,sdhi-r8a774b1 # RZ/G2N - - renesas,sdhi-r8a774c0 # RZ/G2E - - renesas,sdhi-r8a774e1 # RZ/G2H - - renesas,sdhi-r8a7795 # R-Car H3 - - renesas,sdhi-r8a7796 # R-Car M3-W - - renesas,sdhi-r8a77961 # R-Car M3-W+ - - renesas,sdhi-r8a77965 # R-Car M3-N - - renesas,sdhi-r8a77970 # R-Car V3M - - renesas,sdhi-r8a77980 # R-Car V3H - - renesas,sdhi-r8a77990 # R-Car E3 - - renesas,sdhi-r8a77995 # R-Car D3 - - renesas,sdhi-r8a779a0 # R-Car V3U + - renesas,sdhi-r8a774a1 # RZ/G2M + - renesas,sdhi-r8a774b1 # RZ/G2N + - renesas,sdhi-r8a774c0 # RZ/G2E + - renesas,sdhi-r8a774e1 # RZ/G2H + - renesas,sdhi-r8a7795 # R-Car H3 + - renesas,sdhi-r8a7796 # R-Car M3-W + - renesas,sdhi-r8a77961 # R-Car M3-W+ + - renesas,sdhi-r8a77965 # R-Car M3-N + - renesas,sdhi-r8a77970 # R-Car V3M + - renesas,sdhi-r8a77980 # R-Car V3H + - renesas,sdhi-r8a77990 # R-Car E3 + - renesas,sdhi-r8a77995 # R-Car D3 + - renesas,sdhi-r8a779a0 # R-Car V3U + - renesas,sdhi-r9a07g044 # RZ/G2{L,LC} - const: renesas,rcar-gen3-sdhi # R-Car Gen3 or RZ/G2 reg: @@ -69,15 +67,9 @@ properties: minItems: 1 maxItems: 3 - clocks: - minItems: 1 - maxItems: 2 + clocks: true - clock-names: - minItems: 1 - items: - - const: core - - const: cd + clock-names: true dmas: minItems: 4 @@ -104,14 +96,82 @@ properties: pinctrl-1: maxItems: 1 - pinctrl-names: - minItems: 1 - items: - - const: default - - const: state_uhs + pinctrl-names: true max-frequency: true +allOf: + - $ref: "mmc-controller.yaml" + + - if: + properties: + compatible: + contains: + const: renesas,sdhi-r9a07g044 + then: + properties: + clocks: + items: + - description: IMCLK, SDHI channel main clock1. + - description: IMCLK2, SDHI channel main clock2. When this clock is + turned off, external SD card detection cannot be + detected. + - description: CLK_HS, SDHI channel High speed clock which operates + 4 times that of SDHI channel main clock1. + - description: ACLK, SDHI channel bus clock. + clock-names: + items: + - const: imclk + - const: imclk2 + - const: clk_hs + - const: aclk + required: + - clock-names + - resets + else: + properties: + clocks: + minItems: 1 + maxItems: 2 + clock-names: + minItems: 1 + items: + - const: core + - const: cd + + - if: + properties: + compatible: + contains: + const: renesas,sdhi-mmc-r8a77470 + then: + properties: + pinctrl-names: + items: + - const: state_uhs + else: + properties: + pinctrl-names: + minItems: 1 + items: + - const: default + - const: state_uhs + + - if: + properties: + compatible: + contains: + enum: + - renesas,sdhi-r7s72100 + - renesas,sdhi-r7s9210 + then: + required: + - clock-names + description: + The internal card detection logic that exists in these controllers is + sectioned off to be run by a separate second clock source to allow + the main core clock to be turned off to save power. + required: - compatible - reg @@ -119,21 +179,6 @@ required: - clocks - power-domains -if: - properties: - compatible: - contains: - enum: - - renesas,sdhi-r7s72100 - - renesas,sdhi-r7s9210 -then: - required: - - clock-names - description: - The internal card detection logic that exists in these controllers is - sectioned off to be run by a separate second clock source to allow - the main core clock to be turned off to save power. - unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 4c7fa6a4ed15..365c3fc122ea 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -19,6 +19,7 @@ Required properties: "qcom,msm8996-sdhci", "qcom,sdhci-msm-v4" "qcom,qcs404-sdhci", "qcom,sdhci-msm-v5" "qcom,sc7180-sdhci", "qcom,sdhci-msm-v5"; + "qcom,sc7280-sdhci", "qcom,sdhci-msm-v5"; "qcom,sdm845-sdhci", "qcom,sdhci-msm-v5" "qcom,sdx55-sdhci", "qcom,sdhci-msm-v5"; "qcom,sm8250-sdhci", "qcom,sdhci-msm-v5" diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml index e5f1a33332a5..dd5a64969e37 100644 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml @@ -84,7 +84,6 @@ properties: interrupts: minItems: 1 - maxItems: 3 items: - description: NAND CTLRDY interrupt - description: FLASH_DMA_DONE if flash DMA is available @@ -92,7 +91,6 @@ properties: interrupt-names: minItems: 1 - maxItems: 3 items: - const: nand_ctlrdy - const: flash_dma_done @@ -148,8 +146,6 @@ allOf: then: properties: reg-names: - minItems: 2 - maxItems: 2 items: - const: nand - const: nand-int-base @@ -161,8 +157,6 @@ allOf: then: properties: reg-names: - minItems: 3 - maxItems: 3 items: - const: nand - const: nand-int-base @@ -175,8 +169,6 @@ allOf: then: properties: reg-names: - minItems: 3 - maxItems: 3 items: - const: nand - const: iproc-idm diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index 44919d48d241..c459f169a904 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -122,7 +122,7 @@ on various other factors also like; so the device should have enough free bytes available its OOB/Spare area to accommodate ECC for entire page. In general following expression helps in determining if given device can accommodate ECC syndrome: - "2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE" + "2 + (PAGESIZE / 512) * ECC_BYTES" <= OOBSIZE" where OOBSIZE number of bytes in OOB/spare area PAGESIZE number of bytes in main-area of device page diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt index c8567b40fe13..2133be0d52f2 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt @@ -10,7 +10,7 @@ Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt Required properties: - bank-width: Width of NOR flash in bytes. GPMC supports 8-bit and 16-bit devices and so must be either 1 or 2 bytes. -- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.txt +- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.yaml - gpmc,cs-on-ns: Chip-select assertion time - gpmc,cs-rd-off-ns: Chip-select de-assertion time for reads - gpmc,cs-wr-off-ns: Chip-select de-assertion time for writes @@ -21,7 +21,7 @@ Required properties: - gpmc,access-ns: Start cycle to first data capture (read access) - gpmc,rd-cycle-ns: Total read cycle time - gpmc,wr-cycle-ns: Total write cycle time -- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.txt +- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.yaml - reg: Chip-select, base address (relative to chip-select) and size of NOR flash. Note that base address will be typically 0 as this is the start of the chip-select. diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml index 13c29cc91b59..f827984936f6 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -23,6 +23,7 @@ properties: - amd,s29gl256n - amd,s29gl512n - arm,versatile-flash + - arm,vexpress-flash - cortina,gemini-flash - cypress,hyperflash - ge,imp3a-firmware-mirror diff --git a/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.txt b/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.txt deleted file mode 100644 index fd0ebe4e3415..000000000000 --- a/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.txt +++ /dev/null @@ -1,27 +0,0 @@ -RedBoot FLASH Image System (FIS) Partitions -=========================================== - -The FLASH Image System (FIS) directory is a flash description -format closely associated with the RedBoot boot loader. - -It uses one single flash eraseblock in the flash to store an index of -all images in the flash. - -This block size will vary depending on flash but is typically -32 KB in size. - -Required properties: -- compatible : (required) must be "redboot-fis" -- fis-index-block : (required) a index to the eraseblock containing - the FIS directory on this device. On a flash memory with 32KB - eraseblocks, 0 means the first eraseblock at 0x00000000, 1 means the - second eraseblock at 0x00008000 and so on. - -Example: - -flash@0 { - partitions { - compatible = "redboot-fis"; - fis-index-block = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml b/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml new file mode 100644 index 000000000000..fee8d81b5276 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/redboot-fis.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/redboot-fis.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RedBoot FLASH Image System (FIS) Partitions + +description: The FLASH Image System (FIS) directory is a flash description + format closely associated with the RedBoot boot loader. + It uses one single flash eraseblock in the flash to store an index of + all images in the flash. + This block size will vary depending on flash but is typically + 32 KB in size. + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +properties: + compatible: + const: redboot-fis + + fis-index-block: + $ref: /schemas/types.yaml#/definitions/uint32 + description: a index to the eraseblock containing the FIS directory on this + device. On a flash memory with 32KB eraseblocks, 0 means the first + eraseblock at 0x00000000, 1 means the second eraseblock at 0x00008000 and so on. + +required: + - compatible + - fis-index-block + +additionalProperties: false + +examples: + - | + flash { + partitions { + compatible = "redboot-fis"; + fis-index-block = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.txt b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.txt deleted file mode 100644 index e15589f47787..000000000000 --- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.txt +++ /dev/null @@ -1,43 +0,0 @@ -* Broadcom UniMAC MDIO bus controller - -Required properties: -- compatible: should one from "brcm,genet-mdio-v1", "brcm,genet-mdio-v2", - "brcm,genet-mdio-v3", "brcm,genet-mdio-v4", "brcm,genet-mdio-v5" or - "brcm,unimac-mdio" -- reg: address and length of the register set for the device, first one is the - base register, and the second one is optional and for indirect accesses to - larger than 16-bits MDIO transactions -- reg-names: name(s) of the register must be "mdio" and optional "mdio_indir_rw" -- #size-cells: must be 1 -- #address-cells: must be 0 - -Optional properties: -- interrupts: must be one if the interrupt is shared with the Ethernet MAC or - Ethernet switch this MDIO block is integrated from, or must be two, if there - are two separate interrupts, first one must be "mdio done" and second must be - for "mdio error" -- interrupt-names: must be "mdio_done_error" when there is a share interrupt fed - to this hardware block, or must be "mdio_done" for the first interrupt and - "mdio_error" for the second when there are separate interrupts -- clocks: A reference to the clock supplying the MDIO bus controller -- clock-frequency: the MDIO bus clock that must be output by the MDIO bus - hardware, if absent, the default hardware values are used - -Child nodes of this MDIO bus controller node are standard Ethernet PHY device -nodes as described in Documentation/devicetree/bindings/net/phy.txt - -Example: - -mdio@403c0 { - compatible = "brcm,unimac-mdio"; - reg = <0x403c0 0x8 0x40300 0x18>; - reg-names = "mdio", "mdio_indir_rw"; - #size-cells = <1>; - #address-cells = <0>; - - ... - phy@0 { - compatible = "ethernet-phy-ieee802.3-c22"; - reg = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml new file mode 100644 index 000000000000..f4f4c37f1d4e --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/brcm,unimac-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom UniMAC MDIO bus controller + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +allOf: + - $ref: mdio.yaml# + +properties: + compatible: + enum: + - brcm,genet-mdio-v1 + - brcm,genet-mdio-v2 + - brcm,genet-mdio-v3 + - brcm,genet-mdio-v4 + - brcm,genet-mdio-v5 + - brcm,unimac-mdio + + reg: + minItems: 1 + items: + - description: base register + - description: indirect accesses to larger than 16-bits MDIO transactions + + reg-names: + minItems: 1 + items: + - const: mdio + - const: mdio_indir_rw + + interrupts: + oneOf: + - description: > + Interrupt shared with the Ethernet MAC or Ethernet switch this MDIO + block is integrated from + - items: + - description: | + "mdio done" interrupt + - description: | + "mdio error" interrupt + + interrupt-names: + oneOf: + - const: mdio_done_error + - items: + - const: mdio_done + - const: mdio_error + + clocks: + description: A reference to the clock supplying the MDIO bus controller + + clock-frequency: + description: > + The MDIO bus clock that must be output by the MDIO bus hardware, if + absent, the default hardware values are used + +unevaluatedProperties: false + +required: + - reg + - reg-names + - '#address-cells' + - '#size-cells' + +examples: + - | + mdio@403c0 { + compatible = "brcm,unimac-mdio"; + reg = <0x403c0 0x8>, <0x40300 0x18>; + reg-names = "mdio", "mdio_indir_rw"; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml new file mode 100644 index 000000000000..2cd145a642f1 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml @@ -0,0 +1,119 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/bosch,c_can.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bosch C_CAN/D_CAN controller Device Tree Bindings + +description: Bosch C_CAN/D_CAN controller for CAN bus + +maintainers: + - Dario Binacchi <dariobin@libero.it> + +allOf: + - $ref: can-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - bosch,c_can + - bosch,d_can + - ti,dra7-d_can + - ti,am3352-d_can + - items: + - enum: + - ti,am4372-d_can + - const: ti,am3352-d_can + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 4 + + power-domains: + description: | + Should contain a phandle to a PM domain provider node and an args + specifier containing the DCAN device id value. It's mandatory for + Keystone 2 66AK2G SoCs only. + maxItems: 1 + + clocks: + description: | + CAN functional clock phandle. + maxItems: 1 + + clock-names: + maxItems: 1 + + syscon-raminit: + description: | + Handle to system control region that contains the RAMINIT register, + register offset to the RAMINIT register and the CAN instance number (0 + offset). + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + items: + - description: The phandle to the system control region. + - description: The register offset. + - description: The CAN instance number. + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +if: + properties: + compatible: + contains: + enum: + - bosch,d_can + +then: + properties: + interrupts: + minItems: 4 + maxItems: 4 + items: + - description: Error and status IRQ + - description: Message object IRQ + - description: RAM ECC correctable error IRQ + - description: RAM ECC non-correctable error IRQ + +else: + properties: + interrupts: + maxItems: 1 + items: + - description: Error and status IRQ + +additionalProperties: false + +examples: + - | + #include <dt-bindings/reset/altr,rst-mgr.h> + + can@ffc00000 { + compatible = "bosch,d_can"; + reg = <0xffc00000 0x1000>; + interrupts = <0 131 4>, <0 132 4>, <0 133 4>, <0 134 4>; + clocks = <&can0_clk>; + resets = <&rst CAN0_RESET>; + }; + - | + can@0 { + compatible = "ti,am3352-d_can"; + reg = <0x0 0x2000>; + clocks = <&dcan1_fck>; + clock-names = "fck"; + syscon-raminit = <&scm_conf 0x644 1>; + interrupts = <55>; + }; diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index f84e31348d80..fb547e26c676 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -104,9 +104,18 @@ properties: maximum: 32 maxItems: 1 + power-domains: + description: + Power domain provider node and an args specifier containing + the can device id value. + maxItems: 1 + can-transceiver: $ref: can-transceiver.yaml# + phys: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt deleted file mode 100644 index 366479806acb..000000000000 --- a/Documentation/devicetree/bindings/net/can/c_can.txt +++ /dev/null @@ -1,65 +0,0 @@ -Bosch C_CAN/D_CAN controller Device Tree Bindings -------------------------------------------------- - -Required properties: -- compatible : Should be "bosch,c_can" for C_CAN controllers and - "bosch,d_can" for D_CAN controllers. - Can be "ti,dra7-d_can", "ti,am3352-d_can" or - "ti,am4372-d_can". -- reg : physical base address and size of the C_CAN/D_CAN - registers map -- interrupts : property with a value describing the interrupt - number - -The following are mandatory properties for DRA7x, AM33xx and AM43xx SoCs only: -- ti,hwmods : Must be "d_can<n>" or "c_can<n>", n being the - instance number - -The following are mandatory properties for Keystone 2 66AK2G SoCs only: -- power-domains : Should contain a phandle to a PM domain provider node - and an args specifier containing the DCAN device id - value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml -- clocks : CAN functional clock phandle. This property is as per the - binding, - Documentation/devicetree/bindings/clock/ti,sci-clk.yaml - -Optional properties: -- syscon-raminit : Handle to system control region that contains the - RAMINIT register, register offset to the RAMINIT - register and the CAN instance number (0 offset). - -Note: "ti,hwmods" field is used to fetch the base address and irq -resources from TI, omap hwmod data base during device registration. -Future plan is to migrate hwmod data base contents into device tree -blob so that, all the required data will be used from device tree dts -file. - -Example: - -Step1: SoC common .dtsi file - - dcan1: d_can@481d0000 { - compatible = "bosch,d_can"; - reg = <0x481d0000 0x2000>; - interrupts = <55>; - interrupt-parent = <&intc>; - status = "disabled"; - }; - -(or) - - dcan1: d_can@481d0000 { - compatible = "bosch,d_can"; - ti,hwmods = "d_can1"; - reg = <0x481d0000 0x2000>; - interrupts = <55>; - interrupt-parent = <&intc>; - status = "disabled"; - }; - -Step 2: board specific .dts file - - &dcan1 { - status = "okay"; - }; diff --git a/Documentation/devicetree/bindings/net/can/can-controller.yaml b/Documentation/devicetree/bindings/net/can/can-controller.yaml index 9cf2ae097156..1f0e98051074 100644 --- a/Documentation/devicetree/bindings/net/can/can-controller.yaml +++ b/Documentation/devicetree/bindings/net/can/can-controller.yaml @@ -13,6 +13,15 @@ properties: $nodename: pattern: "^can(@.*)?$" + termination-gpios: + description: GPIO pin to enable CAN bus termination. + maxItems: 1 + + termination-ohms: + description: The resistance value of the CAN bus termination resistor. + minimum: 1 + maximum: 65535 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml index 55bff1586b6f..3f0ee17c1461 100644 --- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml +++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml @@ -119,6 +119,9 @@ properties: minimum: 0 maximum: 2 + termination-gpios: true + termination-ohms: true + required: - compatible - reg @@ -148,3 +151,17 @@ examples: fsl,stop-mode = <&gpr 0x34 28>; fsl,scu-index = /bits/ 8 <1>; }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + + can@2090000 { + compatible = "fsl,imx6q-flexcan"; + reg = <0x02090000 0x4000>; + interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks 1>, <&clks 2>; + clock-names = "ipg", "per"; + fsl,stop-mode = <&gpr 0x34 28>; + termination-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; + termination-ohms = <120>; + }; diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml index 0b33ba9ccb47..546c6e6d2fb0 100644 --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -30,13 +30,15 @@ properties: - renesas,r8a77995-canfd # R-Car D3 - const: renesas,rcar-gen3-canfd # R-Car Gen3 and RZ/G2 + - items: + - enum: + - renesas,r9a07g044-canfd # RZ/G2{L,LC} + - const: renesas,rzg2l-canfd # RZ/G2L family + reg: maxItems: 1 - interrupts: - items: - - description: Channel interrupt - - description: Global interrupt + interrupts: true clocks: maxItems: 3 @@ -50,8 +52,7 @@ properties: power-domains: maxItems: 1 - resets: - maxItems: 1 + resets: true renesas,no-can-fd: $ref: /schemas/types.yaml#/definitions/flag @@ -91,6 +92,62 @@ required: - channel0 - channel1 +if: + properties: + compatible: + contains: + enum: + - renesas,rzg2l-canfd +then: + properties: + interrupts: + items: + - description: CAN global error interrupt + - description: CAN receive FIFO interrupt + - description: CAN0 error interrupt + - description: CAN0 transmit interrupt + - description: CAN0 transmit/receive FIFO receive completion interrupt + - description: CAN1 error interrupt + - description: CAN1 transmit interrupt + - description: CAN1 transmit/receive FIFO receive completion interrupt + + interrupt-names: + items: + - const: g_err + - const: g_recc + - const: ch0_err + - const: ch0_rec + - const: ch0_trx + - const: ch1_err + - const: ch1_rec + - const: ch1_trx + + resets: + maxItems: 2 + + reset-names: + items: + - const: rstp_n + - const: rstc_n + + required: + - interrupt-names + - reset-names +else: + properties: + interrupts: + items: + - description: Channel interrupt + - description: Global interrupt + + interrupt-names: + items: + - const: ch_int + - const: g_int + + resets: + maxItems: 1 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml index 0b8a05dd52e6..f978f8719d8e 100644 --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml @@ -67,8 +67,8 @@ properties: reg: oneOf: - enum: - - 0 - - 1 + - 0 + - 1 required: - compatible diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml new file mode 100644 index 000000000000..eca41443fcce --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -0,0 +1,244 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,fec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Fast Ethernet Controller (FEC) + +maintainers: + - Joakim Zhang <qiangqing.zhang@nxp.com> + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - fsl,imx25-fec + - fsl,imx27-fec + - fsl,imx28-fec + - fsl,imx6q-fec + - fsl,mvf600-fec + - items: + - enum: + - fsl,imx53-fec + - fsl,imx6sl-fec + - const: fsl,imx25-fec + - items: + - enum: + - fsl,imx35-fec + - fsl,imx51-fec + - const: fsl,imx27-fec + - items: + - enum: + - fsl,imx6ul-fec + - fsl,imx6sx-fec + - const: fsl,imx6q-fec + - items: + - enum: + - fsl,imx7d-fec + - const: fsl,imx6sx-fec + - items: + - const: fsl,imx8mq-fec + - const: fsl,imx6sx-fec + - items: + - enum: + - fsl,imx8mm-fec + - fsl,imx8mn-fec + - fsl,imx8mp-fec + - const: fsl,imx8mq-fec + - const: fsl,imx6sx-fec + - items: + - const: fsl,imx8qm-fec + - const: fsl,imx6sx-fec + - items: + - enum: + - fsl,imx8qxp-fec + - const: fsl,imx8qm-fec + - const: fsl,imx6sx-fec + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 4 + + interrupt-names: + oneOf: + - items: + - const: int0 + - items: + - const: int0 + - const: pps + - items: + - const: int0 + - const: int1 + - const: int2 + - items: + - const: int0 + - const: int1 + - const: int2 + - const: pps + + clocks: + minItems: 2 + maxItems: 5 + description: + The "ipg", for MAC ipg_clk_s, ipg_clk_mac_s that are for register accessing. + The "ahb", for MAC ipg_clk, ipg_clk_mac that are bus clock. + The "ptp"(option), for IEEE1588 timer clock that requires the clock. + The "enet_clk_ref"(option), for MAC transmit/receiver reference clock like + RGMII TXC clock or RMII reference clock. It depends on board design, + the clock is required if RGMII TXC and RMII reference clock source from + SOC internal PLL. + The "enet_out"(option), output clock for external device, like supply clock + for PHY. The clock is required if PHY clock source from SOC. + The "enet_2x_txclk"(option), for RGMII sampling clock which fixed at 250Mhz. + The clock is required if SoC RGMII enable clock delay. + + clock-names: + minItems: 2 + maxItems: 5 + items: + enum: + - ipg + - ahb + - ptp + - enet_clk_ref + - enet_out + - enet_2x_txclk + + phy-mode: true + + phy-handle: true + + fixed-link: true + + local-mac-address: true + + mac-address: true + + tx-internal-delay-ps: + enum: [0, 2000] + + rx-internal-delay-ps: + enum: [0, 2000] + + phy-supply: + description: + Regulator that powers the Ethernet PHY. + + fsl,num-tx-queues: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The property is valid for enet-avb IP, which supports hw multi queues. + Should specify the tx queue number, otherwise set tx queue number to 1. + enum: [1, 2, 3] + + fsl,num-rx-queues: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The property is valid for enet-avb IP, which supports hw multi queues. + Should specify the rx queue number, otherwise set rx queue number to 1. + enum: [1, 2, 3] + + fsl,magic-packet: + $ref: /schemas/types.yaml#/definitions/flag + description: + If present, indicates that the hardware supports waking up via magic packet. + + fsl,err006687-workaround-present: + $ref: /schemas/types.yaml#/definitions/flag + description: + If present indicates that the system has the hardware workaround for + ERR006687 applied and does not need a software workaround. + + fsl,stop-mode: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Register bits of stop mode control, the format is <&gpr req_gpr req_bit>. + gpr is the phandle to general purpose register node. + req_gpr is the gpr register offset for ENET stop request. + req_bit is the gpr bit offset for ENET stop request. + + mdio: + type: object + description: + Specifies the mdio bus in the FEC, used as a container for phy nodes. + + # Deprecated optional properties: + # To avoid these, create a phy node according to ethernet-phy.yaml in the same + # directory, and point the FEC's "phy-handle" property to it. Then use + # the phy's reset binding, again described by ethernet-phy.yaml. + + phy-reset-gpios: + deprecated: true + description: + Should specify the gpio for phy reset. + + phy-reset-duration: + deprecated: true + description: + Reset duration in milliseconds. Should present only if property + "phy-reset-gpios" is available. Missing the property will have the + duration be 1 millisecond. Numbers greater than 1000 are invalid + and 1 millisecond will be used instead. + + phy-reset-active-high: + deprecated: true + description: + If present then the reset sequence using the GPIO specified in the + "phy-reset-gpios" property is reversed (H=reset state, L=operation state). + + phy-reset-post-delay: + deprecated: true + description: + Post reset delay in milliseconds. If present then a delay of phy-reset-post-delay + milliseconds will be observed after the phy-reset-gpios has been toggled. + Can be omitted thus no delay is observed. Delay is in range of 1ms to 1000ms. + Other delays are invalid. + +required: + - compatible + - reg + - interrupts + +# FIXME: We had better set additionalProperties to false to avoid invalid or at +# least undocumented properties. However, PHY may have a deprecated option to +# place PHY OF properties in the MAC node, such as Micrel PHY, and we can find +# these boards which is based on i.MX6QDL. +additionalProperties: false + +examples: + - | + ethernet@83fec000 { + compatible = "fsl,imx51-fec", "fsl,imx27-fec"; + reg = <0x83fec000 0x4000>; + interrupts = <87>; + phy-mode = "mii"; + phy-reset-gpios = <&gpio2 14 0>; + phy-supply = <®_fec_supply>; + }; + + ethernet@83fed000 { + compatible = "fsl,imx51-fec", "fsl,imx27-fec"; + reg = <0x83fed000 0x4000>; + interrupts = <87>; + phy-mode = "mii"; + phy-reset-gpios = <&gpio2 14 0>; + phy-supply = <®_fec_supply>; + phy-handle = <ðphy0>; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt deleted file mode 100644 index 9b543789cd52..000000000000 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt +++ /dev/null @@ -1,95 +0,0 @@ -* Freescale Fast Ethernet Controller (FEC) - -Required properties: -- compatible : Should be "fsl,<soc>-fec" -- reg : Address and length of the register set for the device -- interrupts : Should contain fec interrupt -- phy-mode : See ethernet.txt file in the same directory - -Optional properties: -- phy-supply : regulator that powers the Ethernet PHY. -- phy-handle : phandle to the PHY device connected to this device. -- fixed-link : Assume a fixed link. See fixed-link.txt in the same directory. - Use instead of phy-handle. -- fsl,num-tx-queues : The property is valid for enet-avb IP, which supports - hw multi queues. Should specify the tx queue number, otherwise set tx queue - number to 1. -- fsl,num-rx-queues : The property is valid for enet-avb IP, which supports - hw multi queues. Should specify the rx queue number, otherwise set rx queue - number to 1. -- fsl,magic-packet : If present, indicates that the hardware supports waking - up via magic packet. -- fsl,err006687-workaround-present: If present indicates that the system has - the hardware workaround for ERR006687 applied and does not need a software - workaround. -- fsl,stop-mode: register bits of stop mode control, the format is - <&gpr req_gpr req_bit>. - gpr is the phandle to general purpose register node. - req_gpr is the gpr register offset for ENET stop request. - req_bit is the gpr bit offset for ENET stop request. - -interrupt-names: names of the interrupts listed in interrupts property in - the same order. The defaults if not specified are - __Number of interrupts__ __Default__ - 1 "int0" - 2 "int0", "pps" - 3 "int0", "int1", "int2" - 4 "int0", "int1", "int2", "pps" - The order may be changed as long as they correspond to the interrupts - property. Currently, only i.mx7 uses "int1" and "int2". They correspond to - tx/rx queues 1 and 2. "int0" will be used for queue 0 and ENET_MII interrupts. - For imx6sx, "int0" handles all 3 queues and ENET_MII. "pps" is for the pulse - per second interrupt associated with 1588 precision time protocol(PTP). - -Optional subnodes: -- mdio : specifies the mdio bus in the FEC, used as a container for phy nodes - according to phy.txt in the same directory - -Deprecated optional properties: - To avoid these, create a phy node according to phy.txt in the same - directory, and point the fec's "phy-handle" property to it. Then use - the phy's reset binding, again described by phy.txt. -- phy-reset-gpios : Should specify the gpio for phy reset -- phy-reset-duration : Reset duration in milliseconds. Should present - only if property "phy-reset-gpios" is available. Missing the property - will have the duration be 1 millisecond. Numbers greater than 1000 are - invalid and 1 millisecond will be used instead. -- phy-reset-active-high : If present then the reset sequence using the GPIO - specified in the "phy-reset-gpios" property is reversed (H=reset state, - L=operation state). -- phy-reset-post-delay : Post reset delay in milliseconds. If present then - a delay of phy-reset-post-delay milliseconds will be observed after the - phy-reset-gpios has been toggled. Can be omitted thus no delay is - observed. Delay is in range of 1ms to 1000ms. Other delays are invalid. - -Example: - -ethernet@83fec000 { - compatible = "fsl,imx51-fec", "fsl,imx27-fec"; - reg = <0x83fec000 0x4000>; - interrupts = <87>; - phy-mode = "mii"; - phy-reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>; /* GPIO2_14 */ - local-mac-address = [00 04 9F 01 1B B9]; - phy-supply = <®_fec_supply>; -}; - -Example with phy specified: - -ethernet@83fec000 { - compatible = "fsl,imx51-fec", "fsl,imx27-fec"; - reg = <0x83fec000 0x4000>; - interrupts = <87>; - phy-mode = "mii"; - phy-reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>; /* GPIO2_14 */ - local-mac-address = [00 04 9F 01 1B B9]; - phy-supply = <®_fec_supply>; - phy-handle = <ðphy>; - mdio { - clock-frequency = <5000000>; - ethphy: ethernet-phy@6 { - compatible = "ethernet-phy-ieee802.3-c22"; - reg = <6>; - max-speed = <100>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt b/Documentation/devicetree/bindings/net/gpmc-eth.txt index f7da3d73ca1b..32821066a85b 100644 --- a/Documentation/devicetree/bindings/net/gpmc-eth.txt +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt @@ -13,7 +13,7 @@ Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt For the properties relevant to the ethernet controller connected to the GPMC refer to the binding documentation of the device. For example, the documentation -for the SMSC 911x is Documentation/devicetree/bindings/net/smsc911x.txt +for the SMSC 911x is Documentation/devicetree/bindings/net/smsc,lan9115.yaml Child nodes need to specify the GPMC bus address width using the "bank-width" property but is possible that an ethernet controller also has a property to diff --git a/Documentation/devicetree/bindings/net/imx-dwmac.txt b/Documentation/devicetree/bindings/net/imx-dwmac.txt deleted file mode 100644 index 921d522fe8d7..000000000000 --- a/Documentation/devicetree/bindings/net/imx-dwmac.txt +++ /dev/null @@ -1,56 +0,0 @@ -IMX8 glue layer controller, NXP imx8 families support Synopsys MAC 5.10a IP. - -This file documents platform glue layer for IMX. -Please see stmmac.txt for the other unchanged properties. - -The device node has following properties. - -Required properties: -- compatible: Should be "nxp,imx8mp-dwmac-eqos" to select glue layer - and "snps,dwmac-5.10a" to select IP version. -- clocks: Must contain a phandle for each entry in clock-names. -- clock-names: Should be "stmmaceth" for the host clock. - Should be "pclk" for the MAC apb clock. - Should be "ptp_ref" for the MAC timer clock. - Should be "tx" for the MAC RGMII TX clock: - Should be "mem" for EQOS MEM clock. - - "mem" clock is required for imx8dxl platform. - - "mem" clock is not required for imx8mp platform. -- interrupt-names: Should contain a list of interrupt names corresponding to - the interrupts in the interrupts property, if available. - Should be "macirq" for the main MAC IRQ - Should be "eth_wake_irq" for the IT which wake up system -- intf_mode: Should be phandle/offset pair. The phandle to the syscon node which - encompases the GPR register, and the offset of the GPR register. - - required for imx8mp platform. - - is optional for imx8dxl platform. - -Optional properties: -- intf_mode: is optional for imx8dxl platform. -- snps,rmii_refclk_ext: to select RMII reference clock from external. - -Example: - eqos: ethernet@30bf0000 { - compatible = "nxp,imx8mp-dwmac-eqos", "snps,dwmac-5.10a"; - reg = <0x30bf0000 0x10000>; - interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "eth_wake_irq", "macirq"; - clocks = <&clk IMX8MP_CLK_ENET_QOS_ROOT>, - <&clk IMX8MP_CLK_QOS_ENET_ROOT>, - <&clk IMX8MP_CLK_ENET_QOS_TIMER>, - <&clk IMX8MP_CLK_ENET_QOS>; - clock-names = "stmmaceth", "pclk", "ptp_ref", "tx"; - assigned-clocks = <&clk IMX8MP_CLK_ENET_AXI>, - <&clk IMX8MP_CLK_ENET_QOS_TIMER>, - <&clk IMX8MP_CLK_ENET_QOS>; - assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_266M>, - <&clk IMX8MP_SYS_PLL2_100M>, - <&clk IMX8MP_SYS_PLL2_125M>; - assigned-clock-rates = <0>, <100000000>, <125000000>; - nvmem-cells = <ð_mac0>; - nvmem-cell-names = "mac-address"; - nvmem_macaddr_swap; - intf_mode = <&gpr 0x4>; - status = "disabled"; - }; diff --git a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml index c1948ce00081..08a3f1f6aea2 100644 --- a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml +++ b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml @@ -116,7 +116,6 @@ examples: snps,mtl-rx-config = <&mtl_rx_setup>; snps,mtl-tx-config = <&mtl_tx_setup>; snps,tso; - status = "okay"; mdio0 { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml b/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml new file mode 100644 index 000000000000..8b9b3f915d92 --- /dev/null +++ b/Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# 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#" + +title: Intel IXP46x PTP Timer (TSYNC) + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + The Intel IXP46x PTP timer is known in the manual as IEEE1588 Hardware + Assist and Time Synchronization Hardware Assist TSYNC provides a PTP + timer. It exists in the Intel IXP45x and IXP46x XScale SoCs. + +properties: + compatible: + const: intel,ixp46x-ptp-timer + + reg: + maxItems: 1 + + interrupts: + items: + - description: Interrupt to trigger master mode snapshot from the + PRP timer, usually a GPIO interrupt. + - description: Interrupt to trigger slave mode snapshot from the + PRP timer, usually a GPIO interrupt. + + interrupt-names: + items: + - const: master + - const: slave + +required: + - compatible + - reg + - interrupts + - interrupt-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + ptp-timer@c8010000 { + compatible = "intel,ixp46x-ptp-timer"; + reg = <0xc8010000 0x1000>; + interrupt-parent = <&gpio0>; + interrupts = <8 IRQ_TYPE_EDGE_FALLING>, <7 IRQ_TYPE_EDGE_FALLING>; + interrupt-names = "master", "slave"; + }; diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml index f2e91d1bf7d7..378ed2d3b003 100644 --- a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml +++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml @@ -71,7 +71,6 @@ examples: ethernet@c8009000 { compatible = "intel,ixp4xx-ethernet"; reg = <0xc8009000 0x1000>; - status = "disabled"; queue-rx = <&qmgr 4>; queue-txready = <&qmgr 21>; intel,npe-handle = <&npe 1>; @@ -82,7 +81,6 @@ examples: ethernet@c800c000 { compatible = "intel,ixp4xx-ethernet"; reg = <0xc800c000 0x1000>; - status = "disabled"; queue-rx = <&qmgr 3>; queue-txready = <&qmgr 20>; intel,npe-handle = <&npe 2>; diff --git a/Documentation/devicetree/bindings/net/litex,liteeth.yaml b/Documentation/devicetree/bindings/net/litex,liteeth.yaml new file mode 100644 index 000000000000..76c164a8199a --- /dev/null +++ b/Documentation/devicetree/bindings/net/litex,liteeth.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/litex,liteeth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LiteX LiteETH ethernet device + +maintainers: + - Joel Stanley <joel@jms.id.au> + +description: | + LiteETH is a small footprint and configurable Ethernet core for FPGA based + system on chips. + + The hardware source is Open Source and can be found on at + https://github.com/enjoy-digital/liteeth/. + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + const: litex,liteeth + + reg: + items: + - description: MAC registers + - description: MDIO registers + - description: Packet buffer + + reg-names: + items: + - const: mac + - const: mdio + - const: buffer + + interrupts: + maxItems: 1 + + litex,rx-slots: + description: Number of slots in the receive buffer + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + default: 2 + + litex,tx-slots: + description: Number of slots in the transmit buffer + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + default: 2 + + litex,slot-size: + description: Size in bytes of a slot in the tx/rx buffer + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x800 + default: 0x800 + + mac-address: true + local-mac-address: true + phy-handle: true + + mdio: + $ref: mdio.yaml# + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + mac: ethernet@8020000 { + compatible = "litex,liteeth"; + reg = <0x8021000 0x100>, + <0x8020800 0x100>, + <0x8030000 0x2000>; + reg-names = "mac", "mdio", "buffer"; + litex,rx-slots = <2>; + litex,tx-slots = <2>; + litex,slot-size = <0x800>; + interrupts = <0x11 0x1>; + phy-handle = <ð_phy>; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + eth_phy: ethernet-phy@0 { + reg = <0>; + }; + }; + }; +... + +# vim: set ts=2 sw=2 sts=2 tw=80 et cc=80 ft=yaml : diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index a4d547efc32a..af9df2f01a1c 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -8,6 +8,7 @@ Required properties: Use "cdns,np4-macb" for NP4 SoC devices. Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb". Use "atmel,sama5d2-gem" for the GEM IP (10/100) available on Atmel sama5d2 SoCs. + Use "atmel,sama5d29-gem" for GEM XL IP (10/100) available on Atmel sama5d29 SoCs. Use "atmel,sama5d3-macb" for the 10/100Mbit IP available on Atmel sama5d3 SoCs. Use "atmel,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs. Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4 SoCs. diff --git a/Documentation/devicetree/bindings/net/micrel,ks8851.yaml b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml new file mode 100644 index 000000000000..5aa7cf2eacb1 --- /dev/null +++ b/Documentation/devicetree/bindings/net/micrel,ks8851.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/micrel,ks8851.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Micrel KS8851 Ethernet MAC (SPI and Parallel bus options) + +maintainers: + - Marek Vasut <marex@denx.de> + +properties: + compatible: + enum: + - micrel,ks8851 # SPI bus option + - micrel,ks8851-mll # Parallel bus option + + interrupts: + maxItems: 1 + + reg: + minItems: 1 + items: + - description: SPI or Parallel bus hardware address + - description: Parallel bus command mode address + + reset-gpios: + maxItems: 1 + description: + The reset_n input pin + + vdd-supply: + description: | + Analog 3.3V supply for Ethernet MAC + + vdd-io-supply: + description: | + Digital 1.8V IO supply for Ethernet MAC + +required: + - compatible + - reg + - interrupts + +allOf: + - $ref: ethernet-controller.yaml# + - if: + properties: + compatible: + contains: + const: micrel,ks8851 + then: + properties: + reg: + maxItems: 1 + - if: + properties: + compatible: + contains: + const: micrel,ks8851-mll + then: + properties: + reg: + minItems: 2 + +unevaluatedProperties: false + +examples: + - | + /* SPI bus option */ + spi { + #address-cells = <1>; + #size-cells = <0>; + ethernet@0 { + compatible = "micrel,ks8851"; + reg = <0>; + interrupt-parent = <&msmgpio>; + interrupts = <90 8>; + vdd-supply = <&ext_l2>; + vdd-io-supply = <&pm8921_lvs6>; + reset-gpios = <&msmgpio 89 0>; + }; + }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + /* Parallel bus option */ + memory-controller { + #address-cells = <2>; + #size-cells = <1>; + ethernet@1,0 { + compatible = "micrel,ks8851-mll"; + reg = <1 0x0 0x2>, <1 0x2 0x20000>; + interrupt-parent = <&gpioc>; + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt deleted file mode 100644 index bbdf9a7359a2..000000000000 --- a/Documentation/devicetree/bindings/net/micrel-ks8851.txt +++ /dev/null @@ -1,18 +0,0 @@ -Micrel KS8851 Ethernet mac (MLL) - -Required properties: -- compatible = "micrel,ks8851-mll" of parallel interface -- reg : 2 physical address and size of registers for data and command -- interrupts : interrupt connection - -Micrel KS8851 Ethernet mac (SPI) - -Required properties: -- compatible = "micrel,ks8851" or the deprecated "ks8851" -- reg : chip select number -- interrupts : interrupt connection - -Optional properties: -- vdd-supply: analog 3.3V supply for Ethernet mac -- vdd-io-supply: digital 1.8V IO supply for Ethernet mac -- reset-gpios: reset_n input pin diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt index 87a27d775d48..0a3647fe331b 100644 --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt @@ -67,7 +67,7 @@ Example: compatible = "ethernet-phy-id0007.0570"; vsc8531,vddmac = <3300>; vsc8531,edge-slowdown = <7>; - vsc8531,led-0-mode = <LINK_1000_ACTIVITY>; - vsc8531,led-1-mode = <LINK_100_ACTIVITY>; + vsc8531,led-0-mode = <VSC8531_LINK_1000_ACTIVITY>; + vsc8531,led-1-mode = <VSC8531_LINK_100_ACTIVITY>; load-save-gpios = <&gpio 10 GPIO_ACTIVE_HIGH>; }; diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml index 081742c2b726..64995cbb0f97 100644 --- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml +++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml @@ -90,14 +90,11 @@ examples: # UART example on Raspberry Pi - | uart0 { - status = "okay"; - nfc { compatible = "samsung,s3fwrn82"; en-gpios = <&gpio 20 GPIO_ACTIVE_HIGH>; wake-gpios = <&gpio 16 GPIO_ACTIVE_HIGH>; - status = "okay"; }; }; diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml new file mode 100644 index 000000000000..5629b2e4ccf8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nxp,dwmac-imx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8 DWMAC glue layer Device Tree Bindings + +maintainers: + - Joakim Zhang <qiangqing.zhang@nxp.com> + +# We need a select here so we don't match all nodes with 'snps,dwmac' +select: + properties: + compatible: + contains: + enum: + - nxp,imx8mp-dwmac-eqos + - nxp,imx8dxl-dwmac-eqos + required: + - compatible + +allOf: + - $ref: "snps,dwmac.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - nxp,imx8mp-dwmac-eqos + - nxp,imx8dxl-dwmac-eqos + - const: snps,dwmac-5.10a + + clocks: + minItems: 3 + maxItems: 5 + items: + - description: MAC host clock + - description: MAC apb clock + - description: MAC timer clock + - description: MAC RGMII TX clock + - description: EQOS MEM clock + + clock-names: + minItems: 3 + maxItems: 5 + contains: + enum: + - stmmaceth + - pclk + - ptp_ref + - tx + - mem + + intf_mode: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Should be phandle/offset pair. The phandle to the syscon node which + encompases the GPR register, and the offset of the GPR register. + + snps,rmii_refclk_ext: + $ref: /schemas/types.yaml#/definitions/flag + description: + To select RMII reference clock from external. + +required: + - compatible + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/imx8mp-clock.h> + + eqos: ethernet@30bf0000 { + compatible = "nxp,imx8mp-dwmac-eqos","snps,dwmac-5.10a"; + reg = <0x30bf0000 0x10000>; + interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq", "eth_wake_irq"; + clocks = <&clk IMX8MP_CLK_ENET_QOS_ROOT>, + <&clk IMX8MP_CLK_QOS_ENET_ROOT>, + <&clk IMX8MP_CLK_ENET_QOS_TIMER>, + <&clk IMX8MP_CLK_ENET_QOS>; + clock-names = "stmmaceth", "pclk", "ptp_ref", "tx"; + phy-mode = "rgmii"; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml index f0db22645d73..cf4d35edaa1b 100644 --- a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml +++ b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml @@ -101,8 +101,6 @@ examples: phy-mode = "gmii"; - status = "disabled"; - fixed-link { speed = <1000>; full-duplex; @@ -148,32 +146,24 @@ examples: reg = <0x1>; phy-handle = <&phy_port0>; phy-mode = "internal"; - - status = "disabled"; }; switch_port2: port@2 { reg = <0x2>; phy-handle = <&phy_port1>; phy-mode = "internal"; - - status = "disabled"; }; switch_port3: port@3 { reg = <0x3>; phy-handle = <&phy_port2>; phy-mode = "internal"; - - status = "disabled"; }; switch_port4: port@4 { reg = <0x4>; phy-handle = <&phy_port3>; phy-mode = "internal"; - - status = "disabled"; }; }; @@ -183,34 +173,29 @@ examples: interrupt-parent = <&switch10>; - phy_port0: phy@0 { + phy_port0: ethernet-phy@0 { reg = <0x0>; interrupts = <0>; - status = "disabled"; }; - phy_port1: phy@1 { + phy_port1: ethernet-phy@1 { reg = <0x1>; interrupts = <0>; - status = "disabled"; }; - phy_port2: phy@2 { + phy_port2: ethernet-phy@2 { reg = <0x2>; interrupts = <0>; - status = "disabled"; }; - phy_port3: phy@3 { + phy_port3: ethernet-phy@3 { reg = <0x3>; interrupts = <0>; - status = "disabled"; }; - phy_port4: phy@4 { + phy_port4: ethernet-phy@4 { reg = <0x4>; interrupts = <0>; - status = "disabled"; }; }; }; diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index ed88ba4b94df..b8a0b392b24e 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -87,16 +87,24 @@ properties: - const: ipa-setup-ready interconnects: - items: - - description: Interconnect path between IPA and main memory - - description: Interconnect path between IPA and internal memory - - description: Interconnect path between IPA and the AP subsystem + oneOf: + - items: + - description: Path leading to system memory + - description: Path between the AP and IPA config space + - items: + - description: Path leading to system memory + - description: Path leading to internal memory + - description: Path between the AP and IPA config space interconnect-names: - items: - - const: memory - - const: imem - - const: config + oneOf: + - items: + - const: memory + - const: config + - items: + - const: memory + - const: imem + - const: config qcom,smem-states: $ref: /schemas/types.yaml#/definitions/phandle-array diff --git a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml index 0c973310ada0..2af304341772 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml @@ -14,7 +14,9 @@ allOf: properties: compatible: - const: qcom,ipq4019-mdio + enum: + - qcom,ipq4019-mdio + - qcom,ipq5018-mdio "#address-cells": const: 1 @@ -23,7 +25,18 @@ properties: const: 0 reg: + minItems: 1 + maxItems: 2 + description: + the first Address and length of the register set for the MDIO controller. + the second Address and length of the register for ethernet LDO, this second + address range is only required by the platform IPQ50xx. + + clocks: maxItems: 1 + description: | + MDIO clock source frequency fixed to 100MHZ, this clock should be specified + by the platform IPQ807x, IPQ60xx and IPQ50xx. required: - compatible diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml index 4f485df69ac3..0634e69dd9a6 100644 --- a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml @@ -17,10 +17,10 @@ description: properties: compatible: - oneOf: - - const: "realtek,rtl8723bs-bt" - - const: "realtek,rtl8723cs-bt" - - const: "realtek,rtl8822cs-bt" + enum: + - realtek,rtl8723bs-bt + - realtek,rtl8723cs-bt + - realtek,rtl8822cs-bt device-wake-gpios: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index 005868f703a6..4c927d2c17d3 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -43,23 +43,20 @@ properties: - renesas,etheravb-r8a779a0 # R-Car V3U - const: renesas,etheravb-rcar-gen3 # R-Car Gen3 and RZ/G2 + - items: + - enum: + - renesas,r9a07g044-gbeth # RZ/G2{L,LC} + - const: renesas,rzg2l-gbeth # RZ/G2L + reg: true interrupts: true interrupt-names: true - clocks: - minItems: 1 - items: - - description: AVB functional clock - - description: Optional TXC reference clock + clocks: true - clock-names: - minItems: 1 - items: - - const: fck - - const: refclk + clock-names: true iommus: maxItems: 1 @@ -145,14 +142,20 @@ allOf: properties: compatible: contains: - const: renesas,etheravb-rcar-gen2 + enum: + - renesas,etheravb-rcar-gen2 + - renesas,rzg2l-gbeth then: properties: interrupts: - maxItems: 1 + minItems: 1 + maxItems: 3 interrupt-names: + minItems: 1 items: - const: mux + - const: fil + - const: arp_ns rx-internal-delay-ps: false else: properties: @@ -208,6 +211,36 @@ allOf: tx-internal-delay-ps: const: 2000 + - if: + properties: + compatible: + contains: + const: renesas,rzg2l-gbeth + then: + properties: + clocks: + items: + - description: Main clock + - description: Register access clock + - description: Reference clock for RGMII + clock-names: + items: + - const: axi + - const: chi + - const: refclk + else: + properties: + clocks: + minItems: 1 + items: + - description: AVB functional clock + - description: Optional TXC reference clock + clock-names: + minItems: 1 + items: + - const: fck + - const: refclk + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/smsc,lan9115.yaml b/Documentation/devicetree/bindings/net/smsc,lan9115.yaml new file mode 100644 index 000000000000..f86667cbcca8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/smsc,lan9115.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/smsc,lan9115.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller + +maintainers: + - Shawn Guo <shawnguo@kernel.org> + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + oneOf: + - const: smsc,lan9115 + - items: + - enum: + - smsc,lan89218 + - smsc,lan9117 + - smsc,lan9118 + - smsc,lan9220 + - smsc,lan9221 + - const: smsc,lan9115 + + reg: + maxItems: 1 + + reg-shift: true + + reg-io-width: + enum: [ 2, 4 ] + default: 2 + + interrupts: + minItems: 1 + items: + - description: + LAN interrupt line + - description: + Optional PME (power management event) interrupt that is able to wake + up the host system with a 50ms pulse on network activity + + clocks: + maxItems: 1 + + phy-mode: true + + smsc,irq-active-high: + type: boolean + description: Indicates the IRQ polarity is active-high + + smsc,irq-push-pull: + type: boolean + description: Indicates the IRQ type is push-pull + + smsc,force-internal-phy: + type: boolean + description: Forces SMSC LAN controller to use internal PHY + + smsc,force-external-phy: + type: boolean + description: Forces SMSC LAN controller to use external PHY + + smsc,save-mac-address: + type: boolean + description: + Indicates that MAC address needs to be saved before resetting the + controller + + reset-gpios: + maxItems: 1 + description: + A GPIO line connected to the RESET (active low) signal of the device. + On many systems this is wired high so the device goes out of reset at + power-on, but if it is under program control, this optional GPIO can + wake up in response to it. + + vdd33a-supply: + description: 3.3V analog power supply + + vddvario-supply: + description: IO logic power supply + +required: + - compatible + - reg + - interrupts + +# There are lots of bus-specific properties ("qcom,*", "samsung,*", "fsl,*", +# "gpmc,*", ...) to be found, that actually depend on the compatible value of +# the parent node. +additionalProperties: true + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + ethernet@f4000000 { + compatible = "smsc,lan9220", "smsc,lan9115"; + reg = <0xf4000000 0x2000000>; + phy-mode = "mii"; + interrupt-parent = <&gpio1>; + interrupts = <31>, <32>; + reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>; + reg-io-width = <4>; + smsc,irq-push-pull; + }; diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt deleted file mode 100644 index acfafc8e143c..000000000000 --- a/Documentation/devicetree/bindings/net/smsc911x.txt +++ /dev/null @@ -1,43 +0,0 @@ -* Smart Mixed-Signal Connectivity (SMSC) LAN911x/912x Controller - -Required properties: -- compatible : Should be "smsc,lan<model>", "smsc,lan9115" -- reg : Address and length of the io space for SMSC LAN -- interrupts : one or two interrupt specifiers - - The first interrupt is the SMSC LAN interrupt line - - The second interrupt (if present) is the PME (power - management event) interrupt that is able to wake up the host - system with a 50ms pulse on network activity -- phy-mode : See ethernet.txt file in the same directory - -Optional properties: -- reg-shift : Specify the quantity to shift the register offsets by -- reg-io-width : Specify the size (in bytes) of the IO accesses that - should be performed on the device. Valid value for SMSC LAN is - 2 or 4. If it's omitted or invalid, the size would be 2. -- smsc,irq-active-high : Indicates the IRQ polarity is active-high -- smsc,irq-push-pull : Indicates the IRQ type is push-pull -- smsc,force-internal-phy : Forces SMSC LAN controller to use - internal PHY -- smsc,force-external-phy : Forces SMSC LAN controller to use - external PHY -- smsc,save-mac-address : Indicates that mac address needs to be saved - before resetting the controller -- reset-gpios : a GPIO line connected to the RESET (active low) signal - of the device. On many systems this is wired high so the device goes - out of reset at power-on, but if it is under program control, this - optional GPIO can wake up in response to it. -- vdd33a-supply, vddvario-supply : 3.3V analog and IO logic power supplies - -Examples: - -lan9220@f4000000 { - compatible = "smsc,lan9220", "smsc,lan9115"; - reg = <0xf4000000 0x2000000>; - phy-mode = "mii"; - interrupt-parent = <&gpio1>; - interrupts = <31>, <32>; - reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>; - reg-io-width = <4>; - smsc,irq-push-pull; -}; diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index d7652596a09b..42689b7d03a2 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -28,6 +28,7 @@ select: - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a + - snps,dwmac-5.10a - snps,dwxgmac - snps,dwxgmac-2.10 @@ -82,6 +83,7 @@ properties: - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a + - snps,dwmac-5.10a - snps,dwxgmac - snps,dwxgmac-2.10 @@ -375,6 +377,7 @@ allOf: - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a + - snps,dwmac-5.10a - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac 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 783b9e32cf66..4b97a0f1175b 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml @@ -53,10 +53,10 @@ properties: "#size-cells": true compatible: - oneOf: - - const: ti,am654-cpsw-nuss - - const: ti,j721e-cpsw-nuss - - const: ti,am642-cpsw-nuss + enum: + - ti,am654-cpsw-nuss + - ti,j721e-cpsw-nuss + - ti,am642-cpsw-nuss reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml index 4317eba503ca..1a81bf70c88c 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml @@ -45,9 +45,9 @@ properties: pattern: "^cpts@[0-9a-f]+$" compatible: - oneOf: - - const: ti,am65-cpts - - const: ti,j721e-cpts + enum: + - ti,am65-cpts + - ti,j721e-cpts reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml b/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml new file mode 100644 index 000000000000..dbe4ffdd644c --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/nintendo-otp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nintendo Wii and Wii U OTP Device Tree Bindings + +description: | + This binding represents the OTP memory as found on a Nintendo Wii or Wii U, + which contains common and per-console keys, signatures and related data + required to access peripherals. + + See https://wiiubrew.org/wiki/Hardware/OTP + +maintainers: + - Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + enum: + - nintendo,hollywood-otp + - nintendo,latte-otp + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + otp@d8001ec { + compatible = "nintendo,latte-otp"; + reg = <0x0d8001ec 0x8>; + }; + +... diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml index b8dc3d2b6e92..456fb808100a 100644 --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml @@ -40,7 +40,7 @@ properties: maxItems: 1 patternProperties: - "^.*@[0-9a-f]+$": + "@[0-9a-f]+(,[0-7])?$": type: object properties: diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml index 861b205016b1..dede8892ee01 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml @@ -51,6 +51,9 @@ properties: vcc-supply: description: Our power supply. + power-domains: + maxItems: 1 + # Needed if any child nodes are present. "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml new file mode 100644 index 000000000000..2578e39deda9 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/socionext,uniphier-efuse.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier eFuse bindings + +maintainers: + - Keiji Hayashibara <hayashibara.keiji@socionext.com> + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +allOf: + - $ref: "nvmem.yaml#" + +properties: + "#address-cells": true + "#size-cells": true + + compatible: + const: socionext,uniphier-efuse + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + // The UniPhier eFuse should be a subnode of a "soc-glue" node. + + soc-glue@5f900000 { + compatible = "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x5f900000 0x2000>; + + efuse@100 { + compatible = "socionext,uniphier-efuse"; + reg = <0x100 0x28>; + }; + + efuse@200 { + compatible = "socionext,uniphier-efuse"; + reg = <0x200 0x68>; + #address-cells = <1>; + #size-cells = <1>; + + /* Data cells */ + usb_rterm0: trim@54,4 { + reg = <0x54 1>; + bits = <4 2>; + }; + usb_rterm1: trim@55,4 { + reg = <0x55 1>; + bits = <4 2>; + }; + usb_rterm2: trim@58,4 { + reg = <0x58 1>; + bits = <4 2>; + }; + usb_rterm3: trim@59,4 { + reg = <0x59 1>; + bits = <4 2>; + }; + usb_sel_t0: trim@54,0 { + reg = <0x54 1>; + bits = <0 4>; + }; + usb_sel_t1: trim@55,0 { + reg = <0x55 1>; + bits = <0 4>; + }; + usb_sel_t2: trim@58,0 { + reg = <0x58 1>; + bits = <0 4>; + }; + usb_sel_t3: trim@59,0 { + reg = <0x59 1>; + bits = <0 4>; + }; + usb_hs_i0: trim@56,0 { + reg = <0x56 1>; + bits = <0 4>; + }; + usb_hs_i2: trim@5a,0 { + reg = <0x5a 1>; + bits = <0 4>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt deleted file mode 100644 index eccf490d5a6d..000000000000 --- a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt +++ /dev/null @@ -1,49 +0,0 @@ -= UniPhier eFuse device tree bindings = - -This UniPhier eFuse must be under soc-glue. - -Required properties: -- compatible: should be "socionext,uniphier-efuse" -- reg: should contain the register location and length - -= Data cells = -Are child nodes of efuse, bindings of which as described in -bindings/nvmem/nvmem.txt - -Example: - - soc-glue@5f900000 { - compatible = "socionext,uniphier-ld20-soc-glue-debug", - "simple-mfd"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0x0 0x5f900000 0x2000>; - - efuse@100 { - compatible = "socionext,uniphier-efuse"; - reg = <0x100 0x28>; - }; - - efuse@200 { - compatible = "socionext,uniphier-efuse"; - reg = <0x200 0x68>; - #address-cells = <1>; - #size-cells = <1>; - - /* Data cells */ - usb_mon: usb-mon@54 { - reg = <0x54 0xc>; - }; - }; - }; - -= Data consumers = -Are device nodes which consume nvmem data cells. - -Example: - - usb { - ... - nvmem-cells = <&usb_mon>; - nvmem-cell-names = "usb_mon"; - } diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt index b6acbe694ffb..c3a75ac6e59d 100644 --- a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt @@ -3,7 +3,7 @@ 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/designware-pcie.txt. +Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. Additional properties are described here: @@ -33,7 +33,7 @@ Required properties: - phy-names: must contain "pcie" - device_type: - should be "pci". As specified in designware-pcie.txt + should be "pci". As specified in snps,dw-pcie.yaml Example configuration: diff --git a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt index 979dc7b6cfe8..cc6dcdb676b9 100644 --- a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt +++ b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt @@ -1,7 +1,7 @@ * Axis ARTPEC-6 PCIe interface This PCIe host controller is based on the Synopsys DesignWare PCIe IP -and thus inherits all the common properties defined in designware-pcie.txt. +and thus inherits all the common properties defined in snps,dw-pcie.yaml. Required properties: - compatible: "axis,artpec6-pcie", "snps,dw-pcie" for ARTPEC-6 in RC mode; diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt deleted file mode 100644 index 78494c4050f7..000000000000 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ /dev/null @@ -1,77 +0,0 @@ -* Synopsys DesignWare PCIe interface - -Required properties: -- compatible: - "snps,dw-pcie" for RC mode; - "snps,dw-pcie-ep" for EP mode; -- reg: For designware cores version < 4.80 contains the configuration - address space. For designware core version >= 4.80, contains - the configuration and ATU address space -- reg-names: Must be "config" for the PCIe configuration space and "atu" for - the ATU address space. - (The old way of getting the configuration address space from "ranges" - is deprecated and should be avoided.) -RC mode: -- #address-cells: set to <3> -- #size-cells: set to <2> -- device_type: set to "pci" -- ranges: ranges for the PCI memory and I/O regions -- #interrupt-cells: set to <1> -- interrupt-map-mask and interrupt-map: standard PCI - properties to define the mapping of the PCIe interface to interrupt - numbers. -EP mode: -- num-ib-windows: number of inbound address translation windows -- num-ob-windows: number of outbound address translation windows - -Optional properties: -- num-lanes: number of lanes to use (this property should be specified unless - the link is brought already up in BIOS) -- reset-gpio: GPIO pin number of power good signal -- clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - "pcie" - - "pcie_bus" -- snps,enable-cdm-check: This is a boolean property and if present enables - automatic checking of CDM (Configuration Dependent Module) registers - for data corruption. CDM registers include standard PCIe configuration - space registers, Port Logic registers, DMA and iATU (internal Address - Translation Unit) registers. -RC mode: -- num-viewport: number of view ports configured in hardware. If a platform - does not specify it, the driver assumes 2. -- bus-range: PCI bus numbers covered (it is recommended for new devicetrees - to specify this property, to keep backwards compatibility a range of - 0x00-0xff is assumed if not present) - -EP mode: -- max-functions: maximum number of functions that can be configured - -Example configuration: - - pcie: pcie@dfc00000 { - compatible = "snps,dw-pcie"; - reg = <0xdfc00000 0x0001000>, /* IP registers */ - <0xd0000000 0x0002000>; /* Configuration space */ - reg-names = "dbi", "config"; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - ranges = <0x81000000 0 0x00000000 0xde000000 0 0x00010000 - 0x82000000 0 0xd0400000 0xd0400000 0 0x0d000000>; - interrupts = <25>, <24>; - #interrupt-cells = <1>; - num-lanes = <1>; - }; -or - pcie: pcie@dfc00000 { - compatible = "snps,dw-pcie-ep"; - reg = <0xdfc00000 0x0001000>, /* IP registers 1 */ - <0xdfc01000 0x0001000>, /* IP registers 2 */ - <0xd0000000 0x2000000>; /* Configuration space */ - reg-names = "dbi", "dbi2", "addr_space"; - num-ib-windows = <6>; - num-ob-windows = <2>; - num-lanes = <1>; - }; diff --git a/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt b/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt deleted file mode 100644 index 5f8cb4962f8d..000000000000 --- a/Documentation/devicetree/bindings/pci/faraday,ftpci100.txt +++ /dev/null @@ -1,135 +0,0 @@ -Faraday Technology FTPCI100 PCI Host Bridge - -This PCI bridge is found inside that Cortina Systems Gemini SoC platform and -is a generic IP block from Faraday Technology. It exists in two variants: -plain and dual PCI. The plain version embeds a cascading interrupt controller -into the host bridge. The dual version routes the interrupts to the host -chips interrupt controller. - -The host controller appear on the PCI bus with vendor ID 0x159b (Faraday -Technology) and product ID 0x4321. - -Mandatory properties: - -- compatible: ranging from specific to generic, should be one of - "cortina,gemini-pci", "faraday,ftpci100" - "cortina,gemini-pci-dual", "faraday,ftpci100-dual" - "faraday,ftpci100" - "faraday,ftpci100-dual" -- reg: memory base and size for the host bridge -- #address-cells: set to <3> -- #size-cells: set to <2> -- #interrupt-cells: set to <1> -- bus-range: set to <0x00 0xff> -- device_type, set to "pci" -- ranges: see pci.txt -- interrupt-map-mask: see pci.txt -- interrupt-map: see pci.txt -- dma-ranges: three ranges for the inbound memory region. The ranges must - be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, 64MB, - 128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked as - pre-fetchable. - -Optional properties: -- clocks: when present, this should contain the peripheral clock (PCLK) and the - PCI clock (PCICLK). If these are not present, they are assumed to be - hard-wired enabled and always on. The PCI clock will be 33 or 66 MHz. -- clock-names: when present, this should contain "PCLK" for the peripheral - clock and "PCICLK" for the PCI-side clock. - -Mandatory subnodes: -- For "faraday,ftpci100" a node representing the interrupt-controller inside the - host bridge is mandatory. It has the following mandatory properties: - - interrupt: see interrupt-controller/interrupts.txt - - interrupt-controller: see interrupt-controller/interrupts.txt - - #address-cells: set to <0> - - #interrupt-cells: set to <1> - -I/O space considerations: - -The plain variant has 128MiB of non-prefetchable memory space, whereas the -"dual" variant has 64MiB. Take this into account when describing the ranges. - -Interrupt map considerations: - -The "dual" variant will get INT A, B, C, D from the system interrupt controller -and should point to respective interrupt in that controller in its -interrupt-map. - -The code which is the only documentation of how the Faraday PCI (the non-dual -variant) interrupts assigns the default interrupt mapping/swizzling has -typically been like this, doing the swizzling on the interrupt controller side -rather than in the interconnect: - -interrupt-map-mask = <0xf800 0 0 7>; -interrupt-map = - <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */ - <0x4800 0 0 2 &pci_intc 1>, - <0x4800 0 0 3 &pci_intc 2>, - <0x4800 0 0 4 &pci_intc 3>, - <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */ - <0x5000 0 0 2 &pci_intc 2>, - <0x5000 0 0 3 &pci_intc 3>, - <0x5000 0 0 4 &pci_intc 0>, - <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */ - <0x5800 0 0 2 &pci_intc 3>, - <0x5800 0 0 3 &pci_intc 0>, - <0x5800 0 0 4 &pci_intc 1>, - <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */ - <0x6000 0 0 2 &pci_intc 0>, - <0x6000 0 0 3 &pci_intc 1>, - <0x6000 0 0 4 &pci_intc 2>; - -Example: - -pci@50000000 { - compatible = "cortina,gemini-pci", "faraday,ftpci100"; - reg = <0x50000000 0x100>; - interrupts = <8 IRQ_TYPE_LEVEL_HIGH>, /* PCI A */ - <26 IRQ_TYPE_LEVEL_HIGH>, /* PCI B */ - <27 IRQ_TYPE_LEVEL_HIGH>, /* PCI C */ - <28 IRQ_TYPE_LEVEL_HIGH>; /* PCI D */ - #address-cells = <3>; - #size-cells = <2>; - #interrupt-cells = <1>; - - bus-range = <0x00 0xff>; - ranges = /* 1MiB I/O space 0x50000000-0x500fffff */ - <0x01000000 0 0 0x50000000 0 0x00100000>, - /* 128MiB non-prefetchable memory 0x58000000-0x5fffffff */ - <0x02000000 0 0x58000000 0x58000000 0 0x08000000>; - - /* DMA ranges */ - dma-ranges = - /* 128MiB at 0x00000000-0x07ffffff */ - <0x02000000 0 0x00000000 0x00000000 0 0x08000000>, - /* 64MiB at 0x00000000-0x03ffffff */ - <0x02000000 0 0x00000000 0x00000000 0 0x04000000>, - /* 64MiB at 0x00000000-0x03ffffff */ - <0x02000000 0 0x00000000 0x00000000 0 0x04000000>; - - interrupt-map-mask = <0xf800 0 0 7>; - interrupt-map = - <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */ - <0x4800 0 0 2 &pci_intc 1>, - <0x4800 0 0 3 &pci_intc 2>, - <0x4800 0 0 4 &pci_intc 3>, - <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */ - <0x5000 0 0 2 &pci_intc 2>, - <0x5000 0 0 3 &pci_intc 3>, - <0x5000 0 0 4 &pci_intc 0>, - <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */ - <0x5800 0 0 2 &pci_intc 3>, - <0x5800 0 0 3 &pci_intc 0>, - <0x5800 0 0 4 &pci_intc 1>, - <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */ - <0x6000 0 0 2 &pci_intc 0>, - <0x6000 0 0 3 &pci_intc 0>, - <0x6000 0 0 4 &pci_intc 0>; - pci_intc: interrupt-controller { - interrupt-parent = <&intcon>; - interrupt-controller; - #address-cells = <0>; - #interrupt-cells = <1>; - }; -}; diff --git a/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml b/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml new file mode 100644 index 000000000000..92efbf0f1297 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/faraday,ftpci100.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/faraday,ftpci100.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Faraday Technology FTPCI100 PCI Host Bridge + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + This PCI bridge is found inside that Cortina Systems Gemini SoC platform and + is a generic IP block from Faraday Technology. It exists in two variants: + plain and dual PCI. The plain version embeds a cascading interrupt controller + into the host bridge. The dual version routes the interrupts to the host + chips interrupt controller. + The host controller appear on the PCI bus with vendor ID 0x159b (Faraday + Technology) and product ID 0x4321. + I/O space considerations: + The plain variant has 128MiB of non-prefetchable memory space, whereas the + "dual" variant has 64MiB. Take this into account when describing the ranges. + + Interrupt map considerations: + + The "dual" variant will get INT A, B, C, D from the system interrupt controller + and should point to respective interrupt in that controller in its interrupt-map. + + The code which is the only documentation of how the Faraday PCI (the non-dual + variant) interrupts assigns the default interrupt mapping/swizzling has + typically been like this, doing the swizzling on the interrupt controller side + rather than in the interconnect: + + interrupt-map-mask = <0xf800 0 0 7>; + interrupt-map = + <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */ + <0x4800 0 0 2 &pci_intc 1>, + <0x4800 0 0 3 &pci_intc 2>, + <0x4800 0 0 4 &pci_intc 3>, + <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */ + <0x5000 0 0 2 &pci_intc 2>, + <0x5000 0 0 3 &pci_intc 3>, + <0x5000 0 0 4 &pci_intc 0>, + <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */ + <0x5800 0 0 2 &pci_intc 3>, + <0x5800 0 0 3 &pci_intc 0>, + <0x5800 0 0 4 &pci_intc 1>, + <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */ + <0x6000 0 0 2 &pci_intc 0>, + <0x6000 0 0 3 &pci_intc 1>, + <0x6000 0 0 4 &pci_intc 2>; + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + oneOf: + - items: + - const: cortina,gemini-pci + - const: faraday,ftpci100 + - items: + - const: cortina,gemini-pci-dual + - const: faraday,ftpci100-dual + - const: faraday,ftpci100 + - const: faraday,ftpci100-dual + + reg: + maxItems: 1 + + "#address-cells": + const: 3 + + "#interrupt-cells": + const: 1 + + ranges: + minItems: 2 + + dma-ranges: + minItems: 3 + description: | + three ranges for the inbound memory region. The ranges must + be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, 64MB, + 128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked as + pre-fetchable. + + clocks: + items: + - description: peripheral clock (PCLK) + - description: PCI clock (PCICLK). + description: | + If these are not present, they are assumed to be + hard-wired enabled and always on. The PCI clock will be 33 or 66 MHz. + + clock-names: + items: + - const: PCLK + - const: PCICLK + + interrupt-controller: + type: object + +required: + - reg + - compatible + - "#interrupt-cells" + - interrupt-map-mask + - interrupt-map + - dma-ranges + +if: + properties: + compatible: + contains: + const: faraday,ftpci100 +then: + required: + - interrupt-controller + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + pci@50000000 { + compatible = "cortina,gemini-pci", "faraday,ftpci100"; + reg = <0x50000000 0x100>; + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + + bus-range = <0x00 0xff>; + ranges = /* 1MiB I/O space 0x50000000-0x500fffff */ + <0x01000000 0 0 0x50000000 0 0x00100000>, + /* 128MiB non-prefetchable memory 0x58000000-0x5fffffff */ + <0x02000000 0 0x58000000 0x58000000 0 0x08000000>; + + /* DMA ranges */ + dma-ranges = + /* 128MiB at 0x00000000-0x07ffffff */ + <0x02000000 0 0x00000000 0x00000000 0 0x08000000>, + /* 64MiB at 0x00000000-0x03ffffff */ + <0x02000000 0 0x00000000 0x00000000 0 0x04000000>, + /* 64MiB at 0x00000000-0x03ffffff */ + <0x02000000 0 0x00000000 0x00000000 0 0x04000000>; + + interrupt-map-mask = <0xf800 0 0 7>; + interrupt-map = + <0x4800 0 0 1 &pci_intc 0>, /* Slot 9 */ + <0x4800 0 0 2 &pci_intc 1>, + <0x4800 0 0 3 &pci_intc 2>, + <0x4800 0 0 4 &pci_intc 3>, + <0x5000 0 0 1 &pci_intc 1>, /* Slot 10 */ + <0x5000 0 0 2 &pci_intc 2>, + <0x5000 0 0 3 &pci_intc 3>, + <0x5000 0 0 4 &pci_intc 0>, + <0x5800 0 0 1 &pci_intc 2>, /* Slot 11 */ + <0x5800 0 0 2 &pci_intc 3>, + <0x5800 0 0 3 &pci_intc 0>, + <0x5800 0 0 4 &pci_intc 1>, + <0x6000 0 0 1 &pci_intc 3>, /* Slot 12 */ + <0x6000 0 0 2 &pci_intc 0>, + <0x6000 0 0 3 &pci_intc 0>, + <0x6000 0 0 4 &pci_intc 0>; + pci_intc: interrupt-controller { + interrupt-parent = <&intcon>; + interrupt-controller; + interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt deleted file mode 100644 index d8971ab99274..000000000000 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt +++ /dev/null @@ -1,100 +0,0 @@ -* Freescale i.MX6 PCIe interface - -This PCIe host controller is based on the Synopsys DesignWare PCIe IP -and thus inherits all the common properties defined in designware-pcie.txt. - -Required properties: -- compatible: - - "fsl,imx6q-pcie" - - "fsl,imx6sx-pcie", - - "fsl,imx6qp-pcie" - - "fsl,imx7d-pcie" - - "fsl,imx8mq-pcie" -- reg: base address and length of the PCIe controller -- interrupts: A list of interrupt outputs of the controller. Must contain an - entry for each entry in the interrupt-names property. -- interrupt-names: Must include the following entries: - - "msi": The interrupt that is asserted when an MSI is received -- clock-names: Must include the following additional entries: - - "pcie_phy" - -Optional properties: -- fsl,tx-deemph-gen1: Gen1 De-emphasis value. Default: 0 -- fsl,tx-deemph-gen2-3p5db: Gen2 (3.5db) De-emphasis value. Default: 0 -- fsl,tx-deemph-gen2-6db: Gen2 (6db) De-emphasis value. Default: 20 -- fsl,tx-swing-full: Gen2 TX SWING FULL value. Default: 127 -- fsl,tx-swing-low: TX launch amplitude swing_low value. Default: 127 -- fsl,max-link-speed: Specify PCI gen for link capability. Must be '2' for - gen2, otherwise will default to gen1. 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. -- reset-gpio: Should specify the GPIO for controlling the PCI bus device reset - signal. It's not polarity aware and defaults to active-low reset sequence - (L=reset state, H=operation state). -- reset-gpio-active-high: If present then the reset sequence using the GPIO - specified in the "reset-gpio" property is reversed (H=reset state, - L=operation state). -- vpcie-supply: 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. -- vph-supply: 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. - -Additional required properties for imx6sx-pcie: -- clock names: Must include the following additional entries: - - "pcie_inbound_axi" -- power-domains: Must be set to phandles pointing to the DISPLAY and - PCIE_PHY power domains -- power-domain-names: Must be "pcie", "pcie_phy" - -Additional required properties for imx7d-pcie and imx8mq-pcie: -- power-domains: Must be set to a phandle pointing to PCIE_PHY power domain -- resets: Must contain phandles to PCIe-related reset lines exposed by SRC - IP block -- reset-names: Must contain the following entries: - - "pciephy" - - "apps" - - "turnoff" -- fsl,imx7d-pcie-phy: A phandle to an fsl,imx7d-pcie-phy node. - -Additional required properties for imx8mq-pcie: -- clock-names: Must include the following additional entries: - - "pcie_aux" - -Example: - - pcie@01000000 { - compatible = "fsl,imx6q-pcie", "snps,dw-pcie"; - reg = <0x01ffc000 0x04000>, - <0x01f00000 0x80000>; - reg-names = "dbi", "config"; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 - 0x81000000 0 0 0x01f80000 0 0x00010000 - 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; - num-lanes = <1>; - interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "msi"; - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 0x7>; - interrupt-map = <0 0 0 1 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, - <0 0 0 2 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, - <0 0 0 3 &intc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, - <0 0 0 4 &intc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks 144>, <&clks 206>, <&clks 189>; - clock-names = "pcie", "pcie_bus", "pcie_phy"; - }; - -* Freescale i.MX7d PCIe PHY - -This is the PHY associated with the IMX7d PCIe controller. It's used by the -PCI-e controller via the fsl,imx7d-pcie-phy phandle. - -Required properties: -- compatible: - - "fsl,imx7d-pcie-phy" -- reg: base address and length of the PCIe PHY controller diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml new file mode 100644 index 000000000000..2911e565b260 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -0,0 +1,202 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/fsl,imx6q-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX6 PCIe host controller + +maintainers: + - Lucas Stach <l.stach@pengutronix.de> + - Richard Zhu <hongxing.zhu@nxp.com> + +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. + +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + +properties: + compatible: + enum: + - fsl,imx6q-pcie + - fsl,imx6sx-pcie + - fsl,imx6qp-pcie + - fsl,imx7d-pcie + - fsl,imx8mq-pcie + + reg: + items: + - description: Data Bus Interface (DBI) registers. + - description: PCIe configuration space region. + + reg-names: + items: + - const: dbi + - const: config + + interrupts: + items: + - description: builtin MSI controller. + + interrupt-names: + minItems: 1 + 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 + - const: pcie_phy + - const: pcie_inbound_axi for imx6sx-pcie, pcie_aux for imx8mq-pcie + + 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: + 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: + items: + - const: pcie + - const: pcie_phy + + resets: + maxItems: 3 + description: Phandles to PCIe-related reset lines exposed by SRC + IP block. Additional required by imx7d-pcie and imx8mq-pcie. + + reset-names: + items: + - const: pciephy + - const: apps + - const: turnoff + + 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 + + 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 + sequence (L=reset state, H=operation state) (optional required). + + reset-gpio-active-high: + description: If present then the reset sequence using the GPIO + specified in the "reset-gpio" property is reversed (H=reset state, + L=operation state) (optional required). + + 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 + - reg-names + - "#address-cells" + - "#size-cells" + - device_type + - bus-range + - ranges + - num-lanes + - interrupts + - interrupt-names + - "#interrupt-cells" + - interrupt-map-mask + - interrupt-map + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/imx6qdl-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pcie: pcie@1ffc000 { + compatible = "fsl,imx6q-pcie"; + reg = <0x01ffc000 0x04000>, + <0x01f00000 0x80000>; + reg-names = "dbi", "config"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + bus-range = <0x00 0xff>; + ranges = <0x81000000 0 0 0x01f80000 0 0x00010000>, + <0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; + num-lanes = <1>; + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0x7>; + interrupt-map = <0 0 0 1 &gpc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 2 &gpc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 3 &gpc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 4 &gpc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks IMX6QDL_CLK_PCIE_AXI>, + <&clks IMX6QDL_CLK_LVDS1_GATE>, + <&clks IMX6QDL_CLK_PCIE_REF_125M>; + clock-names = "pcie", "pcie_bus", "pcie_phy"; + }; +... diff --git a/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml b/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml new file mode 100644 index 000000000000..cbee87802559 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml @@ -0,0 +1,167 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/hisilicon,kirin-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HiSilicon Kirin SoCs PCIe host DT description + +maintainers: + - Xiaowei Song <songxiaowei@hisilicon.com> + - Binghui Wang <wangbinghui@hisilicon.com> + +description: | + Kirin 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. + +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + +properties: + compatible: + contains: + enum: + - hisilicon,kirin960-pcie + - hisilicon,kirin970-pcie + + reg: + description: | + Should contain dbi, apb, config registers location and length. + For hisilicon,kirin960-pcie, it should also contain phy. + minItems: 3 + maxItems: 4 + + reg-names: + minItems: 3 + maxItems: 4 + + hisilicon,clken-gpios: + description: | + Clock input enablement GPIOs from PCI devices like Ethernet, M.2 and + mini-PCIe slots. + +required: + - compatible + - reg + - reg-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/hi3660-clock.h> + #include <dt-bindings/clock/hi3670-clock.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pcie@f4000000 { + compatible = "hisilicon,kirin960-pcie"; + reg = <0x0 0xf4000000 0x0 0x1000>, + <0x0 0xff3fe000 0x0 0x1000>, + <0x0 0xf3f20000 0x0 0x40000>, + <0x0 0xf5000000 0x0 0x2000>; + reg-names = "dbi", "apb", "phy", "config"; + bus-range = <0x0 0xff>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x02000000 0x0 0x00000000 + 0x0 0xf6000000 + 0x0 0x02000000>; + num-lanes = <1>; + #interrupt-cells = <1>; + interrupts = <0 283 4>; + interrupt-names = "msi"; + interrupt-map-mask = <0xf800 0 0 7>; + interrupt-map = <0x0 0 0 1 &gic GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>, + <0x0 0 0 2 &gic GIC_SPI 283 IRQ_TYPE_LEVEL_HIGH>, + <0x0 0 0 3 &gic GIC_SPI 284 IRQ_TYPE_LEVEL_HIGH>, + <0x0 0 0 4 &gic GIC_SPI 285 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&crg_ctrl HI3660_PCIEPHY_REF>, + <&crg_ctrl HI3660_CLK_GATE_PCIEAUX>, + <&crg_ctrl HI3660_PCLK_GATE_PCIE_PHY>, + <&crg_ctrl HI3660_PCLK_GATE_PCIE_SYS>, + <&crg_ctrl HI3660_ACLK_GATE_PCIE>; + clock-names = "pcie_phy_ref", "pcie_aux", "pcie_apb_phy", + "pcie_apb_sys", "pcie_aclk"; + }; + + pcie@f5000000 { + compatible = "hisilicon,kirin970-pcie"; + reg = <0x0 0xf4000000 0x0 0x1000000>, + <0x0 0xfc180000 0x0 0x1000>, + <0x0 0xf5000000 0x0 0x2000>; + reg-names = "dbi", "apb", "config"; + bus-range = <0x0 0xff>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + phys = <&pcie_phy>; + ranges = <0x02000000 0x0 0x00000000 + 0x0 0xf6000000 + 0x0 0x02000000>; + num-lanes = <1>; + #interrupt-cells = <1>; + interrupts = <GIC_SPI 283 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "msi"; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0x0 0 0 1 &gic GIC_SPI 282 IRQ_TYPE_LEVEL_HIGH>, + <0x0 0 0 2 &gic GIC_SPI 283 IRQ_TYPE_LEVEL_HIGH>, + <0x0 0 0 3 &gic GIC_SPI 284 IRQ_TYPE_LEVEL_HIGH>, + <0x0 0 0 4 &gic GIC_SPI 285 IRQ_TYPE_LEVEL_HIGH>; + reset-gpios = <&gpio7 0 0>; + hisilicon,clken-gpios = <&gpio27 3 0>, <&gpio17 0 0>, <&gpio20 6 0>; + pcie@0,0 { // Lane 0: PCIe switch: Bus 1, Device 0 + reg = <0 0 0 0 0>; + compatible = "pciclass,0604"; + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + ranges; + + pcie@0,0 { // Lane 0: upstream + reg = <0 0 0 0 0>; + compatible = "pciclass,0604"; + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + ranges; + + pcie@1,0 { // Lane 4: M.2 + reg = <0x0800 0 0 0 0>; + compatible = "pciclass,0604"; + device_type = "pci"; + reset-gpios = <&gpio3 1 0>; + #address-cells = <3>; + #size-cells = <2>; + ranges; + }; + + pcie@5,0 { // Lane 5: Mini PCIe + reg = <0x2800 0 0 0 0>; + compatible = "pciclass,0604"; + device_type = "pci"; + reset-gpios = <&gpio27 4 0 >; + #address-cells = <3>; + #size-cells = <2>; + ranges; + }; + + pcie@7,0 { // Lane 6: Ethernet + reg = <0x03800 0 0 0 0>; + compatible = "pciclass,0604"; + device_type = "pci"; + reset-gpios = <&gpio25 2 0 >; + #address-cells = <3>; + #size-cells = <2>; + ranges; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt index 760b4d740616..5f0cf6c2fef3 100644 --- a/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt +++ b/Documentation/devicetree/bindings/pci/hisilicon-histb-pcie.txt @@ -3,7 +3,7 @@ HiSilicon STB PCIe host bridge DT description The HiSilicon STB PCIe host controller is based on the DesignWare PCIe core. It shares common functions with the DesignWare PCIe core driver and inherits common properties defined in -Documentation/devicetree/bindings/pci/designware-pcie.txt. +Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. Additional properties are described here: diff --git a/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml new file mode 100644 index 000000000000..e87ff27526ff --- /dev/null +++ b/Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml @@ -0,0 +1,69 @@ +# 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#" + +title: Intel Keem Bay PCIe controller Endpoint mode + +maintainers: + - Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> + - Srikanth Thokala <srikanth.thokala@intel.com> + +properties: + compatible: + const: intel,keembay-pcie-ep + + reg: + maxItems: 5 + + reg-names: + items: + - const: dbi + - const: dbi2 + - const: atu + - const: addr_space + - const: apb + + interrupts: + maxItems: 4 + + interrupt-names: + items: + - const: pcie + - const: pcie_ev + - const: pcie_err + - const: pcie_mem_access + + num-lanes: + description: Number of lanes to use. + enum: [ 1, 2 ] + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + pcie-ep@37000000 { + compatible = "intel,keembay-pcie-ep"; + reg = <0x37000000 0x00001000>, + <0x37100000 0x00001000>, + <0x37300000 0x00001000>, + <0x36000000 0x01000000>, + <0x37800000 0x00000200>; + reg-names = "dbi", "dbi2", "atu", "addr_space", "apb"; + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 108 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "pcie", "pcie_ev", "pcie_err", "pcie_mem_access"; + num-lanes = <2>; + }; diff --git a/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml b/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml new file mode 100644 index 000000000000..ed4400c9ac09 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml @@ -0,0 +1,97 @@ +# 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#" + +title: Intel Keem Bay PCIe controller Root Complex mode + +maintainers: + - Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> + - Srikanth Thokala <srikanth.thokala@intel.com> + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + const: intel,keembay-pcie + + ranges: + maxItems: 1 + + reset-gpios: + maxItems: 1 + + reg: + maxItems: 4 + + reg-names: + items: + - const: dbi + - const: atu + - const: config + - const: apb + + clocks: + maxItems: 2 + + clock-names: + items: + - const: master + - const: aux + + interrupts: + maxItems: 3 + + interrupt-names: + items: + - const: pcie + - const: pcie_ev + - const: pcie_err + + num-lanes: + description: Number of lanes to use. + enum: [ 1, 2 ] + +required: + - compatible + - reg + - reg-names + - ranges + - clocks + - clock-names + - interrupts + - interrupt-names + - reset-gpios + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + #define KEEM_BAY_A53_PCIE + #define KEEM_BAY_A53_AUX_PCIE + pcie@37000000 { + compatible = "intel,keembay-pcie"; + reg = <0x37000000 0x00001000>, + <0x37300000 0x00001000>, + <0x36e00000 0x00200000>, + <0x37800000 0x00000200>; + reg-names = "dbi", "atu", "config", "apb"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x02000000 0 0x36000000 0x36000000 0 0x00e00000>; + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "pcie", "pcie_ev", "pcie_err"; + clocks = <&scmi_clk KEEM_BAY_A53_PCIE>, + <&scmi_clk KEEM_BAY_A53_AUX_PCIE>; + clock-names = "master", "aux"; + reset-gpios = <&pca2 9 GPIO_ACTIVE_LOW>; + num-lanes = <2>; + }; diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml index a1e2be737eec..54e2890ae631 100644 --- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: PCIe RC controller on Intel Gateway SoCs maintainers: - - Dilip Kota <eswara.kota@linux.intel.com> + - Rahul Tanwar <rtanwar@maxlinear.com> select: properties: @@ -17,21 +17,15 @@ select: required: - compatible +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + properties: compatible: items: - const: intel,lgm-pcie - const: snps,dw-pcie - device_type: - const: pci - - "#address-cells": - const: 3 - - "#size-cells": - const: 2 - reg: items: - description: Controller control and status registers. @@ -62,30 +56,13 @@ properties: reset-gpios: maxItems: 1 - linux,pci-domain: true - num-lanes: maximum: 2 - description: Number of lanes to use for this port. - - '#interrupt-cells': - const: 1 - - interrupt-map-mask: - description: Standard PCI IRQ mapping properties. - - interrupt-map: - description: Standard PCI IRQ mapping properties. max-link-speed: - description: Specify PCI Gen for link capability. - $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 2, 3, 4] default: 1 - bus-range: - description: Range of bus numbers associated with this controller. - reset-assert-ms: description: | Delay after asserting reset to the PCIe device. @@ -94,9 +71,6 @@ properties: required: - compatible - - device_type - - "#address-cells" - - "#size-cells" - reg - reg-names - ranges @@ -109,7 +83,7 @@ required: - interrupt-map - interrupt-map-mask -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/pci/kirin-pcie.txt b/Documentation/devicetree/bindings/pci/kirin-pcie.txt deleted file mode 100644 index 6bbe43818ad5..000000000000 --- a/Documentation/devicetree/bindings/pci/kirin-pcie.txt +++ /dev/null @@ -1,50 +0,0 @@ -HiSilicon Kirin SoCs PCIe host DT description - -Kirin 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/designware-pcie.txt. - -Additional properties are described here: - -Required properties -- compatible: - "hisilicon,kirin960-pcie" for PCIe of Kirin960 SoC -- reg: Should contain rc_dbi, apb, phy, config registers location and length. -- reg-names: Must include the following entries: - "dbi": controller configuration registers; - "apb": apb Ctrl register defined by Kirin; - "phy": apb PHY register defined by Kirin; - "config": PCIe configuration space registers. -- reset-gpios: The GPIO to generate PCIe PERST# assert and deassert signal. - -Optional properties: - -Example based on kirin960: - - pcie@f4000000 { - compatible = "hisilicon,kirin-pcie"; - reg = <0x0 0xf4000000 0x0 0x1000>, <0x0 0xff3fe000 0x0 0x1000>, - <0x0 0xf3f20000 0x0 0x40000>, <0x0 0xF4000000 0 0x2000>; - reg-names = "dbi","apb","phy", "config"; - bus-range = <0x0 0x1>; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - ranges = <0x02000000 0x0 0x00000000 0x0 0xf5000000 0x0 0x2000000>; - num-lanes = <1>; - #interrupt-cells = <1>; - interrupt-map-mask = <0xf800 0 0 7>; - interrupt-map = <0x0 0 0 1 &gic 0 0 0 282 4>, - <0x0 0 0 2 &gic 0 0 0 283 4>, - <0x0 0 0 3 &gic 0 0 0 284 4>, - <0x0 0 0 4 &gic 0 0 0 285 4>; - clocks = <&crg_ctrl HI3660_PCIEPHY_REF>, - <&crg_ctrl HI3660_CLK_GATE_PCIEAUX>, - <&crg_ctrl HI3660_PCLK_GATE_PCIE_PHY>, - <&crg_ctrl HI3660_PCLK_GATE_PCIE_SYS>, - <&crg_ctrl HI3660_ACLK_GATE_PCIE>; - clock-names = "pcie_phy_ref", "pcie_aux", - "pcie_apb_phy", "pcie_apb_sys", "pcie_aclk"; - reset-gpios = <&gpio11 1 0 >; - }; diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index 6d898dd4a8e2..f36efa73a470 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -1,7 +1,7 @@ Freescale Layerscape PCIe controller This PCIe host controller is based on the Synopsys DesignWare PCIe IP -and thus inherits all the common properties defined in designware-pcie.txt. +and thus inherits all the common properties defined in snps,dw-pcie.yaml. This controller derives its clocks from the Reset Configuration Word (RCW) which is used to describe the PLL settings at the time of chip-reset. diff --git a/Documentation/devicetree/bindings/pci/loongson.yaml b/Documentation/devicetree/bindings/pci/loongson.yaml index 82bc6c486ca3..a8324a9bd002 100644 --- a/Documentation/devicetree/bindings/pci/loongson.yaml +++ b/Documentation/devicetree/bindings/pci/loongson.yaml @@ -17,10 +17,10 @@ allOf: properties: compatible: - oneOf: - - const: loongson,ls2k-pci - - const: loongson,ls7a-pci - - const: loongson,rs780e-pci + enum: + - loongson,ls2k-pci + - loongson,ls7a-pci + - loongson,rs780e-pci reg: minItems: 1 diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-cfg.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-cfg.yaml new file mode 100644 index 000000000000..841a3d284bbf --- /dev/null +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-cfg.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/mediatek-pcie-cfg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek PCIECFG controller + +maintainers: + - Chuanjia Liu <chuanjia.liu@mediatek.com> + - Jianjun Wang <jianjun.wang@mediatek.com> + +description: | + The MediaTek PCIECFG controller controls some feature about + LTSSM, ASPM and so on. + +properties: + compatible: + items: + - enum: + - mediatek,generic-pciecfg + - const: syscon + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pciecfg: pciecfg@1a140000 { + compatible = "mediatek,generic-pciecfg", "syscon"; + reg = <0x1a140000 0x1000>; + }; +... diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt index 7468d666763a..57ae73462272 100644 --- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt @@ -8,7 +8,7 @@ Required properties: "mediatek,mt7623-pcie" "mediatek,mt7629-pcie" - device_type: Must be "pci" -- reg: Base addresses and lengths of the PCIe subsys and root ports. +- reg: Base addresses and lengths of the root ports. - reg-names: Names of the above areas to use during resource lookup. - #address-cells: Address representation for root ports (must be 3) - #size-cells: Size representation for root ports (must be 2) @@ -47,9 +47,12 @@ Required properties for MT7623/MT2701: - reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the number of root ports. -Required properties for MT2712/MT7622: +Required properties for MT2712/MT7622/MT7629: -interrupts: A list of interrupt outputs of the controller, must have one entry for each PCIe port +- interrupt-names: Must include the following entries: + - "pcie_irq": The interrupt that is asserted when an MSI/INTX is received +- linux,pci-domain: PCI domain ID. Should be unique for each host controller In addition, the device tree node must have sub-nodes describing each PCIe port interface, having the following mandatory properties: @@ -143,130 +146,143 @@ Examples for MT7623: Examples for MT2712: - pcie: pcie@11700000 { + pcie1: pcie@112ff000 { compatible = "mediatek,mt2712-pcie"; device_type = "pci"; - reg = <0 0x11700000 0 0x1000>, - <0 0x112ff000 0 0x1000>; - reg-names = "port0", "port1"; + reg = <0 0x112ff000 0 0x1000>; + reg-names = "port1"; + linux,pci-domain = <1>; #address-cells = <3>; #size-cells = <2>; - interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>, - <&topckgen CLK_TOP_PE2_MAC_P1_SEL>, - <&pericfg CLK_PERI_PCIE0>, + interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "pcie_irq"; + clocks = <&topckgen CLK_TOP_PE2_MAC_P1_SEL>, <&pericfg CLK_PERI_PCIE1>; - clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1"; - phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>; - phy-names = "pcie-phy0", "pcie-phy1"; + clock-names = "sys_ck1", "ahb_ck1"; + phys = <&u3port1 PHY_TYPE_PCIE>; + phy-names = "pcie-phy1"; bus-range = <0x00 0xff>; - ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>; + ranges = <0x82000000 0 0x11400000 0x0 0x11400000 0 0x300000>; + status = "disabled"; - pcie0: pcie@0,0 { - reg = <0x0000 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_intc1 0>, + <0 0 0 2 &pcie_intc1 1>, + <0 0 0 3 &pcie_intc1 2>, + <0 0 0 4 &pcie_intc1 3>; + pcie_intc1: interrupt-controller { + interrupt-controller; + #address-cells = <0>; #interrupt-cells = <1>; - ranges; - interrupt-map-mask = <0 0 0 7>; - interrupt-map = <0 0 0 1 &pcie_intc0 0>, - <0 0 0 2 &pcie_intc0 1>, - <0 0 0 3 &pcie_intc0 2>, - <0 0 0 4 &pcie_intc0 3>; - pcie_intc0: interrupt-controller { - interrupt-controller; - #address-cells = <0>; - #interrupt-cells = <1>; - }; }; + }; - pcie1: pcie@1,0 { - reg = <0x0800 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; + pcie0: pcie@11700000 { + compatible = "mediatek,mt2712-pcie"; + device_type = "pci"; + reg = <0 0x11700000 0 0x1000>; + reg-names = "port0"; + linux,pci-domain = <0>; + #address-cells = <3>; + #size-cells = <2>; + interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "pcie_irq"; + clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>, + <&pericfg CLK_PERI_PCIE0>; + clock-names = "sys_ck0", "ahb_ck0"; + phys = <&u3port0 PHY_TYPE_PCIE>; + phy-names = "pcie-phy0"; + bus-range = <0x00 0xff>; + ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>; + status = "disabled"; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_intc0 0>, + <0 0 0 2 &pcie_intc0 1>, + <0 0 0 3 &pcie_intc0 2>, + <0 0 0 4 &pcie_intc0 3>; + pcie_intc0: interrupt-controller { + interrupt-controller; + #address-cells = <0>; #interrupt-cells = <1>; - ranges; - interrupt-map-mask = <0 0 0 7>; - interrupt-map = <0 0 0 1 &pcie_intc1 0>, - <0 0 0 2 &pcie_intc1 1>, - <0 0 0 3 &pcie_intc1 2>, - <0 0 0 4 &pcie_intc1 3>; - pcie_intc1: interrupt-controller { - interrupt-controller; - #address-cells = <0>; - #interrupt-cells = <1>; - }; }; }; Examples for MT7622: - pcie: pcie@1a140000 { + pcie0: pcie@1a143000 { compatible = "mediatek,mt7622-pcie"; device_type = "pci"; - reg = <0 0x1a140000 0 0x1000>, - <0 0x1a143000 0 0x1000>, - <0 0x1a145000 0 0x1000>; - reg-names = "subsys", "port0", "port1"; + reg = <0 0x1a143000 0 0x1000>; + reg-names = "port0"; + linux,pci-domain = <0>; #address-cells = <3>; #size-cells = <2>; - interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>; + interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>; + interrupt-names = "pcie_irq"; clocks = <&pciesys CLK_PCIE_P0_MAC_EN>, - <&pciesys CLK_PCIE_P1_MAC_EN>, <&pciesys CLK_PCIE_P0_AHB_EN>, - <&pciesys CLK_PCIE_P1_AHB_EN>, <&pciesys CLK_PCIE_P0_AUX_EN>, - <&pciesys CLK_PCIE_P1_AUX_EN>, <&pciesys CLK_PCIE_P0_AXI_EN>, - <&pciesys CLK_PCIE_P1_AXI_EN>, <&pciesys CLK_PCIE_P0_OBFF_EN>, - <&pciesys CLK_PCIE_P1_OBFF_EN>, - <&pciesys CLK_PCIE_P0_PIPE_EN>, - <&pciesys CLK_PCIE_P1_PIPE_EN>; - clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1", - "aux_ck0", "aux_ck1", "axi_ck0", "axi_ck1", - "obff_ck0", "obff_ck1", "pipe_ck0", "pipe_ck1"; - phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>; - phy-names = "pcie-phy0", "pcie-phy1"; + <&pciesys CLK_PCIE_P0_PIPE_EN>; + clock-names = "sys_ck0", "ahb_ck0", "aux_ck0", + "axi_ck0", "obff_ck0", "pipe_ck0"; + power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>; bus-range = <0x00 0xff>; - ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>; + ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x8000000>; + status = "disabled"; - pcie0: pcie@0,0 { - reg = <0x0000 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_intc0 0>, + <0 0 0 2 &pcie_intc0 1>, + <0 0 0 3 &pcie_intc0 2>, + <0 0 0 4 &pcie_intc0 3>; + pcie_intc0: interrupt-controller { + interrupt-controller; + #address-cells = <0>; #interrupt-cells = <1>; - ranges; - interrupt-map-mask = <0 0 0 7>; - interrupt-map = <0 0 0 1 &pcie_intc0 0>, - <0 0 0 2 &pcie_intc0 1>, - <0 0 0 3 &pcie_intc0 2>, - <0 0 0 4 &pcie_intc0 3>; - pcie_intc0: interrupt-controller { - interrupt-controller; - #address-cells = <0>; - #interrupt-cells = <1>; - }; }; + }; - pcie1: pcie@1,0 { - reg = <0x0800 0 0 0 0>; - #address-cells = <3>; - #size-cells = <2>; + pcie1: pcie@1a145000 { + compatible = "mediatek,mt7622-pcie"; + device_type = "pci"; + reg = <0 0x1a145000 0 0x1000>; + reg-names = "port1"; + linux,pci-domain = <1>; + #address-cells = <3>; + #size-cells = <2>; + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>; + interrupt-names = "pcie_irq"; + clocks = <&pciesys CLK_PCIE_P1_MAC_EN>, + /* designer has connect RC1 with p0_ahb clock */ + <&pciesys CLK_PCIE_P0_AHB_EN>, + <&pciesys CLK_PCIE_P1_AUX_EN>, + <&pciesys CLK_PCIE_P1_AXI_EN>, + <&pciesys CLK_PCIE_P1_OBFF_EN>, + <&pciesys CLK_PCIE_P1_PIPE_EN>; + clock-names = "sys_ck1", "ahb_ck1", "aux_ck1", + "axi_ck1", "obff_ck1", "pipe_ck1"; + + power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>; + bus-range = <0x00 0xff>; + ranges = <0x82000000 0 0x28000000 0x0 0x28000000 0 0x8000000>; + status = "disabled"; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_intc1 0>, + <0 0 0 2 &pcie_intc1 1>, + <0 0 0 3 &pcie_intc1 2>, + <0 0 0 4 &pcie_intc1 3>; + pcie_intc1: interrupt-controller { + interrupt-controller; + #address-cells = <0>; #interrupt-cells = <1>; - ranges; - interrupt-map-mask = <0 0 0 7>; - interrupt-map = <0 0 0 1 &pcie_intc1 0>, - <0 0 0 2 &pcie_intc1 1>, - <0 0 0 3 &pcie_intc1 2>, - <0 0 0 4 &pcie_intc1 3>; - pcie_intc1: interrupt-controller { - interrupt-controller; - #address-cells = <0>; - #interrupt-cells = <1>; - }; }; }; diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt index bd43f3c3ece4..6a99d2aa8075 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt @@ -1,7 +1,8 @@ NVIDIA Tegra PCIe controller (Synopsys DesignWare Core based) This PCIe controller is based on the Synopsis Designware PCIe IP -and thus inherits all the common properties defined in designware-pcie.txt. +and thus inherits all the common properties defined in snps,dw-pcie.yaml and +snps,dw-pcie-ep.yaml. Some of the controller instances are dual mode where in they can work either in root port mode or endpoint mode but one at a time. @@ -22,7 +23,7 @@ Required properties: property. - reg-names: Must include the following entries: "appl": Controller's application logic registers - "config": As per the definition in designware-pcie.txt + "config": As per the definition in snps,dw-pcie.yaml "atu_dma": iATU and DMA registers. This is where the iATU (internal Address Translation Unit) registers of the PCIe core are made available for SW access. diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt b/Documentation/devicetree/bindings/pci/pci-armada8k.txt index 7a813d0e6d63..ff25a134befa 100644 --- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt +++ b/Documentation/devicetree/bindings/pci/pci-armada8k.txt @@ -1,7 +1,7 @@ * Marvell Armada 7K/8K PCIe interface This PCIe host controller is based on the Synopsys DesignWare PCIe IP -and thus inherits all the common properties defined in designware-pcie.txt. +and thus inherits all the common properties defined in snps,dw-pcie.yaml. Required properties: - compatible: "marvell,armada8k-pcie" diff --git a/Documentation/devicetree/bindings/pci/pci-ep.yaml b/Documentation/devicetree/bindings/pci/pci-ep.yaml index 7847bbcd4a03..ccec51ab5247 100644 --- a/Documentation/devicetree/bindings/pci/pci-ep.yaml +++ b/Documentation/devicetree/bindings/pci/pci-ep.yaml @@ -23,6 +23,13 @@ properties: default: 1 maximum: 255 + max-virtual-functions: + description: Array representing the number of virtual functions corresponding to each physical + function + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 1 + maxItems: 255 + max-link-speed: $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 1, 2, 3, 4 ] diff --git a/Documentation/devicetree/bindings/pci/pcie-al.txt b/Documentation/devicetree/bindings/pci/pcie-al.txt index 557a5089229d..2ad1fe466eab 100644 --- a/Documentation/devicetree/bindings/pci/pcie-al.txt +++ b/Documentation/devicetree/bindings/pci/pcie-al.txt @@ -2,7 +2,7 @@ Amazon's Annapurna Labs PCIe Host Controller is based on the Synopsys DesignWare PCI core. It inherits common properties defined in -Documentation/devicetree/bindings/pci/designware-pcie.txt. +Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. Properties of the host controller node that differ from it are: diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt index 25f4def468bf..3f646875f8c2 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt @@ -34,22 +34,22 @@ - device_type: Usage: required Value type: <string> - Definition: Should be "pci". As specified in designware-pcie.txt + Definition: Should be "pci". As specified in snps,dw-pcie.yaml - #address-cells: Usage: required Value type: <u32> - Definition: Should be 3. As specified in designware-pcie.txt + Definition: Should be 3. As specified in snps,dw-pcie.yaml - #size-cells: Usage: required Value type: <u32> - Definition: Should be 2. As specified in designware-pcie.txt + Definition: Should be 2. As specified in snps,dw-pcie.yaml - ranges: Usage: required Value type: <prop-encoded-array> - Definition: As specified in designware-pcie.txt + Definition: As specified in snps,dw-pcie.yaml - interrupts: Usage: required @@ -64,17 +64,17 @@ - #interrupt-cells: Usage: required Value type: <u32> - Definition: Should be 1. As specified in designware-pcie.txt + Definition: Should be 1. As specified in snps,dw-pcie.yaml - interrupt-map-mask: Usage: required Value type: <prop-encoded-array> - Definition: As specified in designware-pcie.txt + Definition: As specified in snps,dw-pcie.yaml - interrupt-map: Usage: required Value type: <prop-encoded-array> - Definition: As specified in designware-pcie.txt + Definition: As specified in snps,dw-pcie.yaml - clocks: Usage: required diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml index 1810bf722350..445eed94b53f 100644 --- a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml @@ -13,10 +13,10 @@ maintainers: description: |+ Exynos5433 SoC PCIe host controller is based on the Synopsys DesignWare PCIe IP and thus inherits all the common properties defined in - designware-pcie.txt. + snps,dw-pcie.yaml. allOf: - - $ref: /schemas/pci/pci-bus.yaml# + - $ref: /schemas/pci/snps,dw-pcie.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml index b03cbb9b6602..2b9d1d6fc661 100644 --- a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml @@ -10,14 +10,14 @@ description: |+ SiFive FU740 PCIe host controller is based on the Synopsys DesignWare PCI core. It shares common features with the PCIe DesignWare core and inherits common properties defined in - Documentation/devicetree/bindings/pci/designware-pcie.txt. + Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. maintainers: - Paul Walmsley <paul.walmsley@sifive.com> - Greentime Hu <greentime.hu@sifive.com> allOf: - - $ref: /schemas/pci/pci-bus.yaml# + - $ref: /schemas/pci/snps,dw-pcie.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml new file mode 100644 index 000000000000..b5935b1b153f --- /dev/null +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/snps,dw-pcie-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare PCIe endpoint interface + +maintainers: + - Jingoo Han <jingoohan1@gmail.com> + - Gustavo Pimentel <gustavo.pimentel@synopsys.com> + +description: | + Synopsys DesignWare PCIe host controller endpoint + +allOf: + - $ref: /schemas/pci/pci-ep.yaml# + +properties: + compatible: + anyOf: + - {} + - const: snps,dw-pcie-ep + + reg: + description: | + It should contain Data Bus Interface (dbi) and config registers for all + versions. + For designware core version >= 4.80, it may contain ATU address space. + minItems: 2 + maxItems: 4 + + reg-names: + minItems: 2 + maxItems: 4 + items: + enum: [dbi, dbi2, config, atu, addr_space, link, atu_dma, appl] + + reset-gpio: + description: GPIO pin number of PERST# signal + maxItems: 1 + deprecated: true + + reset-gpios: + description: GPIO controlled connection to PERST# signal + maxItems: 1 + + snps,enable-cdm-check: + type: boolean + description: | + This is a boolean property and if present enables + automatic checking of CDM (Configuration Dependent Module) registers + for data corruption. CDM registers include standard PCIe configuration + space registers, Port Logic registers, DMA and iATU (internal Address + Translation Unit) registers. + + num-ib-windows: + description: number of inbound address translation windows + maxItems: 1 + deprecated: true + + num-ob-windows: + description: number of outbound address translation windows + maxItems: 1 + deprecated: true + + max-functions: + $ref: /schemas/types.yaml#/definitions/uint32 + description: maximum number of functions that can be configured + +required: + - reg + - reg-names + - compatible + +unevaluatedProperties: false + +examples: + - | + bus { + #address-cells = <1>; + #size-cells = <1>; + pcie-ep@dfd00000 { + compatible = "snps,dw-pcie-ep"; + reg = <0xdfc00000 0x0001000>, /* IP registers 1 */ + <0xdfc01000 0x0001000>, /* IP registers 2 */ + <0xd0000000 0x2000000>; /* Configuration space */ + reg-names = "dbi", "dbi2", "addr_space"; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml new file mode 100644 index 000000000000..9ed0dfba7f89 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/snps,dw-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare PCIe interface + +maintainers: + - Jingoo Han <jingoohan1@gmail.com> + - Gustavo Pimentel <gustavo.pimentel@synopsys.com> + +description: | + Synopsys DesignWare PCIe host controller + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + anyOf: + - {} + - const: snps,dw-pcie + + reg: + description: | + It should contain Data Bus Interface (dbi) and config registers for all + versions. + For designware core version >= 4.80, it may contain ATU address space. + minItems: 2 + maxItems: 5 + + reg-names: + minItems: 2 + maxItems: 5 + items: + enum: [ dbi, dbi2, config, atu, app, elbi, mgmt, ctrl, parf, cfg, link, + ulreg, smu, mpu, apb, phy ] + + num-lanes: + description: | + number of lanes to use (this property should be specified unless + the link is brought already up in firmware) + maximum: 16 + + reset-gpio: + description: GPIO pin number of PERST# signal + maxItems: 1 + deprecated: true + + reset-gpios: + description: GPIO controlled connection to PERST# signal + maxItems: 1 + + interrupts: true + + interrupt-names: true + + clocks: true + + snps,enable-cdm-check: + type: boolean + description: | + This is a boolean property and if present enables + automatic checking of CDM (Configuration Dependent Module) registers + for data corruption. CDM registers include standard PCIe configuration + space registers, Port Logic registers, DMA and iATU (internal Address + Translation Unit) registers. + + num-viewport: + description: | + number of view ports configured in hardware. If a platform + does not specify it, the driver autodetects it. + deprecated: true + +unevaluatedProperties: false + +required: + - reg + - reg-names + - compatible + +examples: + - | + bus { + #address-cells = <1>; + #size-cells = <1>; + pcie@dfc00000 { + device_type = "pci"; + compatible = "snps,dw-pcie"; + reg = <0xdfc00000 0x0001000>, /* IP registers */ + <0xd0000000 0x0002000>; /* Configuration space */ + reg-names = "dbi", "config"; + #address-cells = <3>; + #size-cells = <2>; + ranges = <0x81000000 0 0x00000000 0xde000000 0 0x00010000>, + <0x82000000 0 0xd0400000 0xd0400000 0 0x0d000000>; + interrupts = <25>, <24>; + #interrupt-cells = <1>; + num-lanes = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml index d6cf8a560ef0..144cbcd60a1c 100644 --- a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml @@ -10,13 +10,13 @@ description: | UniPhier PCIe endpoint controller is based on the Synopsys DesignWare PCI core. It shares common features with the PCIe DesignWare core and inherits common properties defined in - Documentation/devicetree/bindings/pci/designware-pcie.txt. + Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml. maintainers: - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> allOf: - - $ref: "pci-ep.yaml#" + - $ref: /schemas/pci/snps,dw-pcie-ep.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt index d5cbfe6b0d89..8147e3e3e29b 100644 --- a/Documentation/devicetree/bindings/pci/ti-pci.txt +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt @@ -12,7 +12,7 @@ PCIe DesignWare Controller number of PHYs as specified in *phys* property. - ti,hwmods : Name of the hwmod associated to the pcie, "pcie<X>", where <X> is the instance number of the pcie from the HW spec. - - num-lanes as specified in ../designware-pcie.txt + - num-lanes as specified in ../snps,dw-pcie.yaml - ti,syscon-lane-sel : phandle/offset pair. Phandle to the system control module and the register offset to specify lane selection. @@ -32,7 +32,7 @@ HOST MODE device_type, ranges, interrupt-map-mask, - interrupt-map : as specified in ../designware-pcie.txt + interrupt-map : as specified in ../snps,dw-pcie.yaml - ti,syscon-unaligned-access: phandle to the syscon DT node. The 1st argument should contain the register offset within syscon and the 2nd argument should contain the bit field diff --git a/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml new file mode 100644 index 000000000000..30b6396d83c8 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/toshiba,visconti-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toshiba Visconti5 SoC PCIe Host Controller Device Tree Bindings + +maintainers: + - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> + +description: + Toshiba Visconti5 SoC PCIe host controller is based on the Synopsys DesignWare PCIe IP. + +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + +properties: + compatible: + const: toshiba,visconti-pcie + + reg: + items: + - description: Data Bus Interface (DBI) registers. + - description: PCIe configuration space region. + - description: Visconti specific additional registers. + - description: Visconti specific SMU registers + - description: Visconti specific memory protection unit registers (MPU) + + reg-names: + items: + - const: dbi + - const: config + - const: ulreg + - const: smu + - const: mpu + + interrupts: + maxItems: 1 + + clocks: + items: + - description: PCIe reference clock + - description: PCIe system clock + - description: Auxiliary clock + + clock-names: + items: + - const: ref + - const: core + - const: aux + + num-lanes: + const: 2 + +required: + - reg + - reg-names + - interrupts + - "#interrupt-cells" + - interrupt-map + - interrupt-map-mask + - num-lanes + - clocks + - clock-names + - max-link-speed + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pcie: pcie@28400000 { + compatible = "toshiba,visconti-pcie"; + reg = <0x0 0x28400000 0x0 0x00400000>, + <0x0 0x70000000 0x0 0x10000000>, + <0x0 0x28050000 0x0 0x00010000>, + <0x0 0x24200000 0x0 0x00002000>, + <0x0 0x24162000 0x0 0x00001000>; + reg-names = "dbi", "config", "ulreg", "smu", "mpu"; + device_type = "pci"; + bus-range = <0x00 0xff>; + num-lanes = <2>; + num-viewport = <8>; + + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x81000000 0 0x40000000 0 0x40000000 0 0x00010000>, + <0x82000000 0 0x50000000 0 0x50000000 0 0x20000000>; + interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "intr"; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = + <0 0 0 1 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH + 0 0 0 2 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH + 0 0 0 3 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH + 0 0 0 4 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&extclk100mhz>, <&clk600mhz>, <&clk25mhz>; + clock-names = "ref", "core", "aux"; + max-link-speed = <2>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt index c4b7381733a0..359585db049f 100644 --- a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt +++ b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt @@ -6,7 +6,7 @@ on Socionext UniPhier SoCs. UniPhier 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/designware-pcie.txt. +Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml. Required properties: - compatible: Should be "socionext,uniphier-pcie". diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt index 2d677e90a7e2..f56f8c58c5d9 100644 --- a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt +++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt @@ -35,6 +35,7 @@ Required properties: Optional properties: - dma-coherent: present if DMA operations are coherent +- clocks: Input clock specifier. Refer to common clock bindings Example: ++++++++ diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt deleted file mode 100644 index 7c70f2ad9942..000000000000 --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Freescale i.MX8MQ USB3 PHY binding - -Required properties: -- compatible: Should be "fsl,imx8mq-usb-phy" or "fsl,imx8mp-usb-phy" -- #phys-cells: must be 0 (see phy-bindings.txt in this directory) -- reg: The base address and length of the registers -- clocks: phandles to the clocks for each clock listed in clock-names -- clock-names: must contain "phy" - -Optional properties: -- vbus-supply: A phandle to the regulator for USB VBUS. - -Example: - usb3_phy0: phy@381f0040 { - compatible = "fsl,imx8mq-usb-phy"; - reg = <0x381f0040 0x40>; - clocks = <&clk IMX8MQ_CLK_USB1_PHY_ROOT>; - clock-names = "phy"; - #phy-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml new file mode 100644 index 000000000000..2936f3510a6a --- /dev/null +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/fsl,imx8mq-usb-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8MQ USB3 PHY binding + +maintainers: + - Li Jun <jun.li@nxp.com> + +properties: + compatible: + enum: + - fsl,imx8mq-usb-phy + - fsl,imx8mp-usb-phy + + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: phy + + vbus-supply: + description: + A phandle to the regulator for USB VBUS. + +required: + - compatible + - reg + - "#phy-cells" + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mq-clock.h> + usb3_phy0: phy@381f0040 { + compatible = "fsl,imx8mq-usb-phy"; + reg = <0x381f0040 0x40>; + clocks = <&clk IMX8MQ_CLK_USB1_PHY_ROOT>; + clock-names = "phy"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml b/Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml new file mode 100644 index 000000000000..17367a0275fe --- /dev/null +++ b/Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/hisilicon,phy-hi3670-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HiSilicon Kirin970 PCIe PHY + +maintainers: + - Mauro Carvalho Chehab <mchehab+huawei@kernel.org> + +description: |+ + Bindings for PCIe PHY on HiSilicon Kirin 970. + +properties: + compatible: + const: hisilicon,hi970-pcie-phy + + "#phy-cells": + const: 0 + + reg: + maxItems: 1 + description: PHY Control registers + + phy-supply: + description: The PCIe PHY power supply + + clocks: + items: + - description: PCIe PHY clock + - description: PCIe AUX clock + - description: PCIe APB PHY clock + - description: PCIe APB SYS clock + - description: PCIe ACLK clock + + clock-names: + items: + - const: phy_ref + - const: aux + - const: apb_phy + - const: apb_sys + - const: aclk + + hisilicon,eye-diagram-param: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Eye diagram for phy. + +required: + - "#phy-cells" + - compatible + - reg + - clocks + - clock-names + - hisilicon,eye-diagram-param + - phy-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/hi3670-clock.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + pcie_phy: pcie-phy@fc000000 { + compatible = "hisilicon,hi970-pcie-phy"; + reg = <0x0 0xfc000000 0x0 0x80000>; + #phy-cells = <0>; + phy-supply = <&ldo33>; + clocks = <&crg_ctrl HI3670_CLK_GATE_PCIEPHY_REF>, + <&crg_ctrl HI3670_CLK_GATE_PCIEAUX>, + <&crg_ctrl HI3670_PCLK_GATE_PCIE_PHY>, + <&crg_ctrl HI3670_PCLK_GATE_PCIE_SYS>, + <&crg_ctrl HI3670_ACLK_GATE_PCIE>; + clock-names = "phy_ref", "aux", + "apb_phy", "apb_sys", "aclk"; + hisilicon,eye-diagram-param = <0xffffffff 0xffffffff + 0xffffffff 0xffffffff 0xffffffff>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml b/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml index a217bb8ac5bc..52815b6c2b88 100644 --- a/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml +++ b/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/phy/intel,phy-keembay-usb.yaml# +$id: http://devicetree.org/schemas/phy/intel,keembay-phy-usb.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel Keem Bay USB PHY bindings diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml index edd9d70a672a..954e67571dfd 100644 --- a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml +++ b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml @@ -23,9 +23,9 @@ description: |+ properties: compatible: - oneOf: - - const: intel,lgm-emmc-phy - - const: intel,keembay-emmc-phy + enum: + - intel,lgm-emmc-phy + - intel,keembay-emmc-phy "#phy-cells": const: 0 diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index ef9d9d4e6875..9e6c0f43f1c6 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -15,7 +15,7 @@ description: | controllers on MediaTek SoCs, includes USB2.0, USB3.0, PCIe and SATA. Layout differences of banks between T-PHY V1 (mt8173/mt2701) and - T-PHY V2 (mt2712) when works on USB mode: + T-PHY V2 (mt2712) / V3 (mt8195) when works on USB mode: ----------------------------------- Version 1: port offset bank @@ -34,7 +34,7 @@ description: | u2 port2 0x1800 U2PHY_COM ... - Version 2: + Version 2/3: port offset bank u2 port0 0x0000 MISC 0x0100 FMREG @@ -59,7 +59,8 @@ description: | SPLLC shared by u3 ports and FMREG shared by u2 ports on V1 are put back into each port; a new bank MISC for u2 ports and CHIP for u3 ports are - added on V2. + added on V2; the FMREG bank for slew rate calibration is not used anymore + and reserved on V3; properties: $nodename: @@ -79,8 +80,11 @@ properties: - mediatek,mt2712-tphy - mediatek,mt7629-tphy - mediatek,mt8183-tphy - - mediatek,mt8195-tphy - const: mediatek,generic-tphy-v2 + - items: + - enum: + - mediatek,mt8195-tphy + - const: mediatek,generic-tphy-v3 - const: mediatek,mt2701-u3phy deprecated: true - const: mediatek,mt2712-u3phy @@ -91,7 +95,7 @@ properties: description: Register shared by multiple ports, exclude port's private register. It is needed for T-PHY V1, such as mt2701 and mt8173, but not for - T-PHY V2, such as mt2712. + T-PHY V2/V3, such as mt2712. maxItems: 1 "#address-cells": @@ -197,6 +201,22 @@ patternProperties: Specify the flag to enable BC1.2 if support it type: boolean + mediatek,syscon-type: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + description: + A phandle to syscon used to access the register of type switch, + the field should always be 3 cells long. + items: + items: + - description: + The first cell represents a phandle to syscon + - description: + The second cell represents the register offset + - description: + The third cell represents the index of config segment + enum: [0, 1, 2, 3] + required: - reg - "#phy-cells" diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index f0497b8623ad..75be5650a198 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,ipq6018-qmp-pcie-phy + - qcom,ipq6018-qmp-usb3-phy - qcom,ipq8074-qmp-pcie-phy - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-pcie-phy @@ -27,6 +28,7 @@ properties: - qcom,msm8998-qmp-ufs-phy - qcom,msm8998-qmp-usb3-phy - qcom,sc7180-qmp-usb3-phy + - qcom,sc8180x-qmp-pcie-phy - qcom,sc8180x-qmp-ufs-phy - qcom,sc8180x-qmp-usb3-phy - qcom,sdm845-qhp-pcie-phy @@ -34,6 +36,7 @@ properties: - qcom,sdm845-qmp-ufs-phy - qcom,sdm845-qmp-usb3-phy - qcom,sdm845-qmp-usb3-uni-phy + - qcom,sm6115-qmp-ufs-phy - qcom,sm8150-qmp-ufs-phy - qcom,sm8150-qmp-usb3-phy - qcom,sm8150-qmp-usb3-uni-phy @@ -326,6 +329,7 @@ allOf: compatible: contains: enum: + - qcom,sc8180x-qmp-pcie-phy - qcom,sdm845-qhp-pcie-phy - qcom,sdm845-qmp-pcie-phy - qcom,sdx55-qmp-pcie-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml index 217aa6c91893..60dc27834e1d 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml @@ -14,6 +14,8 @@ properties: compatible: enum: - qcom,sc7180-qmp-usb3-dp-phy + - qcom,sc7280-qmp-usb3-dp-phy + - qcom,sc8180x-qmp-usb3-dp-phy - qcom,sdm845-qmp-usb3-dp-phy - qcom,sm8250-qmp-usb3-dp-phy reg: diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index d5dc5a3cdceb..3a6e1165419c 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -30,6 +30,11 @@ properties: - renesas,usb2-phy-r8a77995 # R-Car D3 - const: renesas,rcar-gen3-usb2-phy + - items: + - enum: + - renesas,usb2-phy-r9a07g044 # RZ/G2{L,LC} + - const: renesas,rzg2l-usb2-phy # RZ/G2L family + reg: maxItems: 1 @@ -91,6 +96,16 @@ required: - clocks - '#phy-cells' +allOf: + - if: + properties: + compatible: + contains: + const: renesas,rzg2l-usb2-phy + then: + required: + - resets + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml index 636cc501b54f..f6ed1a005e7a 100644 --- a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml @@ -16,6 +16,7 @@ properties: compatible: enum: - samsung,exynos7-ufs-phy + - samsung,exynosautov9-ufs-phy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt deleted file mode 100644 index 64b286d2d398..000000000000 --- a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt +++ /dev/null @@ -1,82 +0,0 @@ -TI AM654 SERDES - -Required properties: - - compatible: Should be "ti,phy-am654-serdes" - - reg : Address and length of the register set for the device. - - #phy-cells: determine the number of cells that should be given in the - phandle while referencing this phy. Should be "2". The 1st cell - corresponds to the phy type (should be one of the types specified in - include/dt-bindings/phy/phy.h) and the 2nd cell should be the serdes - lane function. - If SERDES0 is referenced 2nd cell should be: - 0 - USB3 - 1 - PCIe0 Lane0 - 2 - ICSS2 SGMII Lane0 - If SERDES1 is referenced 2nd cell should be: - 0 - PCIe1 Lane0 - 1 - PCIe0 Lane1 - 2 - ICSS2 SGMII Lane1 - - power-domains: As documented by the generic PM domain bindings in - Documentation/devicetree/bindings/power/power_domain.txt. - - clocks: List of clock-specifiers representing the input to the SERDES. - Should have 3 items representing the left input clock, external - reference clock and right input clock in that order. - - clock-output-names: List of clock names for each of the clock outputs of - SERDES. Should have 3 items for CMU reference clock, - left output clock and right output clock in that order. - - assigned-clocks: As defined in - Documentation/devicetree/bindings/clock/clock-bindings.txt - - assigned-clock-parents: As defined in - Documentation/devicetree/bindings/clock/clock-bindings.txt - - #clock-cells: Should be <1> to choose between the 3 output clocks. - Defined in Documentation/devicetree/bindings/clock/clock-bindings.txt - - The following macros are defined in dt-bindings/phy/phy-am654-serdes.h - for selecting the correct reference clock. This can be used while - specifying the clocks created by SERDES. - => AM654_SERDES_CMU_REFCLK - => AM654_SERDES_LO_REFCLK - => AM654_SERDES_RO_REFCLK - - - mux-controls: Phandle to the multiplexer that is used to select the lane - function. See #phy-cells above to see the multiplex values. - -Example: - -Example for SERDES0 is given below. It has 3 clock inputs; -left input reference clock as indicated by <&k3_clks 153 4>, external -reference clock as indicated by <&k3_clks 153 1> and right input -reference clock as indicated by <&serdes1 AM654_SERDES_LO_REFCLK>. (The -right input of SERDES0 is connected to the left output of SERDES1). - -SERDES0 registers 3 clock outputs as indicated in clock-output-names. The -first refers to the CMU reference clock, second refers to the left output -reference clock and the third refers to the right output reference clock. - -The assigned-clocks and assigned-clock-parents is used here to set the -parent of left input reference clock to MAINHSDIV_CLKOUT4 and parent of -CMU reference clock to left input reference clock. - -serdes0: serdes@900000 { - compatible = "ti,phy-am654-serdes"; - reg = <0x0 0x900000 0x0 0x2000>; - reg-names = "serdes"; - #phy-cells = <2>; - power-domains = <&k3_pds 153>; - clocks = <&k3_clks 153 4>, <&k3_clks 153 1>, - <&serdes1 AM654_SERDES_LO_REFCLK>; - clock-output-names = "serdes0_cmu_refclk", "serdes0_lo_refclk", - "serdes0_ro_refclk"; - assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>; - assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>; - ti,serdes-clk = <&serdes0_clk>; - mux-controls = <&serdes_mux 0>; - #clock-cells = <1>; -}; - -Example for PCIe consumer node using the SERDES PHY specifier is given below. -&pcie0_rc { - num-lanes = <2>; - phys = <&serdes0 PHY_TYPE_PCIE 1>, <&serdes1 PHY_TYPE_PCIE 1>; - phy-names = "pcie-phy0", "pcie-phy1"; -}; diff --git a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml new file mode 100644 index 000000000000..62dcb84c08aa --- /dev/null +++ b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/ti,phy-am654-serdes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM654 SERDES binding + +description: + This binding describes the TI AM654 SERDES. AM654 SERDES can be configured + to be used with either PCIe or USB or SGMII. + +maintainers: + - Kishon Vijay Abraham I <kishon@ti.com> + +properties: + compatible: + enum: + - ti,phy-am654-serdes + + reg: + maxItems: 1 + + reg-names: + items: + - const: serdes + + power-domains: + maxItems: 1 + + clocks: + maxItems: 3 + description: + 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: + The 1st cell corresponds to the phy type (should be one of the types specified in + include/dt-bindings/phy/phy.h) and the 2nd cell should be the serdes lane function. + + ti,serdes-clk: + description: Phandle to the SYSCON entry required for configuring SERDES clock selection. + $ref: /schemas/types.yaml#/definitions/phandle + + '#clock-cells': + const: 1 + + mux-controls: + maxItems: 1 + description: Phandle to the SYSCON entry required for configuring SERDES lane function. + + clock-output-names: + oneOf: + - description: Clock output names for SERDES 0 + items: + - const: serdes0_cmu_refclk + - const: serdes0_lo_refclk + - const: serdes0_ro_refclk + - description: Clock output names for SERDES 1 + items: + - const: serdes1_cmu_refclk + - const: serdes1_lo_refclk + - const: serdes1_ro_refclk + +required: + - compatible + - reg + - power-domains + - clocks + - assigned-clocks + - assigned-clock-parents + - ti,serdes-clk + - mux-controls + - clock-output-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/phy/phy-am654-serdes.h> + + serdes0: serdes@900000 { + compatible = "ti,phy-am654-serdes"; + reg = <0x900000 0x2000>; + reg-names = "serdes"; + #phy-cells = <2>; + power-domains = <&k3_pds 153>; + clocks = <&k3_clks 153 4>, <&k3_clks 153 1>, + <&serdes1 AM654_SERDES_LO_REFCLK>; + clock-output-names = "serdes0_cmu_refclk", "serdes0_lo_refclk", "serdes0_ro_refclk"; + assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>; + assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>; + ti,serdes-clk = <&serdes0_clk>; + mux-controls = <&serdes_mux 0>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml index 5272b6f284ba..dcd63908aeae 100644 --- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml +++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml @@ -77,6 +77,34 @@ properties: Type-C spec states minimum CC pin debounce of 100 ms and maximum of 200 ms. However, some solutions might need more than 200 ms. + refclk-dig: + type: object + description: | + WIZ node should have subnode for refclk_dig to select the reference + clock source for the reference clock used in the PHY and PMA digital + logic. + properties: + clocks: + minItems: 2 + maxItems: 4 + description: Phandle to two (Torrent) or four (Sierra) clock nodes representing + the inputs to refclk_dig + + "#clock-cells": + const: 0 + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + required: + - clocks + - "#clock-cells" + - assigned-clocks + - assigned-clock-parents + patternProperties: "^pll[0|1]-refclk$": type: object @@ -121,34 +149,6 @@ patternProperties: - clocks - "#clock-cells" - "^refclk-dig$": - type: object - description: | - WIZ node should have subnode for refclk_dig to select the reference - clock source for the reference clock used in the PHY and PMA digital - logic. - properties: - clocks: - minItems: 2 - maxItems: 4 - description: Phandle to two (Torrent) or four (Sierra) clock nodes representing - the inputs to refclk_dig - - "#clock-cells": - const: 0 - - assigned-clocks: - maxItems: 1 - - assigned-clock-parents: - maxItems: 1 - - required: - - clocks - - "#clock-cells" - - assigned-clocks - - assigned-clock-parents - "^serdes@[0-9a-f]+$": type: object description: | diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml new file mode 100644 index 000000000000..86622c4f374b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/fsl,imx8ulp-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale IMX8ULP IOMUX Controller + +maintainers: + - Jacky Bai <ping.bai@nxp.com> + +description: + Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory + for common binding part and usage. + +properties: + compatible: + const: fsl,imx8ulp-iomuxc1 + + reg: + maxItems: 1 + +# Client device subnode's properties +patternProperties: + 'grp$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + fsl,pins: + description: + each entry consists of 5 integers and represents the mux and config + setting for one pin. The first 4 integers <mux_config_reg input_reg + mux_mode input_val> are specified using a PIN_FUNC_ID macro, which can + be found in <arch/arm64/boot/dts/freescale/imx8ulp-pinfunc.h>. The last + integer CONFIG is the pad setting value like pull-up on this pin. Please + refer to i.MX8ULP Reference Manual for detailed CONFIG settings. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_config_reg" indicates the offset of mux register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_mode" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. + + required: + - fsl,pins + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + # Pinmux controller node + - | + iomuxc: pinctrl@298c0000 { + compatible = "fsl,imx8ulp-iomuxc1"; + reg = <0x298c0000 0x10000>; + + pinctrl_lpuart5: lpuart5grp { + fsl,pins = + <0x0138 0x08F0 0x4 0x3 0x3>, + <0x013C 0x08EC 0x4 0x3 0x3>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml index a4846d78111c..a12d0ceb7637 100644 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml @@ -19,10 +19,10 @@ description: > pin within that GPIO port. For example PA0 is the first pin in GPIO port A, and PB31 is the last pin in GPIO port B. The JZ4730, the JZ4740, the JZ4725B, the X1000 and the X1830 contains 4 GPIO ports, PA to PD, for a total of 128 - pins. The X2000 contains 5 GPIO ports, PA to PE, for a total of 160 pins. - The JZ4750, the JZ4755 the JZ4760, the JZ4770 and the JZ4780 contains 6 GPIO - ports, PA to PF, for a total of 192 pins. The JZ4775 contains 7 GPIO ports, - PA to PG, for a total of 224 pins. + pins. The X2000 and the X2100 contains 5 GPIO ports, PA to PE, for a total of + 160 pins. The JZ4750, the JZ4755 the JZ4760, the JZ4770 and the JZ4780 contains + 6 GPIO ports, PA to PF, for a total of 192 pins. The JZ4775 contains 7 GPIO + ports, PA to PG, for a total of 224 pins. maintainers: - Paul Cercueil <paul@crapouillou.net> @@ -47,6 +47,7 @@ properties: - ingenic,x1500-pinctrl - ingenic,x1830-pinctrl - ingenic,x2000-pinctrl + - ingenic,x2100-pinctrl - items: - const: ingenic,jz4760b-pinctrl - const: ingenic,jz4760-pinctrl @@ -85,6 +86,7 @@ patternProperties: - ingenic,x1500-gpio - ingenic,x1830-gpio - ingenic,x2000-gpio + - ingenic,x2100-gpio reg: items: diff --git a/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml b/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml new file mode 100644 index 000000000000..5e99d79499b4 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-keembay.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/intel,pinctrl-keembay.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Keem Bay pin controller Device Tree Bindings + +maintainers: + - Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com> + +description: | + Intel Keem Bay SoC integrates a pin controller which enables control + of pin directions, input/output values and configuration + for a total of 80 pins. + +properties: + compatible: + const: intel,keembay-pinctrl + + reg: + maxItems: 2 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + ngpios: + description: The number of GPIOs exposed. + const: 80 + + interrupts: + description: + Specifies the interrupt lines to be used by the controller. + Each interrupt line is shared by upto 4 GPIO lines. + maxItems: 8 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + +patternProperties: + '^gpio@[0-9a-f]*$': + type: object + + 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 "GPIO79". + + bias-disable: true + + bias-pull-down: true + + bias-pull-up: true + + drive-strength: + description: IO pads drive strength in milli Ampere. + enum: [2, 4, 8, 12] + + bias-bus-hold: + type: boolean + + input-schmitt-enable: + type: boolean + + slew-rate: + description: GPIO slew rate control. + 0 - Fast(~100MHz) + 1 - Slow(~50MHz) + enum: [0, 1] + +additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - ngpios + - '#gpio-cells' + - interrupts + - interrupt-controller + - '#interrupt-cells' + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + // Example 1 + gpio@0 { + compatible = "intel,keembay-pinctrl"; + reg = <0x600b0000 0x88>, + <0x600b0190 0x1ac>; + gpio-controller; + ngpios = <0x50>; + #gpio-cells = <0x2>; + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + // Example 2 + gpio@1 { + compatible = "intel,keembay-pinctrl"; + reg = <0x600c0000 0x88>, + <0x600c0190 0x1ac>; + gpio-controller; + ngpios = <0x50>; + #gpio-cells = <0x2>; + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt index 38dc56a57760..ecec514b3155 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt @@ -43,19 +43,19 @@ group emmc_nb group pwm0 - pin 11 (GPIO1-11) - - functions pwm, gpio + - functions pwm, led, gpio group pwm1 - pin 12 - - functions pwm, gpio + - functions pwm, led, gpio group pwm2 - pin 13 - - functions pwm, gpio + - functions pwm, led, gpio group pwm3 - pin 14 - - functions pwm, gpio + - functions pwm, led, gpio group pmic1 - pin 7 diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml new file mode 100644 index 000000000000..f8e6e138dc13 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-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/mediatek,mt65xx-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT65xx Pin Controller Device Tree Bindings + +maintainers: + - Sean Wang <sean.wang@kernel.org> + +description: |+ + The Mediatek's Pin controller is used to control SoC pins. + +properties: + compatible: + enum: + - mediatek,mt2701-pinctrl + - mediatek,mt2712-pinctrl + - mediatek,mt6397-pinctrl + - mediatek,mt7623-pinctrl + - mediatek,mt8127-pinctrl + - mediatek,mt8135-pinctrl + - mediatek,mt8167-pinctrl + - mediatek,mt8173-pinctrl + - mediatek,mt8516-pinctrl + + reg: + maxItems: 1 + + pins-are-numbered: + $ref: /schemas/types.yaml#/definitions/flag + description: | + Specify the subnodes are using numbered pinmux to specify pins. + + 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. + + mediatek,pctl-regmap: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 2 + description: | + Should be phandles of the syscfg node. + + interrupt-controller: true + + interrupts: + minItems: 1 + maxItems: 3 + + "#interrupt-cells": + const: 2 + +required: + - compatible + - pins-are-numbered + - gpio-controller + - "#gpio-cells" + +patternProperties: + '-[0-9]+$': + type: object + additionalProperties: false + patternProperties: + 'pins': + type: object + additionalProperties: false + 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" + + 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 <soc>-pinfunc.h directly. + + bias-disable: true + + bias-pull-up: + 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 + as MTK_PUPD_SET_R1R0_00. See dt-bindings/pinctrl/mt65xx.h for + valid arguments. + + bias-pull-down: true + + input-enable: true + + input-disable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + drive-strength: + description: | + Can support some arguments, such as MTK_DRIVE_4mA, MTK_DRIVE_6mA, + etc. See dt-bindings/pinctrl/mt65xx.h for valid arguments. + + required: + - pinmux + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/mt8135-pinfunc.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + syscfg_pctl_a: syscfg-pctl-a@10005000 { + compatible = "mediatek,mt8135-pctl-a-syscfg", "syscon"; + reg = <0 0x10005000 0 0x1000>; + }; + + syscfg_pctl_b: syscfg-pctl-b@1020c020 { + compatible = "mediatek,mt8135-pctl-b-syscfg", "syscon"; + reg = <0 0x1020C020 0 0x1000>; + }; + + pinctrl@1c20800 { + compatible = "mediatek,mt8135-pinctrl"; + reg = <0 0x1000B000 0 0x1000>; + mediatek,pctl-regmap = <&syscfg_pctl_a>, <&syscfg_pctl_b>; + pins-are-numbered; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; + + i2c0_pins_a: i2c0-0 { + pins1 { + pinmux = <MT8135_PIN_100_SDA0__FUNC_SDA0>, + <MT8135_PIN_101_SCL0__FUNC_SCL0>; + bias-disable; + }; + }; + + i2c1_pins_a: i2c1-0 { + pins { + pinmux = <MT8135_PIN_195_SDA1__FUNC_SDA1>, + <MT8135_PIN_196_SCL1__FUNC_SCL1>; + bias-pull-up = <MTK_PUPD_SET_R1R0_01>; + }; + }; + + i2c2_pins_a: i2c2-0 { + pins1 { + pinmux = <MT8135_PIN_193_SDA2__FUNC_SDA2>; + bias-pull-down; + }; + + pins2 { + pinmux = <MT8135_PIN_49_WATCHDOG__FUNC_GPIO49>; + bias-pull-up; + }; + }; + + i2c3_pins_a: i2c3-0 { + pins1 { + pinmux = <MT8135_PIN_40_DAC_CLK__FUNC_GPIO40>, + <MT8135_PIN_41_DAC_WS__FUNC_GPIO41>; + bias-pull-up = <MTK_PUPD_SET_R1R0_01>; + }; + + pins2 { + pinmux = <MT8135_PIN_35_SCL3__FUNC_SCL3>, + <MT8135_PIN_36_SDA3__FUNC_SDA3>; + output-low; + bias-pull-up = <MTK_PUPD_SET_R1R0_01>; + }; + + pins3 { + pinmux = <MT8135_PIN_57_JTCK__FUNC_GPIO57>, + <MT8135_PIN_60_JTDI__FUNC_JTDI>; + drive-strength = <32>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml new file mode 100644 index 000000000000..76a6df75ed9c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml @@ -0,0 +1,173 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt6797-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT6797 Pin Controller Device Tree Bindings + +maintainers: + - Sean Wang <sean.wang@kernel.org> + +description: |+ + The MediaTek's MT6797 Pin controller is used to control SoC pins. + +properties: + compatible: + const: mediatek,mt6797-pinctrl + + reg: + minItems: 5 + maxItems: 5 + + reg-names: + items: + - const: gpio + - const: iocfgl + - const: iocfgb + - const: iocfgr + - const: iocfgt + + 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. + + interrupt-controller: true + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - reg-names + - gpio-controller + - "#gpio-cells" + +patternProperties: + '-[0-9]+$': + type: object + additionalProperties: false + patternProperties: + 'pins': + type: object + additionalProperties: false + 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" + + 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 <soc>-pinfunc.h directly. + + bias-disable: true + + bias-pull-up: true + + bias-pull-down: true + + input-enable: true + + input-disable: true + + output-enable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + drive-strength: + enum: [2, 4, 8, 12, 16] + + slew-rate: + enum: [0, 1] + + 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: + 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. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + 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: + 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. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + mediatek,tdsel: + 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: | + An integer describing the steps for input level shifter duty cycle + when asserted (high pulse width adjustment). Valid arguments are + from 0 to 63. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - pinmux + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/mt6797-pinfunc.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pio: pinctrl@10005000 { + compatible = "mediatek,mt6797-pinctrl"; + reg = <0 0x10005000 0 0x1000>, + <0 0x10002000 0 0x400>, + <0 0x10002400 0 0x400>, + <0 0x10002800 0 0x400>, + <0 0x10002C00 0 0x400>; + reg-names = "gpio", "iocfgl", "iocfgb", "iocfgr", "iocfgt"; + gpio-controller; + #gpio-cells = <2>; + + uart_pins_a: uart-0 { + pins1 { + pinmux = <MT6797_GPIO232__FUNC_URXD1>, + <MT6797_GPIO233__FUNC_UTXD1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml new file mode 100644 index 000000000000..0feecd376c69 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml @@ -0,0 +1,373 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT7622 Pin Controller Device Tree Bindings + +maintainers: + - Sean Wang <sean.wang@kernel.org> + +description: |+ + The MediaTek's MT7622 Pin controller is used to control SoC pins. + +properties: + compatible: + enum: + - mediatek,mt7622-pinctrl + - mediatek,mt7629-pinctrl + + reg: + maxItems: 1 + + reg-names: + items: + - const: eint + + 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. + + interrupt-controller: true + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +if: + required: + - interrupt-controller +then: + required: + - reg-names + - interrupts + - "#interrupt-cells" + +patternProperties: + '-[0-9]+$': + type: object + additionalProperties: false + patternProperties: + 'mux': + type: object + additionalProperties: false + description: | + pinmux configuration nodes. + $ref: "/schemas/pinctrl/pinmux-node.yaml" + properties: + function: + 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: | + An array of strings. Each string contains the name of a group. + + drive-strength: + enum: [4, 8, 12, 16] + + required: + - groups + - function + + allOf: + - if: + properties: + function: + const: emmc + then: + properties: + groups: + enum: [emmc, emmc_rst] + - if: + properties: + function: + const: eth + then: + properties: + groups: + enum: [esw, esw_p0_p1, esw_p2_p3_p4, rgmii_via_esw, + rgmii_via_gmac1, rgmii_via_gmac2, mdc_mdio] + - if: + properties: + function: + const: i2c + then: + properties: + groups: + enum: [i2c0, i2c_0, i2c_1, i2c1_0, i2c1_1, i2c1_2, i2c2_0, + i2c2_1, i2c2_2] + - if: + properties: + function: + const: i2s + then: + properties: + groups: + enum: [i2s_in_mclk_bclk_ws, i2s1_in_data, i2s2_in_data, + i2s3_in_data, i2s4_in_data, i2s_out_mclk_bclk_ws, + i2s1_out_data, i2s2_out_data, i2s3_out_data, + i2s4_out_data] + - if: + properties: + function: + const: ir + then: + properties: + groups: + enum: [ir_0_tx, ir_1_tx, ir_2_tx, ir_0_rx, ir_1_rx, ir_2_rx] + - if: + properties: + function: + const: led + then: + properties: + groups: + enum: [ephy_leds, ephy0_led, ephy1_led, ephy2_led, ephy3_led, + ephy4_led, wled, wf2g_led, wf5g_led] + - if: + properties: + function: + const: flash + then: + properties: + groups: + enum: [par_nand, snfi, spi_nor] + - if: + properties: + function: + const: pcie + then: + properties: + groups: + enum: [pcie0_0_waken, pcie0_1_waken, pcie1_0_waken, + pcie0_0_clkreq, pcie0_1_clkreq, pcie1_0_clkreq, + pcie0_pad_perst, pcie1_pad_perst, pcie_pereset, + pcie_wake, pcie_clkreq] + - if: + properties: + function: + const: pmic + then: + properties: + groups: + enum: [pmic_bus] + - if: + properties: + function: + const: pwm + then: + properties: + groups: + enum: [pwm_ch1_0, pwm_ch1_1, pwm_ch1_2, pwm_ch2_0, pwm_ch2_1, + pwm_ch2_2, pwm_ch3_0, pwm_ch3_1, pwm_ch3_2, pwm_ch4_0, + pwm_ch4_1, pwm_ch4_2, pwm_ch4_3, pwm_ch5_0, pwm_ch5_1, + pwm_ch5_2, pwm_ch6_0, pwm_ch6_1, pwm_ch6_2, pwm_ch6_3, + pwm_ch7_0, pwm_0, pwm_1] + - if: + properties: + function: + const: sd + then: + properties: + groups: + enum: [sd_0, sd_1] + - if: + properties: + function: + const: spi + then: + properties: + groups: + enum: [spic0_0, spic0_1, spic1_0, spic1_1, spic2_0_wp_hold, + spic2_0, spi_0, spi_1, spi_wp, spi_hold] + - if: + properties: + function: + const: tdm + then: + properties: + groups: + enum: [tdm_0_out_mclk_bclk_ws, tdm_0_in_mclk_bclk_ws, + tdm_0_out_data, tdm_0_in_data, tdm_1_out_mclk_bclk_ws, + tdm_1_in_mclk_bclk_ws, tdm_1_out_data, tdm_1_in_data] + - if: + properties: + function: + const: uart + then: + properties: + groups: + enum: [uart0_0_tx_rx, uart1_0_tx_rx, uart1_0_rts_cts, + uart1_1_tx_rx, uart1_1_rts_cts, uart2_0_tx_rx, + uart2_0_rts_cts, uart2_1_tx_rx, uart2_1_rts_cts, + uart2_2_tx_rx, uart2_2_rts_cts, uart2_3_tx_rx, + uart3_0_tx_rx, uart3_1_tx_rx, uart3_1_rts_cts, + uart4_0_tx_rx, uart4_1_tx_rx, uart4_1_rts_cts, + uart4_2_tx_rx, uart4_2_rts_cts, uart0_txd_rxd, + uart1_0_txd_rxd, uart1_0_cts_rts, uart1_1_txd_rxd, + uart1_1_cts_rts, uart2_0_txd_rxd, uart2_0_cts_rts, + uart2_1_txd_rxd, uart2_1_cts_rts] + - if: + properties: + function: + const: watchdog + then: + properties: + groups: + enum: [watchdog] + - if: + properties: + function: + const: wifi + then: + properties: + groups: + enum: [wf0_2g, wf0_5g] + + 'conf': + type: object + additionalProperties: false + description: | + pinconf configuration nodes. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + groups: + description: | + An array of strings. Each string contains the name of a group. + Valid values are the same as the pinmux node. + + pins: + 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, + I2C_SDA, I2C_SCL, I2S2_IN, I2S3_IN, I2S4_IN, I2S2_OUT, + I2S3_OUT, I2S4_OUT, GPIO_B, MDC, MDIO, G2_TXD0, G2_TXD1, + G2_TXD2, G2_TXD3, G2_TXEN, G2_TXC, G2_RXD0, G2_RXD1, G2_RXD2, + G2_RXD3, G2_RXDV, G2_RXC, NCEB, NWEB, NREB, NDL4, NDL5, NDL6, + NDL7, NRB, NCLE, NALE, NDL0, NDL1, NDL2, NDL3, MDI_TP_P0, + MDI_TN_P0, MDI_RP_P0, MDI_RN_P0, MDI_TP_P1, MDI_TN_P1, + MDI_RP_P1, MDI_RN_P1, MDI_RP_P2, MDI_RN_P2, MDI_TP_P2, + MDI_TN_P2, MDI_TP_P3, MDI_TN_P3, MDI_RP_P3, MDI_RN_P3, + MDI_RP_P4, MDI_RN_P4, MDI_TP_P4, MDI_TN_P4, PMIC_SCL, + PMIC_SDA, SPIC1_CLK, SPIC1_MOSI, SPIC1_MISO, SPIC1_CS, + GPIO_D, WATCHDOG, RTS3_N, CTS3_N, TXD3, RXD3, PERST0_N, + PERST1_N, WLED_N, EPHY_LED0_N, AUXIN0, AUXIN1, AUXIN2, + AUXIN3, TXD4, RXD4, RTS4_N, CST4_N, PWM1, PWM2, PWM3, PWM4, + PWM5, PWM6, PWM7, GPIO_E, TOP_5G_CLK, TOP_5G_DATA, + WF0_5G_HB0, WF0_5G_HB1, WF0_5G_HB2, WF0_5G_HB3, WF0_5G_HB4, + WF0_5G_HB5, WF0_5G_HB6, XO_REQ, TOP_RST_N, SYS_WATCHDOG, + EPHY_LED0_N_JTDO, EPHY_LED1_N_JTDI, EPHY_LED2_N_JTMS, + EPHY_LED3_N_JTCLK, EPHY_LED4_N_JTRST_N, WF2G_LED_N, + WF5G_LED_N, GPIO_9, GPIO_10, GPIO_11, GPIO_12, UART1_TXD, + UART1_RXD, UART1_CTS, UART1_RTS, UART2_TXD, UART2_RXD, + UART2_CTS, UART2_RTS, SMI_MDC, SMI_MDIO, PCIE_PERESET_N, + PWM_0, GPIO_0, GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5, + GPIO_6, GPIO_7, GPIO_8, UART0_TXD, UART0_RXD, TOP_2G_CLK, + TOP_2G_DATA, WF0_2G_HB0, WF0_2G_HB1, WF0_2G_HB2, WF0_2G_HB3, + WF0_2G_HB4, WF0_2G_HB5, WF0_2G_HB6] + + bias-disable: true + + bias-pull-up: true + + bias-pull-down: true + + input-enable: true + + input-disable: true + + output-enable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + drive-strength: + enum: [4, 8, 12, 16] + + slew-rate: + enum: [0, 1] + + mediatek,tdsel: + 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: | + An integer describing the steps for input level shifter duty cycle + when asserted (high pulse width adjustment). Valid arguments are + from 0 to 63. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - pins + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pio: pinctrl@10211000 { + compatible = "mediatek,mt7622-pinctrl"; + reg = <0 0x10211000 0 0x1000>; + gpio-controller; + #gpio-cells = <2>; + + pinctrl_eth_default: eth-0 { + mux-mdio { + groups = "mdc_mdio"; + function = "eth"; + drive-strength = <12>; + }; + + mux-gmac2 { + groups = "rgmii_via_gmac2"; + function = "eth"; + drive-strength = <12>; + }; + + mux-esw { + groups = "esw"; + function = "eth"; + drive-strength = <8>; + }; + + conf-mdio { + pins = "MDC"; + bias-pull-up; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml new file mode 100644 index 000000000000..cc1509e9b981 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml @@ -0,0 +1,228 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt8183-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT8183 Pin Controller Device Tree Bindings + +maintainers: + - Sean Wang <sean.wang@kernel.org> + +description: |+ + The MediaTek's MT8183 Pin controller is used to control SoC pins. + +properties: + compatible: + const: mediatek,mt8183-pinctrl + + reg: + minItems: 10 + maxItems: 10 + + reg-names: + items: + - const: iocfg0 + - const: iocfg1 + - const: iocfg2 + - const: iocfg3 + - const: iocfg4 + - const: iocfg5 + - const: iocfg6 + - const: iocfg7 + - const: iocfg8 + - const: eint + + 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. + + gpio-ranges: + minItems: 1 + maxItems: 5 + description: | + GPIO valid number range. + + interrupt-controller: true + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - gpio-ranges + +patternProperties: + '-[0-9]+$': + type: object + additionalProperties: false + patternProperties: + 'pins': + type: object + additionalProperties: false + 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" + + 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 <soc>-pinfunc.h directly. + + bias-disable: true + + bias-pull-up: true + + bias-pull-down: true + + input-enable: true + + input-disable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + + mediatek,drive-strength-adv: + description: | + 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 + can support 0.125/0.25/0.5/1mA adjustment. If we enable specific + driving setup, the existing generic setup will be disabled. + The specific driving setup is controlled by E1E0EN. + When E1=0/E0=0, the strength is 0.125mA. + When E1=0/E0=1, the strength is 0.25mA. + When E1=1/E0=0, the strength is 0.5mA. + When E1=1/E0=1, the strength is 1mA. + EN is used to enable or disable the specific driving setup. + Valid arguments are described as below: + 0: (E1, E0, EN) = (0, 0, 0) + 1: (E1, E0, EN) = (0, 0, 1) + 2: (E1, E0, EN) = (0, 1, 0) + 3: (E1, E0, EN) = (0, 1, 1) + 4: (E1, E0, EN) = (1, 0, 0) + 5: (E1, E0, EN) = (1, 0, 1) + 6: (E1, E0, EN) = (1, 1, 0) + 7: (E1, E0, EN) = (1, 1, 1) + So the valid arguments are from 0 to 7. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + 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: + 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. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + 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: + 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. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + mediatek,tdsel: + 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: | + An integer describing the steps for input level shifter duty cycle + when asserted (high pulse width adjustment). Valid arguments are + from 0 to 63. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - pinmux + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/mt8183-pinfunc.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pio: pinctrl@10005000 { + compatible = "mediatek,mt8183-pinctrl"; + reg = <0 0x10005000 0 0x1000>, + <0 0x11f20000 0 0x1000>, + <0 0x11e80000 0 0x1000>, + <0 0x11e70000 0 0x1000>, + <0 0x11e90000 0 0x1000>, + <0 0x11d30000 0 0x1000>, + <0 0x11d20000 0 0x1000>, + <0 0x11c50000 0 0x1000>, + <0 0x11f30000 0 0x1000>, + <0 0x1000b000 0 0x1000>; + reg-names = "iocfg0", "iocfg1", "iocfg2", + "iocfg3", "iocfg4", "iocfg5", + "iocfg6", "iocfg7", "iocfg8", + "eint"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pio 0 0 192>; + interrupt-controller; + interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; + #interrupt-cells = <2>; + + i2c0_pins_a: i2c-0 { + pins1 { + pinmux = <PINMUX_GPIO48__FUNC_SCL5>, + <PINMUX_GPIO49__FUNC_SDA5>; + mediatek,pull-up-adv = <3>; + mediatek,drive-strength-adv = <7>; + }; + }; + + i2c1_pins_a: i2c-1 { + pins { + 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-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt deleted file mode 100644 index 5fe2c26c28bf..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt +++ /dev/null @@ -1,156 +0,0 @@ -* Mediatek MT65XX Pin Controller - -The Mediatek's Pin controller is used to control SoC pins. - -Required properties: -- compatible: value should be one of the following. - "mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl. - "mediatek,mt2712-pinctrl", compatible with mt2712 pinctrl. - "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl. - "mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl. - "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl. - "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl. - "mediatek,mt8167-pinctrl", compatible with mt8167 pinctrl. - "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl. - "mediatek,mt8365-pinctrl", compatible with mt8365 pinctrl. - "mediatek,mt8516-pinctrl", compatible with mt8516 pinctrl. -- pins-are-numbered: Specify the subnodes are using numbered pinmux to - specify pins. -- gpio-controller : Marks the device node as a gpio controller. -- #gpio-cells: 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. - - Eg: <&pio 6 0> - <[phandle of the gpio controller node] - [line number within the gpio controller] - [flags]> - - Values for gpio specifier: - - Line number: is a value between 0 to 202. - - Flags: bit field of flags, as defined in <dt-bindings/gpio/gpio.h>. - Only the following flags are supported: - 0 - GPIO_ACTIVE_HIGH - 1 - GPIO_ACTIVE_LOW - -Optional properties: -- mediatek,pctl-regmap: Should be a phandle of the syscfg node. -- reg: physicall address base for EINT registers -- interrupt-controller: Marks the device node as an interrupt controller -- #interrupt-cells: Should be two. -- interrupts : The interrupt outputs from the controller. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices. - -Subnode format -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. - - node { - pinmux = <PIN_NUMBER_PINMUX>; - GENERIC_PINCONFIG; - }; - -Required properties: -- pinmux: 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. - -Optional properties: -- GENERIC_PINCONFIG: is the generic pinconfig options to use, bias-disable, - bias-pull-down, bias-pull-up, input-enable, input-disable, output-low, output-high, - input-schmitt-enable, input-schmitt-disable and drive-strength are valid. - - Some special pins have extra pull up strength, there are R0 and R1 pull-up - resistors available, but for user, it's only need to set R1R0 as 00, 01, 10 or 11. - So when config bias-pull-up, it support arguments for those special pins. - Some macros have been defined for this usage, such as MTK_PUPD_SET_R1R0_00. - See dt-bindings/pinctrl/mt65xx.h. - - When config drive-strength, it can support some arguments, such as - MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See dt-bindings/pinctrl/mt65xx.h. - -Examples: - -#include "mt8135-pinfunc.h" - -... -{ - syscfg_pctl_a: syscfg-pctl-a@10005000 { - compatible = "mediatek,mt8135-pctl-a-syscfg", "syscon"; - reg = <0 0x10005000 0 0x1000>; - }; - - syscfg_pctl_b: syscfg-pctl-b@1020c020 { - compatible = "mediatek,mt8135-pctl-b-syscfg", "syscon"; - reg = <0 0x1020C020 0 0x1000>; - }; - - pinctrl@1c20800 { - compatible = "mediatek,mt8135-pinctrl"; - reg = <0 0x1000B000 0 0x1000>; - mediatek,pctl-regmap = <&syscfg_pctl_a>, <&syscfg_pctl_b>; - pins-are-numbered; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; - - i2c0_pins_a: i2c0@0 { - pins1 { - pinmux = <MT8135_PIN_100_SDA0__FUNC_SDA0>, - <MT8135_PIN_101_SCL0__FUNC_SCL0>; - bias-disable; - }; - }; - - i2c1_pins_a: i2c1@0 { - pins { - pinmux = <MT8135_PIN_195_SDA1__FUNC_SDA1>, - <MT8135_PIN_196_SCL1__FUNC_SCL1>; - bias-pull-up = <55>; - }; - }; - - i2c2_pins_a: i2c2@0 { - pins1 { - pinmux = <MT8135_PIN_193_SDA2__FUNC_SDA2>; - bias-pull-down; - }; - - pins2 { - pinmux = <MT8135_PIN_49_WATCHDOG__FUNC_GPIO49>; - bias-pull-up; - }; - }; - - i2c3_pins_a: i2c3@0 { - pins1 { - pinmux = <MT8135_PIN_40_DAC_CLK__FUNC_GPIO40>, - <MT8135_PIN_41_DAC_WS__FUNC_GPIO41>; - bias-pull-up = <55>; - }; - - pins2 { - pinmux = <MT8135_PIN_35_SCL3__FUNC_SCL3>, - <MT8135_PIN_36_SDA3__FUNC_SDA3>; - output-low; - bias-pull-up = <55>; - }; - - pins3 { - pinmux = <MT8135_PIN_57_JTCK__FUNC_GPIO57>, - <MT8135_PIN_60_JTDI__FUNC_JTDI>; - drive-strength = <32>; - }; - }; - - ... - } -}; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt deleted file mode 100644 index bd83401e6179..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt6797.txt +++ /dev/null @@ -1,83 +0,0 @@ -* MediaTek MT6797 Pin Controller - -The MediaTek's MT6797 Pin controller is used to control SoC pins. - -Required properties: -- compatible: Value should be one of the following. - "mediatek,mt6797-pinctrl", compatible with mt6797 pinctrl. -- reg: Should contain address and size for gpio, iocfgl, iocfgb, - iocfgr and iocfgt register bases. -- reg-names: An array of strings describing the "reg" entries. Must - contain "gpio", "iocfgl", "iocfgb", "iocfgr", "iocfgt". -- gpio-controller: Marks the device node as a gpio controller. -- #gpio-cells: Should be two. The first cell is the gpio pin number - and the second cell is used for optional parameters. - -Optional properties: -- interrupt-controller: Marks the device node as an interrupt controller. -- #interrupt-cells: Should be two. -- interrupts : The interrupt outputs from the controller. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices. - -Subnode format -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. - - node { - pinmux = <PIN_NUMBER_PINMUX>; - GENERIC_PINCONFIG; - }; - -Required properties: -- pinmux: 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. - -Optional properties: -- GENERIC_PINCONFIG: is the generic pinconfig options to use, bias-disable, - bias-pull, bias-pull-down, input-enable, input-schmitt-enable, - input-schmitt-disable, output-enable output-low, output-high, - drive-strength, and slew-rate are valid. - - Valid arguments for 'slew-rate' are '0' for no slew rate controlled and - '1' for slower slew rate respectively. Valid arguments for 'drive-strength' - is limited, such as 2, 4, 8, 12, or 16 in mA. - - Some optional vendor properties as defined are valid to specify in a - pinconf subnode: - - mediatek,tdsel: An integer describing the steps for output level shifter - duty cycle when asserted (high pulse width adjustment). Valid arguments - are from 0 to 15. - - mediatek,rdsel: An integer describing the steps for input level shifter - duty cycle when asserted (high pulse width adjustment). Valid arguments - are from 0 to 63. - - mediatek,pull-up-adv: An integer describing the code R1R0 as 0, 1, 2 - or 3 for the advanced pull-up resistors. - - mediatek,pull-down-adv: An integer describing the code R1R0 as 0, 1, 2, - or 3 for the advanced pull-down resistors. - -Examples: - - pio: pinctrl@10005000 { - compatible = "mediatek,mt6797-pinctrl"; - reg = <0 0x10005000 0 0x1000>, - <0 0x10002000 0 0x400>, - <0 0x10002400 0 0x400>, - <0 0x10002800 0 0x400>, - <0 0x10002C00 0 0x400>; - reg-names = "gpio", "iocfgl", "iocfgb", - "iocfgr", "iocfgt"; - gpio-controller; - #gpio-cells = <2>; - - uart1_pins_a: uart1 { - pins1 { - pinmux = <MT6797_GPIO232__FUNC_URXD1>, - <MT6797_GPIO233__FUNC_UTXD1>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt deleted file mode 100644 index 7a7aca1ed705..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt +++ /dev/null @@ -1,490 +0,0 @@ -== MediaTek MT7622 pinctrl controller == - -Required properties for the root node: - - compatible: Should be one of the following - "mediatek,mt7622-pinctrl" for MT7622 SoC - "mediatek,mt7629-pinctrl" for MT7629 SoC - - reg: offset and length of the pinctrl space - - - gpio-controller: Marks the device node as a GPIO controller. - - #gpio-cells: Should be two. The first cell is the pin number and the - second is the GPIO flags. - -Optional properties: -- interrupt-controller : Marks the device node as an interrupt controller - -If the property interrupt-controller is defined, following property is required -- reg-names: A string describing the "reg" entries. Must contain "eint". -- interrupts : The interrupt output from the controller. -- #interrupt-cells: Should be two. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -MT7622 pin configuration nodes act as a container for an arbitrary number of -subnodes. Each of these subnodes represents some desired configuration for a -pin, a group, or a list of pins or groups. This configuration can include the -mux function to select on those pin(s)/group(s), and various pin configuration -parameters, such as pull-up, slew rate, etc. - -We support 2 types of configuration nodes. Those nodes can be either pinmux -nodes or pinconf nodes. Each configuration node can consist of multiple nodes -describing the pinmux and pinconf options. - -The name of each subnode doesn't matter as long as it is unique; all subnodes -should be enumerated and processed purely based on their content. - -== pinmux nodes content == - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pinmux subnode: - -Required properties are: - - groups: An array of strings. Each string contains the name of a group. - Valid values for these names are listed below. - - function: A string containing the name of the function to mux to the - group. Valid values for function names are listed below. - -== pinconf nodes content == - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pinconf subnode: - -Required properties are: - - pins: An array of strings. Each string contains the name of a pin. - Valid values for these names are listed below. - - groups: An array of strings. Each string contains the name of a group. - Valid values for these names are listed below. - -Optional properies are: - bias-disable, bias-pull, bias-pull-down, input-enable, - input-schmitt-enable, input-schmitt-disable, output-enable - output-low, output-high, drive-strength, slew-rate - - Valid arguments for 'slew-rate' are '0' for no slew rate controlled and '1' for - slower slew rate respectively. - Valid arguments for 'drive-strength', 4, 8, 12, or 16 in mA. - -The following specific properties as defined are valid to specify in a pinconf -subnode: - -Optional properties are: - - mediatek,tdsel: An integer describing the steps for output level shifter duty - cycle when asserted (high pulse width adjustment). Valid arguments are from 0 - to 15. - - mediatek,rdsel: An integer describing the steps for input level shifter duty - cycle when asserted (high pulse width adjustment). Valid arguments are from 0 - to 63. - -== Valid values for pins, function and groups on MT7622 == - -Valid values for pins are: -pins can be referenced via the pin names as the below table shown and the -related physical number is also put ahead of those names which helps cross -references to pins between groups to know whether pins assignment conflict -happens among devices try to acquire those available pins. - - Pin #: Valid values for pins - ----------------------------- - PIN 0: "GPIO_A" - PIN 1: "I2S1_IN" - PIN 2: "I2S1_OUT" - PIN 3: "I2S_BCLK" - PIN 4: "I2S_WS" - PIN 5: "I2S_MCLK" - PIN 6: "TXD0" - PIN 7: "RXD0" - PIN 8: "SPI_WP" - PIN 9: "SPI_HOLD" - PIN 10: "SPI_CLK" - PIN 11: "SPI_MOSI" - PIN 12: "SPI_MISO" - PIN 13: "SPI_CS" - PIN 14: "I2C_SDA" - PIN 15: "I2C_SCL" - PIN 16: "I2S2_IN" - PIN 17: "I2S3_IN" - PIN 18: "I2S4_IN" - PIN 19: "I2S2_OUT" - PIN 20: "I2S3_OUT" - PIN 21: "I2S4_OUT" - PIN 22: "GPIO_B" - PIN 23: "MDC" - PIN 24: "MDIO" - PIN 25: "G2_TXD0" - PIN 26: "G2_TXD1" - PIN 27: "G2_TXD2" - PIN 28: "G2_TXD3" - PIN 29: "G2_TXEN" - PIN 30: "G2_TXC" - PIN 31: "G2_RXD0" - PIN 32: "G2_RXD1" - PIN 33: "G2_RXD2" - PIN 34: "G2_RXD3" - PIN 35: "G2_RXDV" - PIN 36: "G2_RXC" - PIN 37: "NCEB" - PIN 38: "NWEB" - PIN 39: "NREB" - PIN 40: "NDL4" - PIN 41: "NDL5" - PIN 42: "NDL6" - PIN 43: "NDL7" - PIN 44: "NRB" - PIN 45: "NCLE" - PIN 46: "NALE" - PIN 47: "NDL0" - PIN 48: "NDL1" - PIN 49: "NDL2" - PIN 50: "NDL3" - PIN 51: "MDI_TP_P0" - PIN 52: "MDI_TN_P0" - PIN 53: "MDI_RP_P0" - PIN 54: "MDI_RN_P0" - PIN 55: "MDI_TP_P1" - PIN 56: "MDI_TN_P1" - PIN 57: "MDI_RP_P1" - PIN 58: "MDI_RN_P1" - PIN 59: "MDI_RP_P2" - PIN 60: "MDI_RN_P2" - PIN 61: "MDI_TP_P2" - PIN 62: "MDI_TN_P2" - PIN 63: "MDI_TP_P3" - PIN 64: "MDI_TN_P3" - PIN 65: "MDI_RP_P3" - PIN 66: "MDI_RN_P3" - PIN 67: "MDI_RP_P4" - PIN 68: "MDI_RN_P4" - PIN 69: "MDI_TP_P4" - PIN 70: "MDI_TN_P4" - PIN 71: "PMIC_SCL" - PIN 72: "PMIC_SDA" - PIN 73: "SPIC1_CLK" - PIN 74: "SPIC1_MOSI" - PIN 75: "SPIC1_MISO" - PIN 76: "SPIC1_CS" - PIN 77: "GPIO_D" - PIN 78: "WATCHDOG" - PIN 79: "RTS3_N" - PIN 80: "CTS3_N" - PIN 81: "TXD3" - PIN 82: "RXD3" - PIN 83: "PERST0_N" - PIN 84: "PERST1_N" - PIN 85: "WLED_N" - PIN 86: "EPHY_LED0_N" - PIN 87: "AUXIN0" - PIN 88: "AUXIN1" - PIN 89: "AUXIN2" - PIN 90: "AUXIN3" - PIN 91: "TXD4" - PIN 92: "RXD4" - PIN 93: "RTS4_N" - PIN 94: "CST4_N" - PIN 95: "PWM1" - PIN 96: "PWM2" - PIN 97: "PWM3" - PIN 98: "PWM4" - PIN 99: "PWM5" - PIN 100: "PWM6" - PIN 101: "PWM7" - PIN 102: "GPIO_E" - -Valid values for function are: - "emmc", "eth", "i2c", "i2s", "ir", "led", "flash", "pcie", - "pmic", "pwm", "sd", "spi", "tdm", "uart", "watchdog" - -Valid values for groups are: -additional data is put followingly with valid value allowing us to know which -applicable function and which relevant pins (in pin#) are able applied for that -group. - - Valid value function pins (in pin#) - ------------------------------------------------------------------------- - "emmc" "emmc" 40, 41, 42, 43, 44, 45, - 47, 48, 49, 50 - "emmc_rst" "emmc" 37 - "esw" "eth" 51, 52, 53, 54, 55, 56, - 57, 58, 59, 60, 61, 62, - 63, 64, 65, 66, 67, 68, - 69, 70 - "esw_p0_p1" "eth" 51, 52, 53, 54, 55, 56, - 57, 58 - "esw_p2_p3_p4" "eth" 59, 60, 61, 62, 63, 64, - 65, 66, 67, 68, 69, 70 - "rgmii_via_esw" "eth" 59, 60, 61, 62, 63, 64, - 65, 66, 67, 68, 69, 70 - "rgmii_via_gmac1" "eth" 59, 60, 61, 62, 63, 64, - 65, 66, 67, 68, 69, 70 - "rgmii_via_gmac2" "eth" 25, 26, 27, 28, 29, 30, - 31, 32, 33, 34, 35, 36 - "mdc_mdio" "eth" 23, 24 - "i2c0" "i2c" 14, 15 - "i2c1_0" "i2c" 55, 56 - "i2c1_1" "i2c" 73, 74 - "i2c1_2" "i2c" 87, 88 - "i2c2_0" "i2c" 57, 58 - "i2c2_1" "i2c" 75, 76 - "i2c2_2" "i2c" 89, 90 - "i2s_in_mclk_bclk_ws" "i2s" 3, 4, 5 - "i2s1_in_data" "i2s" 1 - "i2s2_in_data" "i2s" 16 - "i2s3_in_data" "i2s" 17 - "i2s4_in_data" "i2s" 18 - "i2s_out_mclk_bclk_ws" "i2s" 3, 4, 5 - "i2s1_out_data" "i2s" 2 - "i2s2_out_data" "i2s" 19 - "i2s3_out_data" "i2s" 20 - "i2s4_out_data" "i2s" 21 - "ir_0_tx" "ir" 16 - "ir_1_tx" "ir" 59 - "ir_2_tx" "ir" 99 - "ir_0_rx" "ir" 17 - "ir_1_rx" "ir" 60 - "ir_2_rx" "ir" 100 - "ephy_leds" "led" 86, 91, 92, 93, 94 - "ephy0_led" "led" 86 - "ephy1_led" "led" 91 - "ephy2_led" "led" 92 - "ephy3_led" "led" 93 - "ephy4_led" "led" 94 - "wled" "led" 85 - "par_nand" "flash" 37, 38, 39, 40, 41, 42, - 43, 44, 45, 46, 47, 48, - 49, 50 - "snfi" "flash" 8, 9, 10, 11, 12, 13 - "spi_nor" "flash" 8, 9, 10, 11, 12, 13 - "pcie0_0_waken" "pcie" 14 - "pcie0_1_waken" "pcie" 79 - "pcie1_0_waken" "pcie" 14 - "pcie0_0_clkreq" "pcie" 15 - "pcie0_1_clkreq" "pcie" 80 - "pcie1_0_clkreq" "pcie" 15 - "pcie0_pad_perst" "pcie" 83 - "pcie1_pad_perst" "pcie" 84 - "pmic_bus" "pmic" 71, 72 - "pwm_ch1_0" "pwm" 51 - "pwm_ch1_1" "pwm" 73 - "pwm_ch1_2" "pwm" 95 - "pwm_ch2_0" "pwm" 52 - "pwm_ch2_1" "pwm" 74 - "pwm_ch2_2" "pwm" 96 - "pwm_ch3_0" "pwm" 53 - "pwm_ch3_1" "pwm" 75 - "pwm_ch3_2" "pwm" 97 - "pwm_ch4_0" "pwm" 54 - "pwm_ch4_1" "pwm" 67 - "pwm_ch4_2" "pwm" 76 - "pwm_ch4_3" "pwm" 98 - "pwm_ch5_0" "pwm" 68 - "pwm_ch5_1" "pwm" 77 - "pwm_ch5_2" "pwm" 99 - "pwm_ch6_0" "pwm" 69 - "pwm_ch6_1" "pwm" 78 - "pwm_ch6_2" "pwm" 81 - "pwm_ch6_3" "pwm" 100 - "pwm_ch7_0" "pwm" 70 - "pwm_ch7_1" "pwm" 82 - "pwm_ch7_2" "pwm" 101 - "sd_0" "sd" 16, 17, 18, 19, 20, 21 - "sd_1" "sd" 25, 26, 27, 28, 29, 30 - "spic0_0" "spi" 63, 64, 65, 66 - "spic0_1" "spi" 79, 80, 81, 82 - "spic1_0" "spi" 67, 68, 69, 70 - "spic1_1" "spi" 73, 74, 75, 76 - "spic2_0_wp_hold" "spi" 8, 9 - "spic2_0" "spi" 10, 11, 12, 13 - "tdm_0_out_mclk_bclk_ws" "tdm" 8, 9, 10 - "tdm_0_in_mclk_bclk_ws" "tdm" 11, 12, 13 - "tdm_0_out_data" "tdm" 20 - "tdm_0_in_data" "tdm" 21 - "tdm_1_out_mclk_bclk_ws" "tdm" 57, 58, 59 - "tdm_1_in_mclk_bclk_ws" "tdm" 60, 61, 62 - "tdm_1_out_data" "tdm" 55 - "tdm_1_in_data" "tdm" 56 - "uart0_0_tx_rx" "uart" 6, 7 - "uart1_0_tx_rx" "uart" 55, 56 - "uart1_0_rts_cts" "uart" 57, 58 - "uart1_1_tx_rx" "uart" 73, 74 - "uart1_1_rts_cts" "uart" 75, 76 - "uart2_0_tx_rx" "uart" 3, 4 - "uart2_0_rts_cts" "uart" 1, 2 - "uart2_1_tx_rx" "uart" 51, 52 - "uart2_1_rts_cts" "uart" 53, 54 - "uart2_2_tx_rx" "uart" 59, 60 - "uart2_2_rts_cts" "uart" 61, 62 - "uart2_3_tx_rx" "uart" 95, 96 - "uart3_0_tx_rx" "uart" 57, 58 - "uart3_1_tx_rx" "uart" 81, 82 - "uart3_1_rts_cts" "uart" 79, 80 - "uart4_0_tx_rx" "uart" 61, 62 - "uart4_1_tx_rx" "uart" 91, 92 - "uart4_1_rts_cts" "uart" 93, 94 - "uart4_2_tx_rx" "uart" 97, 98 - "uart4_2_rts_cts" "uart" 95, 96 - "watchdog" "watchdog" 78 - - -== Valid values for pins, function and groups on MT7629 == - - Pin #: Valid values for pins - ----------------------------- - PIN 0: "TOP_5G_CLK" - PIN 1: "TOP_5G_DATA" - PIN 2: "WF0_5G_HB0" - PIN 3: "WF0_5G_HB1" - PIN 4: "WF0_5G_HB2" - PIN 5: "WF0_5G_HB3" - PIN 6: "WF0_5G_HB4" - PIN 7: "WF0_5G_HB5" - PIN 8: "WF0_5G_HB6" - PIN 9: "XO_REQ" - PIN 10: "TOP_RST_N" - PIN 11: "SYS_WATCHDOG" - PIN 12: "EPHY_LED0_N_JTDO" - PIN 13: "EPHY_LED1_N_JTDI" - PIN 14: "EPHY_LED2_N_JTMS" - PIN 15: "EPHY_LED3_N_JTCLK" - PIN 16: "EPHY_LED4_N_JTRST_N" - PIN 17: "WF2G_LED_N" - PIN 18: "WF5G_LED_N" - PIN 19: "I2C_SDA" - PIN 20: "I2C_SCL" - PIN 21: "GPIO_9" - PIN 22: "GPIO_10" - PIN 23: "GPIO_11" - PIN 24: "GPIO_12" - PIN 25: "UART1_TXD" - PIN 26: "UART1_RXD" - PIN 27: "UART1_CTS" - PIN 28: "UART1_RTS" - PIN 29: "UART2_TXD" - PIN 30: "UART2_RXD" - PIN 31: "UART2_CTS" - PIN 32: "UART2_RTS" - PIN 33: "MDI_TP_P1" - PIN 34: "MDI_TN_P1" - PIN 35: "MDI_RP_P1" - PIN 36: "MDI_RN_P1" - PIN 37: "MDI_RP_P2" - PIN 38: "MDI_RN_P2" - PIN 39: "MDI_TP_P2" - PIN 40: "MDI_TN_P2" - PIN 41: "MDI_TP_P3" - PIN 42: "MDI_TN_P3" - PIN 43: "MDI_RP_P3" - PIN 44: "MDI_RN_P3" - PIN 45: "MDI_RP_P4" - PIN 46: "MDI_RN_P4" - PIN 47: "MDI_TP_P4" - PIN 48: "MDI_TN_P4" - PIN 49: "SMI_MDC" - PIN 50: "SMI_MDIO" - PIN 51: "PCIE_PERESET_N" - PIN 52: "PWM_0" - PIN 53: "GPIO_0" - PIN 54: "GPIO_1" - PIN 55: "GPIO_2" - PIN 56: "GPIO_3" - PIN 57: "GPIO_4" - PIN 58: "GPIO_5" - PIN 59: "GPIO_6" - PIN 60: "GPIO_7" - PIN 61: "GPIO_8" - PIN 62: "SPI_CLK" - PIN 63: "SPI_CS" - PIN 64: "SPI_MOSI" - PIN 65: "SPI_MISO" - PIN 66: "SPI_WP" - PIN 67: "SPI_HOLD" - PIN 68: "UART0_TXD" - PIN 69: "UART0_RXD" - PIN 70: "TOP_2G_CLK" - PIN 71: "TOP_2G_DATA" - PIN 72: "WF0_2G_HB0" - PIN 73: "WF0_2G_HB1" - PIN 74: "WF0_2G_HB2" - PIN 75: "WF0_2G_HB3" - PIN 76: "WF0_2G_HB4" - PIN 77: "WF0_2G_HB5" - PIN 78: "WF0_2G_HB6" - -Valid values for function are: - "eth", "i2c", "led", "flash", "pcie", "pwm", "spi", "uart", - "watchdog", "wifi" - -Valid values for groups are: - Valid value function pins (in pin#) - ---------------------------------------------------------------- - "mdc_mdio" "eth" 23, 24 - "i2c_0" "i2c" 19, 20 - "i2c_1" "i2c" 53, 54 - "ephy_leds" "led" 12, 13, 14, 15, 16, - 17, 18 - "ephy0_led" "led" 12 - "ephy1_led" "led" 13 - "ephy2_led" "led" 14 - "ephy3_led" "led" 15 - "ephy4_led" "led" 16 - "wf2g_led" "led" 17 - "wf5g_led" "led" 18 - "snfi" "flash" 62, 63, 64, 65, 66, 67 - "spi_nor" "flash" 62, 63, 64, 65, 66, 67 - "pcie_pereset" "pcie" 51 - "pcie_wake" "pcie" 55 - "pcie_clkreq" "pcie" 56 - "pwm_0" "pwm" 52 - "pwm_1" "pwm" 61 - "spi_0" "spi" 21, 22, 23, 24 - "spi_1" "spi" 62, 63, 64, 65 - "spi_wp" "spi" 66 - "spi_hold" "spi" 67 - "uart0_txd_rxd" "uart" 68, 69 - "uart1_0_txd_rxd" "uart" 25, 26 - "uart1_0_cts_rts" "uart" 27, 28 - "uart1_1_txd_rxd" "uart" 53, 54 - "uart1_1_cts_rts" "uart" 55, 56 - "uart2_0_txd_rxd" "uart" 29, 30 - "uart2_0_cts_rts" "uart" 31, 32 - "uart2_1_txd_rxd" "uart" 57, 58 - "uart2_1_cts_rts" "uart" 59, 60 - "watchdog" "watchdog" 11 - "wf0_2g" "wifi" 70, 71, 72, 73, 74, - 75, 76, 77, 78 - "wf0_5g" "wifi" 0, 1, 2, 3, 4, 5, 6, - 7, 8, 9, 10 - -Example: - - pio: pinctrl@10211000 { - compatible = "mediatek,mt7622-pinctrl"; - reg = <0 0x10211000 0 0x1000>; - gpio-controller; - #gpio-cells = <2>; - - pinctrl_eth_default: eth-default { - mux-mdio { - groups = "mdc_mdio"; - function = "eth"; - drive-strength = <12>; - }; - - mux-gmac2 { - groups = "gmac2"; - function = "eth"; - drive-strength = <12>; - }; - - mux-esw { - groups = "esw"; - function = "eth"; - drive-strength = <8>; - }; - - conf-mdio { - pins = "MDC"; - bias-pull-up; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt deleted file mode 100644 index eccbe3f55d3f..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8183.txt +++ /dev/null @@ -1,132 +0,0 @@ -* Mediatek MT8183 Pin Controller - -The Mediatek's Pin controller is used to control SoC pins. - -Required properties: -- compatible: value should be one of the following. - "mediatek,mt8183-pinctrl", compatible with mt8183 pinctrl. -- gpio-controller : Marks the device node as a gpio controller. -- #gpio-cells: 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 : gpio valid number range. -- reg: physical address base for gpio base registers. There are 10 GPIO - physical address base in mt8183. - -Optional properties: -- reg-names: gpio base register names. There are 10 gpio base register - names in mt8183. They are "iocfg0", "iocfg1", "iocfg2", "iocfg3", "iocfg4", - "iocfg5", "iocfg6", "iocfg7", "iocfg8", "eint". -- interrupt-controller: Marks the device node as an interrupt controller -- #interrupt-cells: Should be two. -- interrupts : The interrupt outputs to sysirq. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices. - -Subnode format -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. - - node { - pinmux = <PIN_NUMBER_PINMUX>; - GENERIC_PINCONFIG; - }; - -Required properties: -- pinmux: 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. - -Optional properties: -- GENERIC_PINCONFIG: is the generic pinconfig options to use, bias-disable, - bias-pull-down, bias-pull-up, input-enable, input-disable, output-low, - output-high, input-schmitt-enable, input-schmitt-disable - and drive-strength are valid. - - Some special pins have extra pull up strength, there are R0 and R1 pull-up - resistors available, but for user, it's only need to set R1R0 as 00, 01, - 10 or 11. So It needs config "mediatek,pull-up-adv" or - "mediatek,pull-down-adv" to support arguments for those special pins. - Valid arguments are from 0 to 3. - - mediatek,tdsel: An integer describing the steps for output level shifter - duty cycle when asserted (high pulse width adjustment). Valid arguments - are from 0 to 15. - mediatek,rdsel: An integer describing the steps for input level shifter - duty cycle when asserted (high pulse width adjustment). Valid arguments - are from 0 to 63. - - When config drive-strength, 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 mt8183. - For I2C pins, there are existing generic driving setup and the specific - driving setup. I2C pins can only support 2/4/6/8/10/12/14/16mA driving - adjustment in generic driving setup. But in specific driving setup, - they can support 0.125/0.25/0.5/1mA adjustment. If we enable specific - driving setup for I2C pins, the existing generic driving setup will be - disabled. For some special features, we need the I2C pins specific - driving setup. The specific driving setup is controlled by E1E0EN. - So we need add extra vendor driving preperty instead of - the generic driving property. - We can add "mediatek,drive-strength-adv = <XXX>;" to describe the specific - driving setup property. "XXX" means the value of E1E0EN. EN is 0 or 1. - It is used to enable or disable the specific driving setup. - E1E0 is used to describe the detail strength specification of the I2C pin. - When E1=0/E0=0, the strength is 0.125mA. - When E1=0/E0=1, the strength is 0.25mA. - When E1=1/E0=0, the strength is 0.5mA. - When E1=1/E0=1, the strength is 1mA. - So the valid arguments of "mediatek,drive-strength-adv" are from 0 to 7. - -Examples: - -#include "mt8183-pinfunc.h" - -... -{ - pio: pinctrl@10005000 { - compatible = "mediatek,mt8183-pinctrl"; - reg = <0 0x10005000 0 0x1000>, - <0 0x11f20000 0 0x1000>, - <0 0x11e80000 0 0x1000>, - <0 0x11e70000 0 0x1000>, - <0 0x11e90000 0 0x1000>, - <0 0x11d30000 0 0x1000>, - <0 0x11d20000 0 0x1000>, - <0 0x11c50000 0 0x1000>, - <0 0x11f30000 0 0x1000>, - <0 0x1000b000 0 0x1000>; - reg-names = "iocfg0", "iocfg1", "iocfg2", - "iocfg3", "iocfg4", "iocfg5", - "iocfg6", "iocfg7", "iocfg8", - "eint"; - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&pio 0 0 192>; - interrupt-controller; - interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; - #interrupt-cells = <2>; - - i2c0_pins_a: i2c0 { - pins1 { - pinmux = <PINMUX_GPIO48__FUNC_SCL5>, - <PINMUX_GPIO49__FUNC_SDA5>; - mediatek,pull-up-adv = <3>; - mediatek,drive-strength-adv = <7>; - }; - }; - - i2c1_pins_a: i2c1 { - pins { - 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-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml index 2f12ec59eee5..e17a399e0904 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml @@ -80,10 +80,7 @@ patternProperties: as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. drive-strength: - description: | - It can support some arguments which is from 0 to 7. It can only support - 2/4/6/8/10/12/14/16mA in mt8195. - enum: [0, 1, 2, 3, 4, 5, 6, 7] + enum: [2, 4, 6, 8, 10, 12, 14, 16] bias-pull-down: true diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml new file mode 100644 index 000000000000..3b02dc6626ed --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,mdm9607-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. MDM9607 TLMM block + +maintainers: + - Konrad Dybcio <konrad.dybcio@somainline.org> + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + MDM9607 platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,mdm9607-tlmm + + reg: + maxItems: 1 + + interrupts: true + interrupt-controller: true + '#interrupt-cells': true + gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': true + gpio-ranges: true + wakeup-parent: true + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-mdm9607-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-mdm9607-tlmm-state" + +'$defs': + qcom-mdm9607-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([1-9]|[1-7][0-9]|80)$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, + sdc2_data, qdsd_cmd, qdsd_data0, qdsd_data1, qdsd_data2, + qdsd_data3 ] + minItems: 1 + maxItems: 16 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ adsp_ext, atest_bbrx0, atest_bbrx1, atest_char, atest_char0, + atest_char1, atest_char2, atest_char3, + atest_combodac_to_gpio_native, atest_gpsadc_dtest0_native, + atest_gpsadc_dtest1_native, atest_tsens, backlight_en_b, + bimc_dte0, bimc_dte1, blsp1_spi, blsp2_spi, blsp3_spi, + blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5, + blsp_i2c6, blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4, + blsp_spi5, blsp_spi6, blsp_uart1, blsp_uart2, blsp_uart3, + blsp_uart4, blsp_uart5, blsp_uart6, blsp_uim1, blsp_uim2, + codec_int, codec_rst, coex_uart, cri_trng, cri_trng0, + cri_trng1, dbg_out, ebi0_wrcdc, ebi2_a, ebi2_a_d_8_b, + ebi2_lcd, ebi2_lcd_cs_n_b, ebi2_lcd_te_b, eth_irq, eth_rst, + gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b, + gcc_gp3_clk_a, gcc_gp3_clk_b, gcc_plltest, gcc_tlmm, gmac_mdio, + gpio, gsm0_tx, lcd_rst, ldo_en, ldo_update, m_voc, modem_tsync, + nav_ptp_pps_in_a, nav_ptp_pps_in_b, nav_tsync_out_a, + nav_tsync_out_b, pa_indicator, pbs0, pbs1, pbs2, + pri_mi2s_data0_a, pri_mi2s_data1_a, pri_mi2s_mclk_a, + pri_mi2s_sck_a, pri_mi2s_ws_a, prng_rosc, ptp_pps_out_a, + ptp_pps_out_b, pwr_crypto_enabled_a, pwr_crypto_enabled_b, + pwr_modem_enabled_a, pwr_modem_enabled_b, pwr_nav_enabled_a, + pwr_nav_enabled_b, 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, rcm_marker1, + rcm_marker2, sd_write, sec_mi2s, sensor_en, sensor_int2, + sensor_int3, sensor_rst, ssbi1, ssbi2, touch_rst, ts_int, + 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 + - function + + additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + tlmm: pinctrl@1000000 { + compatible = "qcom,mdm9607-tlmm"; + reg = <0x01000000 0x300000>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + gpio-ranges = <&msmgpio 0 0 80>; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt deleted file mode 100644 index 161216daf463..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ /dev/null @@ -1,288 +0,0 @@ -Qualcomm PMIC GPIO block - -This binding describes the GPIO block(s) found in the 8xxx series of -PMIC's from Qualcomm. - -- compatible: - Usage: required - Value type: <string> - Definition: must be one of: - "qcom,pm8005-gpio" - "qcom,pm8018-gpio" - "qcom,pm8038-gpio" - "qcom,pm8058-gpio" - "qcom,pm8916-gpio" - "qcom,pm8917-gpio" - "qcom,pm8921-gpio" - "qcom,pm8941-gpio" - "qcom,pm8950-gpio" - "qcom,pm8994-gpio" - "qcom,pm8998-gpio" - "qcom,pma8084-gpio" - "qcom,pmi8950-gpio" - "qcom,pmi8994-gpio" - "qcom,pmi8998-gpio" - "qcom,pms405-gpio" - "qcom,pm660-gpio" - "qcom,pm660l-gpio" - "qcom,pm8150-gpio" - "qcom,pm8150b-gpio" - "qcom,pm8350-gpio" - "qcom,pm8350b-gpio" - "qcom,pm8350c-gpio" - "qcom,pmk8350-gpio" - "qcom,pm7325-gpio" - "qcom,pmr735a-gpio" - "qcom,pmr735b-gpio" - "qcom,pm6150-gpio" - "qcom,pm6150l-gpio" - "qcom,pm8008-gpio" - "qcom,pmx55-gpio" - - And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" - if the device is on an spmi bus or an ssbi bus respectively - -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: Register base of the GPIO block and length. - -- interrupts: - Usage: required - Value type: <prop-encoded-array> - Definition: Must contain an array of encoded interrupt specifiers for - each available GPIO - -- gpio-controller: - Usage: required - Value type: <none> - Definition: Mark the device node as a GPIO controller - -- #gpio-cells: - Usage: required - Value type: <u32> - Definition: Must be 2; - the first cell will be used to define gpio number and the - second denotes the flags for this gpio - -Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for -a general description of GPIO and interrupt bindings. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -The pin configuration nodes act as a container for an arbitrary number of -subnodes. Each of these subnodes represents some desired configuration for a -pin or a list of pins. This configuration can include the -mux function to select on those pin(s), and various pin configuration -parameters, as listed below. - - -SUBNODES: - -The name of each subnode is not important; all subnodes should be enumerated -and processed purely based on their content. - -Each subnode only affects those parameters that are explicitly listed. In -other words, a subnode that lists a mux function but no pin configuration -parameters implies no information about any pin configuration parameters. -Similarly, a pin subnode that describes a pullup parameter implies no -information about e.g. the mux function. - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pin configuration subnode: - -- pins: - Usage: required - Value type: <string-array> - Definition: List of gpio pins affected by the properties specified in - this subnode. Valid pins are: - gpio1-gpio4 for pm8005 - gpio1-gpio6 for pm8018 - gpio1-gpio12 for pm8038 - gpio1-gpio40 for pm8058 - gpio1-gpio4 for pm8916 - gpio1-gpio38 for pm8917 - gpio1-gpio44 for pm8921 - gpio1-gpio36 for pm8941 - gpio1-gpio8 for pm8950 (hole on gpio3) - gpio1-gpio22 for pm8994 - gpio1-gpio26 for pm8998 - gpio1-gpio22 for pma8084 - gpio1-gpio2 for pmi8950 - gpio1-gpio10 for pmi8994 - gpio1-gpio12 for pms405 (holes on gpio1, gpio9 and gpio10) - gpio1-gpio10 for pm8150 (holes on gpio2, gpio5, gpio7 - and gpio8) - gpio1-gpio12 for pm8150b (holes on gpio3, gpio4, gpio7) - gpio1-gpio12 for pm8150l (hole on gpio7) - gpio1-gpio10 for pm8350 - gpio1-gpio8 for pm8350b - gpio1-gpio9 for pm8350c - gpio1-gpio4 for pmk8350 - gpio1-gpio10 for pm7325 - gpio1-gpio4 for pmr735a - gpio1-gpio4 for pmr735b - gpio1-gpio10 for pm6150 - gpio1-gpio12 for pm6150l - gpio1-gpio2 for pm8008 - gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10 - and gpio11) - -- function: - Usage: required - Value type: <string> - Definition: Specify the alternative function to be configured for the - specified pins. Valid values are: - "normal", - "paired", - "func1", - "func2", - "dtest1", - "dtest2", - "dtest3", - "dtest4", - And following values are supported by LV/MV GPIO subtypes: - "func3", - "func4" - -- bias-disable: - Usage: optional - Value type: <none> - Definition: The specified pins should be configured as no pull. - -- bias-pull-down: - Usage: optional - Value type: <none> - Definition: The specified pins should be configured as pull down. - -- bias-pull-up: - Usage: optional - Value type: <empty> - Definition: The specified pins should be configured as pull up. - -- qcom,pull-up-strength: - Usage: optional - Value type: <u32> - Definition: Specifies the strength to use for pull up, if selected. - Valid values are; as defined in - <dt-bindings/pinctrl/qcom,pmic-gpio.h>: - 1: 30uA (PMIC_GPIO_PULL_UP_30) - 2: 1.5uA (PMIC_GPIO_PULL_UP_1P5) - 3: 31.5uA (PMIC_GPIO_PULL_UP_31P5) - 4: 1.5uA + 30uA boost (PMIC_GPIO_PULL_UP_1P5_30) - If this property is omitted 30uA strength will be used if - pull up is selected - -- bias-high-impedance: - Usage: optional - Value type: <none> - Definition: The specified pins will put in high-Z mode and disabled. - -- input-enable: - Usage: optional - Value type: <none> - Definition: The specified pins are put in input mode. - -- output-high: - Usage: optional - Value type: <none> - Definition: The specified pins are configured in output mode, driven - high. - -- output-low: - Usage: optional - Value type: <none> - Definition: The specified pins are configured in output mode, driven - low. - -- power-source: - Usage: optional - Value type: <u32> - Definition: Selects the power source for the specified pins. Valid - power sources are defined per chip in - <dt-bindings/pinctrl/qcom,pmic-gpio.h> - -- qcom,drive-strength: - Usage: optional - Value type: <u32> - Definition: Selects the drive strength for the specified pins. Value - drive strengths are: - 0: no (PMIC_GPIO_STRENGTH_NO) - 1: high (PMIC_GPIO_STRENGTH_HIGH) 0.9mA @ 1.8V - 1.9mA @ 2.6V - 2: medium (PMIC_GPIO_STRENGTH_MED) 0.6mA @ 1.8V - 1.25mA @ 2.6V - 3: low (PMIC_GPIO_STRENGTH_LOW) 0.15mA @ 1.8V - 0.3mA @ 2.6V - as defined in <dt-bindings/pinctrl/qcom,pmic-gpio.h> - -- drive-push-pull: - Usage: optional - Value type: <none> - Definition: The specified pins are configured in push-pull mode. - -- drive-open-drain: - Usage: optional - Value type: <none> - Definition: The specified pins are configured in open-drain mode. - -- drive-open-source: - Usage: optional - Value type: <none> - Definition: The specified pins are configured in open-source mode. - -- qcom,analog-pass: - Usage: optional - Value type: <none> - Definition: The specified pins are configured in analog-pass-through mode. - -- qcom,atest: - Usage: optional - Value type: <u32> - Definition: Selects ATEST rail to route to GPIO when it's configured - in analog-pass-through mode. - Valid values are 1-4 corresponding to ATEST1 to ATEST4. - -- qcom,dtest-buffer: - Usage: optional - Value type: <u32> - Definition: Selects DTEST rail to route to GPIO when it's configured - as digital input. - Valid values are 1-4 corresponding to DTEST1 to DTEST4. - -Example: - - pm8921_gpio: gpio@150 { - compatible = "qcom,pm8921-gpio", "qcom,ssbi-gpio"; - reg = <0x150 0x160>; - interrupts = <192 1>, <193 1>, <194 1>, - <195 1>, <196 1>, <197 1>, - <198 1>, <199 1>, <200 1>, - <201 1>, <202 1>, <203 1>, - <204 1>, <205 1>, <206 1>, - <207 1>, <208 1>, <209 1>, - <210 1>, <211 1>, <212 1>, - <213 1>, <214 1>, <215 1>, - <216 1>, <217 1>, <218 1>, - <219 1>, <220 1>, <221 1>, - <222 1>, <223 1>, <224 1>, - <225 1>, <226 1>, <227 1>, - <228 1>, <229 1>, <230 1>, - <231 1>, <232 1>, <233 1>, - <234 1>, <235 1>; - - gpio-controller; - #gpio-cells = <2>; - - pm8921_gpio_keys: gpio-keys { - volume-keys { - pins = "gpio20", "gpio21"; - function = "normal"; - - input-enable; - bias-pull-up; - drive-push-pull; - qcom,drive-strength = <PMIC_GPIO_STRENGTH_NO>; - power-source = <PM8921_GPIO_S4>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml new file mode 100644 index 000000000000..9bd01db37dcd --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -0,0 +1,239 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,pmic-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm PMIC GPIO block + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + This binding describes the GPIO block(s) found in the 8xxx series of + PMIC's from Qualcomm. + +properties: + compatible: + items: + - enum: + - qcom,pm660-gpio + - qcom,pm660l-gpio + - qcom,pm6150-gpio + - qcom,pm6150l-gpio + - qcom,pm7325-gpio + - qcom,pm8005-gpio + - qcom,pm8008-gpio + - qcom,pm8018-gpio + - qcom,pm8038-gpio + - qcom,pm8058-gpio + - qcom,pm8150-gpio + - qcom,pm8150b-gpio + - qcom,pm8350-gpio + - qcom,pm8350b-gpio + - qcom,pm8350c-gpio + - qcom,pm8916-gpio + - qcom,pm8917-gpio + - qcom,pm8921-gpio + - qcom,pm8941-gpio + - qcom,pm8950-gpio + - qcom,pm8994-gpio + - qcom,pm8998-gpio + - qcom,pma8084-gpio + - qcom,pmi8950-gpio + - qcom,pmi8994-gpio + - qcom,pmi8998-gpio + - qcom,pmk8350-gpio + - qcom,pmr735a-gpio + - qcom,pmr735b-gpio + - qcom,pms405-gpio + - qcom,pmx55-gpio + + - enum: + - qcom,spmi-gpio + - qcom,ssbi-gpio + + reg: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + gpio-controller: true + + gpio-ranges: + maxItems: 1 + + '#gpio-cells': + const: 2 + description: + The first cell will be used to define gpio number and the + second denotes the flags for this gpio + +additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + - interrupt-controller + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-pmic-gpio-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-pmic-gpio-state" + +$defs: + qcom-pmic-gpio-state: + type: object + allOf: + - $ref: "pinmux-node.yaml" + - $ref: "pincfg-node.yaml" + properties: + pins: + description: + List of gpio pins affected by the properties specified in + this subnode. Valid pins are + - gpio1-gpio10 for pm6150 + - gpio1-gpio12 for pm6150l + - gpio1-gpio10 for pm7325 + - gpio1-gpio4 for pm8005 + - gpio1-gpio2 for pm8008 + - gpio1-gpio6 for pm8018 + - gpio1-gpio12 for pm8038 + - gpio1-gpio40 for pm8058 + - gpio1-gpio10 for pm8150 (holes on gpio2, gpio5, + gpio7 and gpio8) + - gpio1-gpio12 for pm8150b (holes on gpio3, gpio4 + and gpio7) + - gpio1-gpio12 for pm8150l (hole on gpio7) + - gpio1-gpio4 for pm8916 + - gpio1-gpio10 for pm8350 + - gpio1-gpio8 for pm8350b + - gpio1-gpio9 for pm8350c + - gpio1-gpio38 for pm8917 + - gpio1-gpio44 for pm8921 + - gpio1-gpio36 for pm8941 + - gpio1-gpio8 for pm8950 (hole on gpio3) + - gpio1-gpio22 for pm8994 + - gpio1-gpio26 for pm8998 + - gpio1-gpio22 for pma8084 + - gpio1-gpio2 for pmi8950 + - gpio1-gpio10 for pmi8994 + - gpio1-gpio4 for pmk8350 + - gpio1-gpio4 for pmr735a + - gpio1-gpio4 for pmr735b + - gpio1-gpio12 for pms405 (holes on gpio1, gpio9 + and gpio10) + - gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10 + and gpio11) + + items: + pattern: "^gpio([0-9]+)$" + + function: + items: + - enum: + - normal + - paired + - func1 + - func2 + - dtest1 + - dtest2 + - dtest3 + - dtest4 + - func3 # supported by LV/MV GPIO subtypes + - func4 # supported by LV/MV GPIO subtypes + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + + qcom,pull-up-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Specifies the strength to use for pull up, if selected. + Valid values are defined in + <dt-bindings/pinctrl/qcom,pmic-gpio.h> + If this property is omitted 30uA strength will be used + if pull up is selected + enum: [0, 1, 2, 3] + + bias-high-impedance: true + input-enable: true + output-high: true + output-low: true + power-source: true + + qcom,drive-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects the drive strength for the specified pins + Valid drive strength values are defined in + <dt-bindings/pinctrl/qcom,pmic-gpio.h> + enum: [0, 1, 2, 3] + + drive-push-pull: true + drive-open-drain: true + drive-open-source: true + + qcom,analog-pass: + $ref: /schemas/types.yaml#/definitions/flag + description: + The specified pins are configured in + analog-pass-through mode. + + qcom,atest: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects ATEST rail to route to GPIO when it's + configured in analog-pass-through mode. + enum: [1, 2, 3, 4] + + qcom,dtest-buffer: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects DTEST rail to route to GPIO when it's + configured as digital input. + enum: [1, 2, 3, 4] + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/qcom,pmic-gpio.h> + + pm8921_gpio: gpio@150 { + compatible = "qcom,pm8921-gpio", "qcom,ssbi-gpio"; + reg = <0x150 0x160>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + gpio-ranges = <&pm8921_gpio 0 0 44>; + #gpio-cells = <2>; + + pm8921_gpio_keys: gpio-keys-state { + volume-keys { + pins = "gpio20", "gpio21"; + function = "normal"; + + input-enable; + bias-pull-up; + drive-push-pull; + qcom,drive-strength = <PMIC_GPIO_STRENGTH_NO>; + power-source = <PM8921_GPIO_S4>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml new file mode 100644 index 000000000000..8fc06f6a3ef4 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml @@ -0,0 +1,179 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm6115-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SM6115, SM4250 TLMM block + +maintainers: + - Iskren Chernev <iskren.chernev@gmail.com> + +description: + This binding describes the Top Level Mode Multiplexer block found in the + SM4250/6115 platforms. + +properties: + compatible: + const: qcom,sm6115-tlmm + + reg: + minItems: 3 + maxItems: 3 + + reg-names: + items: + - const: west + - const: south + - const: east + + interrupts: + description: Specifies the TLMM summary IRQ + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + description: + Specifies the PIN numbers and Flags, as defined in defined in + include/dt-bindings/interrupt-controller/irq.h + const: 2 + + gpio-controller: true + + '#gpio-cells': + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + + wakeup-parent: + maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sm6115-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sm6115-tlmm-state" + +'$defs': + qcom-sm6115-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-2])$" + - 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: [ adsp_ext, agera_pll, atest, cam_mclk, cci_async, cci_i2c, + cci_timer, cri_trng, dac_calib, dbg_out, ddr_bist, ddr_pxi0, + ddr_pxi1, ddr_pxi2, ddr_pxi3, gcc_gp1, gcc_gp2, gcc_gp3, gpio, + gp_pdm0, gp_pdm1, gp_pdm2, gsm0_tx, gsm1_tx, jitter_bist, + mdp_vsync, mdp_vsync_out_0, mdp_vsync_out_1, mpm_pwr, mss_lte, + m_voc, nav_gpio, pa_indicator, pbs, pbs_out, phase_flag, + pll_bist, pll_bypassnl, pll_reset, prng_rosc, qdss_cti, + qdss_gpio, qup0, qup1, qup2, qup3, qup4, qup5, sdc1_tb, + sdc2_tb, sd_write, ssbi_wtr1, tgu, tsense_pwm, uim1_clk, + uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data, + uim2_present, uim2_reset, usb_phy, vfr_1, vsense_trigger, + wlan1_adc0, elan1_adc1 ] + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + + required: + - pins + + additionalProperties: false + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + tlmm: pinctrl@500000 { + compatible = "qcom,sm6115-tlmm"; + reg = <0x500000 0x400000>, + <0x900000 0x400000>, + <0xd00000 0x400000>; + reg-names = "west", "south", "east"; + interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-ranges = <&tlmm 0 0 114>; + + sdc2_on_state: sdc2-on-state { + clk { + pins = "sdc2_clk"; + bias-disable; + drive-strength = <16>; + }; + + cmd { + pins = "sdc2_cmd"; + bias-pull-up; + drive-strength = <10>; + }; + + data { + pins = "sdc2_data"; + bias-pull-up; + drive-strength = <10>; + }; + + sd-cd { + pins = "gpio88"; + function = "gpio"; + bias-pull-up; + drive-strength = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml new file mode 100644 index 000000000000..ef68dabcf4dc --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -0,0 +1,155 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/renesas,rzg2l-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/G2L combined Pin and GPIO controller + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> + +description: + The Renesas SoCs of the RZ/G2L series feature a combined Pin and GPIO + controller. + Pin multiplexing and GPIO configuration is performed on a per-pin basis. + Each port features up to 8 pins, each of them configurable for GPIO function + (port mode) or in alternate function mode. + Up to 8 different alternate function modes exist for each single pin. + +properties: + compatible: + enum: + - renesas,r9a07g044-pinctrl # RZ/G2{L,LC} + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + description: + The first cell contains the global GPIO port index, constructed using the + RZG2L_GPIO() helper macro in <dt-bindings/pinctrl/rzg2l-pinctrl.h> and the + second cell represents consumer flag as mentioned in ../gpio/gpio.txt + E.g. "RZG2L_GPIO(39, 1)" for P39_1. + + gpio-ranges: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + items: + - description: GPIO_RSTN signal + - description: GPIO_PORT_RESETN signal + - description: GPIO_SPARE_RESETN signal + +additionalProperties: + anyOf: + - type: object + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + description: + Pin controller client devices use pin configuration subnodes (children + and grandchildren) for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + phandle: true + pinmux: + description: + Values are constructed from GPIO port number, pin number, and + alternate function configuration number using the RZG2L_PORT_PINMUX() + helper macro in <dt-bindings/pinctrl/rzg2l-pinctrl.h>. + pins: true + drive-strength: + enum: [ 2, 4, 8, 12 ] + power-source: + enum: [ 1800, 2500, 3300 ] + slew-rate: true + gpio-hog: true + gpios: true + input-enable: true + output-high: true + output-low: true + line-name: true + + - type: object + properties: + phandle: true + + additionalProperties: + $ref: "#/additionalProperties/anyOf/0" + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + - clocks + - power-domains + - resets + +examples: + - | + #include <dt-bindings/pinctrl/rzg2l-pinctrl.h> + #include <dt-bindings/clock/r9a07g044-cpg.h> + + pinctrl: pinctrl@11030000 { + compatible = "renesas,r9a07g044-pinctrl"; + reg = <0x11030000 0x10000>; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl 0 0 392>; + clocks = <&cpg CPG_MOD R9A07G044_GPIO_HCLK>; + resets = <&cpg R9A07G044_GPIO_RSTN>, + <&cpg R9A07G044_GPIO_PORT_RESETN>, + <&cpg R9A07G044_GPIO_SPARE_RESETN>; + power-domains = <&cpg>; + + scif0_pins: serial0 { + pinmux = <RZG2L_PORT_PINMUX(38, 0, 1)>, /* Tx */ + <RZG2L_PORT_PINMUX(38, 1, 1)>; /* Rx */ + }; + + i2c1_pins: i2c1 { + pins = "RIIC1_SDA", "RIIC1_SCL"; + input-enable; + }; + + sd1-pwr-en-hog { + gpio-hog; + gpios = <RZG2L_GPIO(39, 2) 0>; + output-high; + line-name = "sd1_pwr_en"; + }; + + sdhi1_pins: sd1 { + sd1_mux { + pinmux = <RZG2L_PORT_PINMUX(19, 0, 1)>, /* CD */ + <RZG2L_PORT_PINMUX(19, 1, 1)>; /* WP */ + power-source = <3300>; + }; + + sd1_data { + pins = "SD1_DATA0", "SD1_DATA1", "SD1_DATA2", "SD1_DATA3"; + power-source = <3300>; + }; + + sd1_ctrl { + pins = "SD1_CLK", "SD1_CMD"; + power-source = <3300>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index 38a1416fd2cd..e7a1b1880375 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -22,6 +22,7 @@ Required Properties: - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller. - "samsung,exynos5433-pinctrl": for Exynos5433 compatible pin-controller. - "samsung,exynos7-pinctrl": for Exynos7 compatible pin-controller. + - "samsung,exynos850-pinctrl": for Exynos850 compatible pin-controller. - reg: Base address of the pin controller hardware module and length of the address space it occupies. diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index 72877544ca78..dfee6d38a701 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -24,6 +24,7 @@ properties: - st,stm32f746-pinctrl - st,stm32f769-pinctrl - st,stm32h743-pinctrl + - st,stm32mp135-pinctrl - st,stm32mp157-pinctrl - st,stm32mp157-z-pinctrl diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt deleted file mode 100644 index f488b0f77406..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt +++ /dev/null @@ -1,105 +0,0 @@ - Binding for Xilinx Zynq Pinctrl - -Required properties: -- compatible: "xlnx,zynq-pinctrl" -- syscon: phandle to SLCR -- reg: Offset and length of pinctrl space in SLCR - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -Zynq's pin configuration nodes act as a container for an arbitrary number of -subnodes. Each of these subnodes represents some desired configuration for a -pin, a group, or a list of pins or groups. This configuration can include the -mux function to select on those pin(s)/group(s), and various pin configuration -parameters, such as pull-up, slew rate, etc. - -Each configuration node can consist of multiple nodes describing the pinmux and -pinconf options. Those nodes can be pinmux nodes or pinconf nodes. - -The name of each subnode is not important; all subnodes should be enumerated -and processed purely based on their content. - -Required properties for pinmux nodes are: - - groups: A list of pinmux groups. - - function: The name of a pinmux function to activate for the specified set - of groups. - -Required properties for configuration nodes: -One of: - - pins: a list of pin names - - groups: A list of pinmux groups. - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pinmux subnode: - groups, function - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pinconf subnode: - groups, pins, bias-disable, bias-high-impedance, bias-pull-up, slew-rate, - low-power-disable, low-power-enable - - Valid arguments for 'slew-rate' are '0' and '1' to select between slow and fast - respectively. - - Valid values for groups are: - ethernet0_0_grp, ethernet1_0_grp, mdio0_0_grp, mdio1_0_grp, - qspi0_0_grp, qspi1_0_grp, qspi_fbclk, qspi_cs1_grp, spi0_0_grp - spi0_2_grp, - spi0_X_ssY (X=0..2, Y=0..2), spi1_0_grp - spi1_3_grp, - spi1_X_ssY (X=0..3, Y=0..2), sdio0_0_grp - sdio0_2_grp, - sdio1_0_grp - sdio1_3_grp, sdio0_emio_wp, sdio0_emio_cd, sdio1_emio_wp, - sdio1_emio_cd, smc0_nor, smc0_nor_cs1_grp, smc0_nor_addr25_grp, smc0_nand, - can0_0_grp - can0_10_grp, can1_0_grp - can1_11_grp, uart0_0_grp - uart0_10_grp, - uart1_0_grp - uart1_11_grp, i2c0_0_grp - i2c0_10_grp, i2c1_0_grp - i2c1_10_grp, - ttc0_0_grp - ttc0_2_grp, ttc1_0_grp - ttc1_2_grp, swdt0_0_grp - swdt0_4_grp, - gpio0_0_grp - gpio0_53_grp, usb0_0_grp, usb1_0_grp - - Valid values for pins are: - MIO0 - MIO53 - - Valid values for function are: - ethernet0, ethernet1, mdio0, mdio1, qspi0, qspi1, qspi_fbclk, qspi_cs1, - spi0, spi0_ss, spi1, spi1_ss, sdio0, sdio0_pc, sdio0_cd, sdio0_wp, - sdio1, sdio1_pc, sdio1_cd, sdio1_wp, - smc0_nor, smc0_nor_cs1, smc0_nor_addr25, smc0_nand, can0, can1, uart0, uart1, - i2c0, i2c1, ttc0, ttc1, swdt0, gpio0, usb0, usb1 - -The following driver-specific properties as defined here are valid to specify in -a pin configuration subnode: - - io-standard: Configure the pin to use the selected IO standard according to - this mapping: - 1: LVCMOS18 - 2: LVCMOS25 - 3: LVCMOS33 - 4: HSTL - -Example: - pinctrl0: pinctrl@700 { - compatible = "xlnx,pinctrl-zynq"; - reg = <0x700 0x200>; - syscon = <&slcr>; - - pinctrl_uart1_default: uart1-default { - mux { - groups = "uart1_10_grp"; - function = "uart1"; - }; - - conf { - groups = "uart1_10_grp"; - slew-rate = <0>; - io-standard = <1>; - }; - - conf-rx { - pins = "MIO49"; - bias-high-impedance; - }; - - conf-tx { - pins = "MIO48"; - bias-disable; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml new file mode 100644 index 000000000000..ac97dbf6998e --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml @@ -0,0 +1,214 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/xlnx,zynq-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq Pinctrl + +maintainers: + - Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com> + +description: | + Please refer to pinctrl-bindings.txt in this directory for details of the + common pinctrl bindings used by client devices, including the meaning of the + phrase "pin configuration node". + + Zynq's pin configuration nodes act as a container for an arbitrary number of + subnodes. Each of these subnodes represents some desired configuration for a + pin, a group, or a list of pins or groups. This configuration can include the + mux function to select on those pin(s)/group(s), and various pin configuration + parameters, such as pull-up, slew rate, etc. + + Each configuration node can consist of multiple nodes describing the pinmux and + pinconf options. Those nodes can be pinmux nodes or pinconf nodes. + + The name of each subnode is not important; all subnodes should be enumerated + and processed purely based on their content. + +properties: + compatible: + const: xlnx,zynq-pinctrl + + reg: + description: Specifies the base address and size of the SLCR space. + maxItems: 1 + + syscon: + description: + phandle to the SLCR. + +patternProperties: + '^(.*-)?(default|gpio)$': + type: object + patternProperties: + '^mux': + type: object + description: + Pinctrl node's client devices use subnodes for pin muxes, + which in turn use below standard properties. + $ref: pinmux-node.yaml# + + properties: + groups: + description: + List of groups to select (either this or "pins" must be + specified), available groups for this subnode. + items: + enum: [ethernet0_0_grp, ethernet1_0_grp, mdio0_0_grp, + mdio1_0_grp, qspi0_0_grp, qspi1_0_grp, qspi_fbclk, + qspi_cs1_grp, spi0_0_grp, spi0_1_grp, spi0_2_grp, + spi0_0_ss0, spi0_0_ss1, spi0_0_ss2, spi0_1_ss0, + spi0_1_ss1, spi0_1_ss2, spi0_2_ss0, spi0_2_ss1, + spi0_2_ss2, spi1_0_grp, spi1_1_grp, spi1_2_grp, + spi1_3_grp, spi1_0_ss0, spi1_0_ss1, spi1_0_ss2, + spi1_1_ss0, spi1_1_ss1, spi1_1_ss2, spi1_2_ss0, + spi1_2_ss1, spi1_2_ss2, spi1_3_ss0, spi1_3_ss1, + spi1_3_ss2, sdio0_0_grp, sdio0_1_grp, sdio0_2_grp, + sdio1_0_grp, sdio1_1_grp, sdio1_2_grp, sdio1_3_grp, + sdio0_emio_wp, sdio0_emio_cd, sdio1_emio_wp, + sdio1_emio_cd, smc0_nor, smc0_nor_cs1_grp, + smc0_nor_addr25_grp, smc0_nand, can0_0_grp, can0_1_grp, + can0_2_grp, can0_3_grp, can0_4_grp, can0_5_grp, + can0_6_grp, can0_7_grp, can0_8_grp, can0_9_grp, + can0_10_grp, can1_0_grp, can1_1_grp, can1_2_grp, + can1_3_grp, can1_4_grp, can1_5_grp, can1_6_grp, + can1_7_grp, can1_8_grp, can1_9_grp, can1_10_grp, + can1_11_grp, uart0_0_grp, uart0_1_grp, uart0_2_grp, + uart0_3_grp, uart0_4_grp, uart0_5_grp, uart0_6_grp, + uart0_7_grp, uart0_8_grp, uart0_9_grp, uart0_10_grp, + uart1_0_grp, uart1_1_grp, uart1_2_grp, uart1_3_grp, + uart1_4_grp, uart1_5_grp, uart1_6_grp, uart1_7_grp, + uart1_8_grp, uart1_9_grp, uart1_10_grp, uart1_11_grp, + i2c0_0_grp, i2c0_1_grp, i2c0_2_grp, i2c0_3_grp, + i2c0_4_grp, i2c0_5_grp, i2c0_6_grp, i2c0_7_grp, + i2c0_8_grp, i2c0_9_grp, i2c0_10_grp, i2c1_0_grp, + i2c1_1_grp, i2c1_2_grp, i2c1_3_grp, i2c1_4_grp, + i2c1_5_grp, i2c1_6_grp, i2c1_7_grp, i2c1_8_grp, + i2c1_9_grp, i2c1_10_grp, ttc0_0_grp, ttc0_1_grp, + ttc0_2_grp, ttc1_0_grp, ttc1_1_grp, ttc1_2_grp, + swdt0_0_grp, swdt0_1_grp, swdt0_2_grp, swdt0_3_grp, + swdt0_4_grp, gpio0_0_grp, gpio0_1_grp, gpio0_2_grp, + gpio0_3_grp, gpio0_4_grp, gpio0_5_grp, gpio0_6_grp, + gpio0_7_grp, gpio0_8_grp, gpio0_9_grp, gpio0_10_grp, + gpio0_11_grp, gpio0_12_grp, gpio0_13_grp, gpio0_14_grp, + gpio0_15_grp, gpio0_16_grp, gpio0_17_grp, gpio0_18_grp, + gpio0_19_grp, gpio0_20_grp, gpio0_21_grp, gpio0_22_grp, + gpio0_23_grp, gpio0_24_grp, gpio0_25_grp, gpio0_26_grp, + gpio0_27_grp, gpio0_28_grp, gpio0_29_grp, gpio0_30_grp, + gpio0_31_grp, gpio0_32_grp, gpio0_33_grp, gpio0_34_grp, + gpio0_35_grp, gpio0_36_grp, gpio0_37_grp, gpio0_38_grp, + gpio0_39_grp, gpio0_40_grp, gpio0_41_grp, gpio0_42_grp, + gpio0_43_grp, gpio0_44_grp, gpio0_45_grp, gpio0_46_grp, + gpio0_47_grp, gpio0_48_grp, gpio0_49_grp, gpio0_50_grp, + gpio0_51_grp, gpio0_52_grp, gpio0_53_grp, usb0_0_grp, + usb1_0_grp] + maxItems: 54 + + function: + description: + Specify the alternative function to be configured for the + given pin groups. + enum: [ethernet0, ethernet1, mdio0, mdio1, qspi0, qspi1, qspi_fbclk, + qspi_cs1, spi0, spi0_ss, spi1, spi1_ss, sdio0, sdio0_pc, + sdio0_cd, sdio0_wp, sdio1, sdio1_pc, sdio1_cd, sdio1_wp, + smc0_nor, smc0_nor_cs1, smc0_nor_addr25, smc0_nand, can0, + can1, uart0, uart1, i2c0, i2c1, ttc0, ttc1, swdt0, gpio0, + usb0, usb1] + + required: + - groups + - function + + additionalProperties: false + + '^conf': + type: object + description: + Pinctrl node's client devices use subnodes for pin configurations, + which in turn use the standard properties below. + $ref: pincfg-node.yaml# + + properties: + groups: + description: + List of pin groups as mentioned above. + + pins: + description: + List of pin names to select in this subnode. + items: + pattern: '^MIO([0-9]|[1-4][0-9]|5[0-3])$' + maxItems: 54 + + bias-pull-up: true + + bias-pull-down: true + + bias-disable: true + + bias-high-impedance: true + + low-power-enable: true + + low-power-disable: true + + slew-rate: + enum: [0, 1] + + power-source: + enum: [1, 2, 3, 4] + + oneOf: + - required: [ groups ] + - required: [ pins ] + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - syscon + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/pinctrl-zynq.h> + pinctrl0: pinctrl@700 { + compatible = "xlnx,zynq-pinctrl"; + reg = <0x700 0x200>; + syscon = <&slcr>; + + pinctrl_uart1_default: uart1-default { + mux { + groups = "uart1_10_grp"; + function = "uart1"; + }; + + conf { + groups = "uart1_10_grp"; + slew-rate = <0>; + power-source = <IO_STANDARD_LVCMOS18>; + }; + + conf-rx { + pins = "MIO49"; + bias-high-impedance; + }; + + conf-tx { + pins = "MIO48"; + bias-disable; + }; + }; + }; + + uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart1_default>; + }; + +... diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index 4807b560f00d..239f37881cae 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -30,6 +30,7 @@ properties: - qcom,sc8180x-rpmhpd - qcom,sdm845-rpmhpd - qcom,sdx55-rpmhpd + - qcom,sm6115-rpmpd - qcom,sm8150-rpmhpd - qcom,sm8250-rpmhpd - qcom,sm8350-rpmhpd diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt deleted file mode 100644 index bb529ecf8a57..000000000000 --- a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.txt +++ /dev/null @@ -1,61 +0,0 @@ --------------------------------------------------------------------- -Device Tree Bindings for the Xilinx Zynq MPSoC Power Management --------------------------------------------------------------------- -The zynqmp-power node describes the power management configurations. -It will control remote suspend/shutdown interfaces. - -Required properties: - - compatible: Must contain: "xlnx,zynqmp-power" - - interrupts: Interrupt specifier - -Optional properties: - - mbox-names : Name given to channels seen in the 'mboxes' property. - "tx" - Mailbox corresponding to transmit path - "rx" - Mailbox corresponding to receive path - - mboxes : Standard property to specify a Mailbox. Each value of - the mboxes property should contain a phandle to the - mailbox controller device node and an args specifier - that will be the phandle to the intended sub-mailbox - child node to be used for communication. See - Documentation/devicetree/bindings/mailbox/mailbox.txt - for more details about the generic mailbox controller - and client driver bindings. Also see - Documentation/devicetree/bindings/mailbox/ \ - xlnx,zynqmp-ipi-mailbox.txt for typical controller that - is used to communicate with this System controllers. - --------- -Examples --------- - -Example with interrupt method: - -firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - - zynqmp_power: zynqmp-power { - compatible = "xlnx,zynqmp-power"; - interrupts = <0 35 4>; - }; - }; -}; - -Example with IPI mailbox method: - -firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - - zynqmp_power: zynqmp-power { - compatible = "xlnx,zynqmp-power"; - interrupt-parent = <&gic>; - interrupts = <0 35 4>; - mboxes = <&ipi_mailbox_pmu0 0>, - <&ipi_mailbox_pmu0 1>; - mbox-names = "tx", "rx"; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml new file mode 100644 index 000000000000..68d7c14a7163 --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/xlnx,zynqmp-power.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq MPSoC Power Management Device Tree Bindings + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +description: | + The zynqmp-power node describes the power management configurations. + It will control remote suspend/shutdown interfaces. + +properties: + compatible: + const: "xlnx,zynqmp-power" + + interrupts: + maxItems: 1 + + mboxes: + description: | + Standard property to specify a Mailbox. Each value of + the mboxes property should contain a phandle to the + mailbox controller device node and an args specifier + that will be the phandle to the intended sub-mailbox + child node to be used for communication. See + Documentation/devicetree/bindings/mailbox/mailbox.txt + for more details about the generic mailbox controller + and client driver bindings. Also see + Documentation/devicetree/bindings/mailbox/ \ + xlnx,zynqmp-ipi-mailbox.txt for typical controller that + is used to communicate with this System controllers. + items: + - description: tx channel + - description: rx channel + + mbox-names: + description: + Name given to channels seen in the 'mboxes' property. + items: + - const: tx + - const: rx + +required: + - compatible + - interrupts + +additionalProperties: false + +examples: + - |+ + + // Example with interrupt method: + + firmware { + zynqmp-firmware { + zynqmp-power { + compatible = "xlnx,zynqmp-power"; + interrupts = <0 35 4>; + }; + }; + }; + + - |+ + + // Example with IPI mailbox method: + + firmware { + zynqmp-firmware { + zynqmp-power { + compatible = "xlnx,zynqmp-power"; + interrupt-parent = <&gic>; + interrupts = <0 35 4>; + mboxes = <&ipi_mailbox_pmu1 0>, + <&ipi_mailbox_pmu1 1>; + mbox-names = "tx", "rx"; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt b/Documentation/devicetree/bindings/power/rockchip-io-domain.txt deleted file mode 100644 index e66fd4eab71c..000000000000 --- a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt +++ /dev/null @@ -1,135 +0,0 @@ -Rockchip SRAM for IO Voltage Domains: -------------------------------------- - -IO domain voltages on some Rockchip SoCs are variable but need to be -kept in sync between the regulators and the SoC using a special -register. - -A specific example using rk3288: -- If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then - bit 7 of GRF_IO_VSEL needs to be 0. If the regulator hooked up to - that same pin is 1.8V then bit 7 of GRF_IO_VSEL needs to be 1. - -Said another way, this driver simply handles keeping bits in the SoC's -general register file (GRF) in sync with the actual value of a voltage -hooked up to the pins. - -Note that this driver specifically doesn't include: -- any logic for deciding what voltage we should set regulators to -- any logic for deciding whether regulators (or internal SoC blocks) - should have power or not have power - -If there were some other software that had the smarts of making -decisions about regulators, it would work in conjunction with this -driver. When that other software adjusted a regulator's voltage then -this driver would handle telling the SoC about it. A good example is -vqmmc for SD. In that case the dw_mmc driver simply is told about a -regulator. It changes the regulator between 3.3V and 1.8V at the -right time. This driver notices the change and makes sure that the -SoC is on the same page. - - -Required properties: -- compatible: should be one of: - - "rockchip,px30-io-voltage-domain" for px30 - - "rockchip,px30-pmu-io-voltage-domain" for px30 pmu-domains - - "rockchip,rk3188-io-voltage-domain" for rk3188 - - "rockchip,rk3228-io-voltage-domain" for rk3228 - - "rockchip,rk3288-io-voltage-domain" for rk3288 - - "rockchip,rk3328-io-voltage-domain" for rk3328 - - "rockchip,rk3368-io-voltage-domain" for rk3368 - - "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains - - "rockchip,rk3399-io-voltage-domain" for rk3399 - - "rockchip,rk3399-pmu-io-voltage-domain" for rk3399 pmu-domains - - "rockchip,rv1108-io-voltage-domain" for rv1108 - - "rockchip,rv1108-pmu-io-voltage-domain" for rv1108 pmu-domains - -Deprecated properties: -- rockchip,grf: phandle to the syscon managing the "general register files" - Systems should move the io-domains to a sub-node of the grf simple-mfd. - -You specify supplies using the standard regulator bindings by including -a phandle the relevant regulator. All specified supplies must be able -to report their voltage. The IO Voltage Domain for any non-specified -supplies will be not be touched. - -Possible supplies for PX30: -- vccio6-supply: The supply connected to VCCIO6. -- vccio1-supply: The supply connected to VCCIO1. -- vccio2-supply: The supply connected to VCCIO2. -- vccio3-supply: The supply connected to VCCIO3. -- vccio4-supply: The supply connected to VCCIO4. -- vccio5-supply: The supply connected to VCCIO5. -- vccio-oscgpi-supply: The supply connected to VCCIO_OSCGPI. - -Possible supplies for PX30 pmu-domains: -- pmuio1-supply: The supply connected to PMUIO1. -- pmuio2-supply: The supply connected to PMUIO2. - -Possible supplies for rk3188: -- ap0-supply: The supply connected to AP0_VCC. -- ap1-supply: The supply connected to AP1_VCC. -- cif-supply: The supply connected to CIF_VCC. -- flash-supply: The supply connected to FLASH_VCC. -- lcdc0-supply: The supply connected to LCD0_VCC. -- lcdc1-supply: The supply connected to LCD1_VCC. -- vccio0-supply: The supply connected to VCCIO0. -- vccio1-supply: The supply connected to VCCIO1. - Sometimes also labeled VCCIO1 and VCCIO2. - -Possible supplies for rk3228: -- vccio1-supply: The supply connected to VCCIO1. -- vccio2-supply: The supply connected to VCCIO2. -- vccio3-supply: The supply connected to VCCIO3. -- vccio4-supply: The supply connected to VCCIO4. - -Possible supplies for rk3288: -- audio-supply: The supply connected to APIO4_VDD. -- bb-supply: The supply connected to APIO5_VDD. -- dvp-supply: The supply connected to DVPIO_VDD. -- flash0-supply: The supply connected to FLASH0_VDD. Typically for eMMC -- flash1-supply: The supply connected to FLASH1_VDD. Also known as SDIO1. -- gpio30-supply: The supply connected to APIO1_VDD. -- gpio1830 The supply connected to APIO2_VDD. -- lcdc-supply: The supply connected to LCDC_VDD. -- sdcard-supply: The supply connected to SDMMC0_VDD. -- wifi-supply: The supply connected to APIO3_VDD. Also known as SDIO0. - -Possible supplies for rk3368: -- audio-supply: The supply connected to APIO3_VDD. -- dvp-supply: The supply connected to DVPIO_VDD. -- flash0-supply: The supply connected to FLASH0_VDD. Typically for eMMC -- gpio30-supply: The supply connected to APIO1_VDD. -- gpio1830 The supply connected to APIO4_VDD. -- sdcard-supply: The supply connected to SDMMC0_VDD. -- wifi-supply: The supply connected to APIO2_VDD. Also known as SDIO0. - -Possible supplies for rk3368 pmu-domains: -- pmu-supply: The supply connected to PMUIO_VDD. -- vop-supply: The supply connected to LCDC_VDD. - -Possible supplies for rk3399: -- bt656-supply: The supply connected to APIO2_VDD. -- audio-supply: The supply connected to APIO5_VDD. -- sdmmc-supply: The supply connected to SDMMC0_VDD. -- gpio1830 The supply connected to APIO4_VDD. - -Possible supplies for rk3399 pmu-domains: -- pmu1830-supply:The supply connected to PMUIO2_VDD. - -Example: - - io-domains { - compatible = "rockchip,rk3288-io-voltage-domain"; - rockchip,grf = <&grf>; - - audio-supply = <&vcc18_codec>; - bb-supply = <&vcc33_io>; - dvp-supply = <&vcc_18>; - flash0-supply = <&vcc18_flashio>; - gpio1830-supply = <&vcc33_io>; - gpio30-supply = <&vcc33_pmuio>; - lcdc-supply = <&vcc33_lcd>; - sdcard-supply = <&vccio_sd>; - wifi-supply = <&vcc18_wl>; - }; diff --git a/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml b/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml new file mode 100644 index 000000000000..1727bf108979 --- /dev/null +++ b/Documentation/devicetree/bindings/power/rockchip-io-domain.yaml @@ -0,0 +1,360 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/rockchip-io-domain.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip SRAM for IO Voltage Domains + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +description: | + IO domain voltages on some Rockchip SoCs are variable but need to be + kept in sync between the regulators and the SoC using a special + register. + + A specific example using rk3288 + If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then + bit 7 of GRF_IO_VSEL needs to be 0. If the regulator hooked up to + that same pin is 1.8V then bit 7 of GRF_IO_VSEL needs to be 1. + + Said another way, this driver simply handles keeping bits in the SoCs + General Register File (GRF) in sync with the actual value of a voltage + hooked up to the pins. + + Note that this driver specifically does not include + any logic for deciding what voltage we should set regulators to + any logic for deciding whether regulators (or internal SoC blocks) + should have power or not have power + + If there were some other software that had the smarts of making + decisions about regulators, it would work in conjunction with this + driver. When that other software adjusted a regulators voltage then + this driver would handle telling the SoC about it. A good example is + vqmmc for SD. In that case the dw_mmc driver simply is told about a + regulator. It changes the regulator between 3.3V and 1.8V at the + right time. This driver notices the change and makes sure that the + SoC is on the same page. + + You specify supplies using the standard regulator bindings by including + a phandle the relevant regulator. All specified supplies must be able + to report their voltage. The IO Voltage Domain for any non-specified + supplies will be not be touched. + +properties: + compatible: + enum: + - rockchip,px30-io-voltage-domain + - rockchip,px30-pmu-io-voltage-domain + - rockchip,rk3188-io-voltage-domain + - rockchip,rk3228-io-voltage-domain + - rockchip,rk3288-io-voltage-domain + - rockchip,rk3328-io-voltage-domain + - rockchip,rk3368-io-voltage-domain + - rockchip,rk3368-pmu-io-voltage-domain + - rockchip,rk3399-io-voltage-domain + - rockchip,rk3399-pmu-io-voltage-domain + - rockchip,rk3568-pmu-io-voltage-domain + - rockchip,rv1108-io-voltage-domain + - rockchip,rv1108-pmu-io-voltage-domain + +required: + - compatible + +unevaluatedProperties: false + +allOf: + - $ref: "#/$defs/px30" + - $ref: "#/$defs/px30-pmu" + - $ref: "#/$defs/rk3188" + - $ref: "#/$defs/rk3228" + - $ref: "#/$defs/rk3288" + - $ref: "#/$defs/rk3328" + - $ref: "#/$defs/rk3368" + - $ref: "#/$defs/rk3368-pmu" + - $ref: "#/$defs/rk3399" + - $ref: "#/$defs/rk3399-pmu" + - $ref: "#/$defs/rk3568-pmu" + - $ref: "#/$defs/rv1108" + - $ref: "#/$defs/rv1108-pmu" + +$defs: + px30: + if: + properties: + compatible: + contains: + const: rockchip,px30-io-voltage-domain + + then: + properties: + vccio1-supply: + description: The supply connected to VCCIO1. + vccio2-supply: + description: The supply connected to VCCIO2. + vccio3-supply: + description: The supply connected to VCCIO3. + vccio4-supply: + description: The supply connected to VCCIO4. + vccio5-supply: + description: The supply connected to VCCIO5. + vccio6-supply: + description: The supply connected to VCCIO6. + vccio-oscgpi-supply: + description: The supply connected to VCCIO_OSCGPI. + + px30-pmu: + if: + properties: + compatible: + contains: + const: rockchip,px30-pmu-io-voltage-domain + + then: + properties: + pmuio1-supply: + description: The supply connected to PMUIO1. + pmuio2-supply: + description: The supply connected to PMUIO2. + + rk3188: + if: + properties: + compatible: + contains: + const: rockchip,rk3188-io-voltage-domain + + then: + properties: + ap0-supply: + description: The supply connected to AP0_VCC. + ap1-supply: + description: The supply connected to AP1_VCC. + cif-supply: + description: The supply connected to CIF_VCC. + flash-supply: + description: The supply connected to FLASH_VCC. + lcdc0-supply: + description: The supply connected to LCD0_VCC. + lcdc1-supply: + description: The supply connected to LCD1_VCC. + vccio0-supply: + description: The supply connected to VCCIO0. + vccio1-supply: + description: The supply connected to VCCIO1. Also labeled as VCCIO2. + + rk3228: + if: + properties: + compatible: + contains: + const: rockchip,rk3228-io-voltage-domain + + then: + properties: + vccio1-supply: + description: The supply connected to VCCIO1. + vccio2-supply: + description: The supply connected to VCCIO2. + vccio3-supply: + description: The supply connected to VCCIO3. + vccio4-supply: + description: The supply connected to VCCIO4. + + rk3288: + if: + properties: + compatible: + contains: + const: rockchip,rk3288-io-voltage-domain + + then: + properties: + audio-supply: + description: The supply connected to APIO4_VDD. + bb-supply: + description: The supply connected to APIO5_VDD. + dvp-supply: + description: The supply connected to DVPIO_VDD. + flash0-supply: + description: The supply connected to FLASH0_VDD. Typically for eMMC. + flash1-supply: + description: The supply connected to FLASH1_VDD. Also known as SDIO1. + gpio30-supply: + description: The supply connected to APIO1_VDD. + gpio1830-supply: + description: The supply connected to APIO2_VDD. + lcdc-supply: + description: The supply connected to LCDC_VDD. + sdcard-supply: + description: The supply connected to SDMMC0_VDD. + wifi-supply: + description: The supply connected to APIO3_VDD. Also known as SDIO0. + + rk3328: + if: + properties: + compatible: + contains: + const: rockchip,rk3328-io-voltage-domain + + then: + properties: + vccio1-supply: + description: The supply connected to VCCIO1. + vccio2-supply: + description: The supply connected to VCCIO2. + vccio3-supply: + description: The supply connected to VCCIO3. + vccio4-supply: + description: The supply connected to VCCIO4. + vccio5-supply: + description: The supply connected to VCCIO5. + vccio6-supply: + description: The supply connected to VCCIO6. + pmuio-supply: + description: The supply connected to VCCIO_PMU. + + rk3368: + if: + properties: + compatible: + contains: + const: rockchip,rk3368-io-voltage-domain + + then: + properties: + audio-supply: + description: The supply connected to APIO3_VDD. + dvp-supply: + description: The supply connected to DVPIO_VDD. + flash0-supply: + description: The supply connected to FLASH0_VDD. Typically for eMMC. + gpio30-supply: + description: The supply connected to APIO1_VDD. + gpio1830-supply: + description: The supply connected to APIO4_VDD. + sdcard-supply: + description: The supply connected to SDMMC0_VDD. + wifi-supply: + description: The supply connected to APIO2_VDD. Also known as SDIO0. + + rk3368-pmu: + if: + properties: + compatible: + contains: + const: rockchip,rk3368-pmu-io-voltage-domain + + then: + properties: + pmu-supply: + description: The supply connected to PMUIO_VDD. + vop-supply: + description: The supply connected to LCDC_VDD. + + rk3399: + if: + properties: + compatible: + contains: + const: rockchip,rk3399-io-voltage-domain + + then: + properties: + audio-supply: + description: The supply connected to APIO5_VDD. + bt656-supply: + description: The supply connected to APIO2_VDD. + gpio1830-supply: + description: The supply connected to APIO4_VDD. + sdmmc-supply: + description: The supply connected to SDMMC0_VDD. + + rk3399-pmu: + if: + properties: + compatible: + contains: + const: rockchip,rk3399-pmu-io-voltage-domain + + then: + properties: + pmu1830-supply: + description: The supply connected to PMUIO2_VDD. + + rk3568-pmu: + if: + properties: + compatible: + contains: + const: rockchip,rk3568-pmu-io-voltage-domain + + then: + properties: + pmuio1-supply: + description: The supply connected to PMUIO1. + pmuio2-supply: + description: The supply connected to PMUIO2. + vccio1-supply: + description: The supply connected to VCCIO1. + vccio2-supply: + description: The supply connected to VCCIO2. + vccio3-supply: + description: The supply connected to VCCIO3. + vccio4-supply: + description: The supply connected to VCCIO4. + vccio5-supply: + description: The supply connected to VCCIO5. + vccio6-supply: + description: The supply connected to VCCIO6. + vccio7-supply: + description: The supply connected to VCCIO7. + + rv1108: + if: + properties: + compatible: + contains: + const: rockchip,rv1108-io-voltage-domain + + then: + properties: + vccio1-supply: + description: The supply connected to APIO1_VDD. + vccio2-supply: + description: The supply connected to APIO2_VDD. + vccio3-supply: + description: The supply connected to APIO3_VDD. + vccio5-supply: + description: The supply connected to APIO5_VDD. + vccio6-supply: + description: The supply connected to APIO6_VDD. + + rv1108-pmu: + if: + properties: + compatible: + contains: + const: rockchip,rv1108-pmu-io-voltage-domain + + then: + properties: + pmu-supply: + description: The supply connected to PMUIO_VDD. + +examples: + - | + io-domains { + compatible = "rockchip,rk3288-io-voltage-domain"; + audio-supply = <&vcc18_codec>; + bb-supply = <&vcc33_io>; + dvp-supply = <&vcc_18>; + flash0-supply = <&vcc18_flashio>; + gpio1830-supply = <&vcc33_io>; + gpio30-supply = <&vcc33_pmuio>; + lcdc-supply = <&vcc33_lcd>; + sdcard-supply = <&vccio_sd>; + wifi-supply = <&vcc18_wl>; + }; diff --git a/Documentation/devicetree/bindings/power/supply/battery.yaml b/Documentation/devicetree/bindings/power/supply/battery.yaml index c3b4b7543591..d56ac484fec5 100644 --- a/Documentation/devicetree/bindings/power/supply/battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/battery.yaml @@ -31,6 +31,20 @@ properties: compatible: const: simple-battery + device-chemistry: + description: This describes the chemical technology of the battery. + oneOf: + - const: nickel-cadmium + - const: nickel-metal-hydride + - const: lithium-ion + description: This is a blanket type for all lithium-ion batteries, + including those below. If possible, a precise compatible string + from below should be used, but sometimes it is unknown which specific + lithium ion battery is employed and this wide compatible can be used. + - const: lithium-ion-polymer + - const: lithium-ion-iron-phosphate + - const: lithium-ion-manganese-oxide + over-voltage-threshold-microvolt: description: battery over-voltage limit diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml index c70f05ea6d27..971b53c58cc6 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml @@ -19,12 +19,15 @@ properties: - maxim,max17047 - maxim,max17050 - maxim,max17055 + - maxim,max77849-battery reg: maxItems: 1 interrupts: maxItems: 1 + description: | + The ALRT pin, an open-drain interrupt. maxim,rsns-microohm: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml b/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml new file mode 100644 index 000000000000..b89b15a5bfa4 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/mt6360_charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Battery charger driver for MT6360 PMIC from MediaTek Integrated. + +maintainers: + - Gene Chen <gene_chen@richtek.com> + +description: | + This module is part of the MT6360 MFD device. + Provides Battery Charger, Boost for OTG devices and BC1.2 detection. + +properties: + compatible: + const: mediatek,mt6360-chg + + richtek,vinovp-microvolt: + description: Maximum CHGIN regulation voltage in uV. + enum: [ 5500000, 6500000, 11000000, 14500000 ] + + + usb-otg-vbus-regulator: + type: object + description: OTG boost regulator. + $ref: /schemas/regulator/regulator.yaml# + +required: + - compatible + +additionalProperties: false + +examples: + - | + mt6360_charger: charger { + compatible = "mediatek,mt6360-chg"; + richtek,vinovp-microvolt = <14500000>; + + otg_vbus_regulator: usb-otg-vbus-regulator { + regulator-compatible = "usb-otg-vbus"; + regulator-name = "usb-otg-vbus"; + regulator-min-microvolt = <4425000>; + regulator-max-microvolt = <5825000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml b/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml index 983fc215c1e5..20862cdfc116 100644 --- a/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/summit,smb347-charger.yaml @@ -73,6 +73,26 @@ properties: - 1 # SMB3XX_SOFT_TEMP_COMPENSATE_CURRENT Current compensation - 2 # SMB3XX_SOFT_TEMP_COMPENSATE_VOLTAGE Voltage compensation + summit,inok-polarity: + description: | + Polarity of INOK signal indicating presence of external power supply. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # SMB3XX_SYSOK_INOK_ACTIVE_LOW + - 1 # SMB3XX_SYSOK_INOK_ACTIVE_HIGH + + usb-vbus: + $ref: "../../regulator/regulator.yaml#" + type: object + + properties: + summit,needs-inok-toggle: + type: boolean + description: INOK signal is fixed and polarity needs to be toggled + in order to enable/disable output mode. + + unevaluatedProperties: false + allOf: - if: properties: @@ -134,6 +154,7 @@ examples: reg = <0x7f>; summit,enable-charge-control = <SMB3XX_CHG_ENABLE_PIN_ACTIVE_HIGH>; + summit,inok-polarity = <SMB3XX_SYSOK_INOK_ACTIVE_LOW>; summit,chip-temperature-threshold-celsius = <110>; summit,mains-current-limit-microamp = <2000000>; summit,usb-current-limit-microamp = <500000>; @@ -141,6 +162,15 @@ examples: summit,enable-mains-charging; monitored-battery = <&battery>; + + usb-vbus { + regulator-name = "usb_vbus"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + regulator-min-microamp = <750000>; + regulator-max-microamp = <750000>; + summit,needs-inok-toggle; + }; }; }; diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml index dcda6660b8ed..de6a23aee977 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-ac-power-supply.yaml @@ -21,10 +21,13 @@ allOf: properties: compatible: - enum: - - x-powers,axp202-ac-power-supply - - x-powers,axp221-ac-power-supply - - x-powers,axp813-ac-power-supply + oneOf: + - const: x-powers,axp202-ac-power-supply + - const: x-powers,axp221-ac-power-supply + - items: + - const: x-powers,axp803-ac-power-supply + - const: x-powers,axp813-ac-power-supply + - const: x-powers,axp813-ac-power-supply required: - compatible diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml index 86e8a713d4e2..d055428ae39f 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml @@ -19,10 +19,14 @@ allOf: properties: compatible: - enum: - - x-powers,axp209-battery-power-supply - - x-powers,axp221-battery-power-supply - - x-powers,axp813-battery-power-supply + oneOf: + - const: x-powers,axp202-battery-power-supply + - const: x-powers,axp209-battery-power-supply + - const: x-powers,axp221-battery-power-supply + - items: + - const: x-powers,axp803-battery-power-supply + - const: x-powers,axp813-battery-power-supply + - const: x-powers,axp813-battery-power-supply required: - compatible diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml index 61f1b320c157..0c371b55c9e1 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-usb-power-supply.yaml @@ -20,11 +20,15 @@ allOf: properties: compatible: - enum: - - x-powers,axp202-usb-power-supply - - x-powers,axp221-usb-power-supply - - x-powers,axp223-usb-power-supply - - x-powers,axp813-usb-power-supply + oneOf: + - enum: + - x-powers,axp202-usb-power-supply + - x-powers,axp221-usb-power-supply + - x-powers,axp223-usb-power-supply + - x-powers,axp813-usb-power-supply + - items: + - const: x-powers,axp803-usb-power-supply + - const: x-powers,axp813-usb-power-supply required: diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml index 8850c01bd470..9b131c6facbc 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml @@ -57,12 +57,14 @@ properties: maxItems: 1 power-domains: + deprecated: true description: Power domain to use for enable control. This binding is only available if the compatible is chosen to regulator-fixed-domain. maxItems: 1 required-opps: + deprecated: true description: Performance state to use for enable control. This binding is only available if the compatible is chosen to regulator-fixed-domain. The diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml index 12b8963615c3..c2e8c54e5311 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml @@ -36,12 +36,12 @@ properties: switching frequency must be one of following corresponding value 1.1MHz, 1.65MHz, 2.2MHz, 2.75MHz - patternProperties: - "^ldo[1-4]$": + ldortc: type: object $ref: regulator.yaml# - "^ldortc$": + patternProperties: + "^ldo[1-4]$": type: object $ref: regulator.yaml# diff --git a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml index 8761437ed8ad..aabf50f5b39e 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml @@ -83,7 +83,8 @@ properties: unevaluatedProperties: false - "^vsnvs$": + properties: + vsnvs: type: object $ref: regulator.yaml# description: diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml index 796ceac87445..e983d0e70c9b 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml @@ -77,7 +77,6 @@ examples: rt6245@34 { compatible = "richtek,rt6245"; - status = "okay"; reg = <0x34>; enable-gpios = <&gpio26 2 0>; diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2134-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2134-regulator.yaml new file mode 100644 index 000000000000..3f47e8e6c4fd --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2134-regulator.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rtq2134-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RTQ2134 SubPMIC Regulator + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + The RTQ2134 is a multi-phase, programmable power management IC that + integrates with four high efficient, synchronous step-down converter cores. + + Datasheet is available at + https://www.richtek.com/assets/product_file/RTQ2134-QA/DSQ2134-QA-01.pdf + +properties: + compatible: + enum: + - richtek,rtq2134 + + reg: + maxItems: 1 + + regulators: + type: object + + patternProperties: + "^buck[1-3]$": + type: object + $ref: regulator.yaml# + description: | + regulator description for buck[1-3]. + + properties: + richtek,use-vsel-dvs: + type: boolean + description: | + If specified, buck will listen to 'vsel' pin for dvs config. + Else, use dvs0 voltage by default. + + richtek,uv-shutdown: + type: boolean + description: | + If specified, use shutdown as UV action. Else, hiccup by default. + + unevaluatedProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtq2134@18 { + compatible = "richtek,rtq2134"; + reg = <0x18>; + + regulators { + buck1 { + regulator-name = "rtq2134-buck1"; + regulator-min-microvolt = <300000>; + regulator-max-microvolt = <1850000>; + regulator-always-on; + richtek,use-vsel-dvs; + regulator-state-mem { + regulator-suspend-min-microvolt = <550000>; + regulator-suspend-max-microvolt = <550000>; + }; + }; + buck2 { + regulator-name = "rtq2134-buck2"; + regulator-min-microvolt = <1120000>; + regulator-max-microvolt = <1120000>; + regulator-always-on; + richtek,use-vsel-dvs; + regulator-state-mem { + regulator-suspend-min-microvolt = <1120000>; + regulator-suspend-max-microvolt = <1120000>; + }; + }; + buck3 { + regulator-name = "rtq2134-buck3"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <600000>; + regulator-always-on; + richtek,use-vsel-dvs; + regulator-state-mem { + regulator-suspend-min-microvolt = <600000>; + regulator-suspend-max-microvolt = <600000>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml new file mode 100644 index 000000000000..e6e5a9a7d940 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq6752-regulator.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rtq6752-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RTQ6752 TFT LCD Voltage Regulator + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + The RTQ6752 is an I2C interface pgorammable power management IC. It includes + two synchronous boost converter for PAVDD, and one synchronous NAVDD + buck-boost. The device is suitable for automotive TFT-LCD panel. + +properties: + compatible: + enum: + - richtek,rtq6752 + + reg: + maxItems: 1 + + enable-gpios: + description: | + A connection of the chip 'enable' gpio line. If not provided, treat it as + external pull up. + maxItems: 1 + + regulators: + type: object + + patternProperties: + "^(p|n)avdd$": + type: object + $ref: regulator.yaml# + description: | + regulator description for pavdd and navdd. + + additionalProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtq6752@6b { + compatible = "richtek,rtq6752"; + reg = <0x6b>; + enable-gpios = <&gpio26 2 0>; + + regulators { + pavdd { + regulator-name = "rtq6752-pavdd"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <7300000>; + regulator-boot-on; + }; + navdd { + regulator-name = "rtq6752-navdd"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <7300000>; + regulator-boot-on; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml new file mode 100644 index 000000000000..861d5f3c79e8 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/socionext,uniphier-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier regulator controller + +description: | + This regulator controls VBUS and belongs to USB3 glue layer. Before using + the regulator, it is necessary to control the clocks and resets to enable + this layer. These clocks and resets should be described in each property. + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +allOf: + - $ref: "regulator.yaml#" + +# USB3 Controller + +properties: + compatible: + enum: + - socionext,uniphier-pro4-usb3-regulator + - socionext,uniphier-pro5-usb3-regulator + - socionext,uniphier-pxs2-usb3-regulator + - socionext,uniphier-ld20-usb3-regulator + - socionext,uniphier-pxs3-usb3-regulator + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + oneOf: + - items: # for Pro4, Pro5 + - const: gio + - const: link + - items: # for others + - const: link + + resets: + minItems: 1 + maxItems: 2 + + reset-names: + oneOf: + - items: # for Pro4, Pro5 + - const: gio + - const: link + - items: + - const: link + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + +examples: + - | + usb-glue@65b00000 { + compatible = "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x65b00000 0x400>; + + usb_vbus0: regulators@100 { + compatible = "socionext,uniphier-ld20-usb3-regulator"; + reg = <0x100 0x10>; + clock-names = "link"; + clocks = <&sys_clk 14>; + reset-names = "link"; + resets = <&sys_rst 14>; + }; + }; + diff --git a/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt b/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt deleted file mode 100644 index 94fd38b0d163..000000000000 --- a/Documentation/devicetree/bindings/regulator/uniphier-regulator.txt +++ /dev/null @@ -1,58 +0,0 @@ -Socionext UniPhier Regulator Controller - -This describes the devicetree bindings for regulator controller implemented -on Socionext UniPhier SoCs. - -USB3 Controller ---------------- - -This regulator controls VBUS and belongs to USB3 glue layer. Before using -the regulator, it is necessary to control the clocks and resets to enable -this layer. These clocks and resets should be described in each property. - -Required properties: -- compatible: Should be - "socionext,uniphier-pro4-usb3-regulator" - for Pro4 SoC - "socionext,uniphier-pro5-usb3-regulator" - for Pro5 SoC - "socionext,uniphier-pxs2-usb3-regulator" - for PXs2 SoC - "socionext,uniphier-ld20-usb3-regulator" - for LD20 SoC - "socionext,uniphier-pxs3-usb3-regulator" - for PXs3 SoC -- reg: Specifies offset and length of the register set for the device. -- clocks: A list of phandles to the clock gate for USB3 glue layer. - According to the clock-names, appropriate clocks are required. -- clock-names: Should contain - "gio", "link" - for Pro4 and Pro5 SoCs - "link" - for others -- resets: A list of phandles to the reset control for USB3 glue layer. - According to the reset-names, appropriate resets are required. -- reset-names: Should contain - "gio", "link" - for Pro4 and Pro5 SoCs - "link" - for others - -See Documentation/devicetree/bindings/regulator/regulator.txt -for more details about the regulator properties. - -Example: - - usb-glue@65b00000 { - compatible = "socionext,uniphier-ld20-dwc3-glue", - "simple-mfd"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x65b00000 0x400>; - - usb_vbus0: regulators@100 { - compatible = "socionext,uniphier-ld20-usb3-regulator"; - reg = <0x100 0x10>; - clock-names = "link"; - clocks = <&sys_clk 14>; - reset-names = "link"; - resets = <&sys_rst 14>; - }; - - phy { - ... - phy-supply = <&usb_vbus0>; - }; - ... - }; diff --git a/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml b/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml index 6f45582c914e..dd7a2f92634c 100644 --- a/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml @@ -39,6 +39,5 @@ examples: regulator-min-microvolt = <1500000>; regulator-max-microvolt = <3000000>; regulator-always-on; - status = "disabled"; }; ... diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index c597ccced623..0c112f3264a9 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -28,6 +28,7 @@ properties: - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas - qcom,sc8180x-mpss-pas + - qcom,sdm660-adsp-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas - qcom,sdx55-mpss-pas diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt index e8d3096d922c..39b5f4c5a511 100644 --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt @@ -51,6 +51,23 @@ compatible (optional) - standard definition used as a shared pool of DMA buffers for a set of devices. It can be used by an operating system to instantiate the necessary pool management subsystem if necessary. + - restricted-dma-pool: This indicates a region of memory meant to be + used as a pool of restricted DMA buffers for a set of devices. The + memory region would be the only region accessible to those devices. + When using this, the no-map and reusable properties must not be set, + so the operating system can create a virtual mapping that will be used + for synchronization. The main purpose for restricted DMA is to + mitigate the lack of DMA access control on systems without an IOMMU, + which could result in the DMA accessing the system memory at + unexpected times and/or unexpected addresses, possibly leading to data + leakage or corruption. The feature on its own provides a basic level + of protection against the DMA overwriting buffer contents at + unexpected times. However, to protect against general data leakage and + system memory corruption, the system needs to provide way to lock down + the memory access, e.g., MPU. Note that since coherent allocation + needs remapping, one must set up another device coherent pool by + shared-dma-pool and use dma_alloc_from_dev_coherent instead for atomic + coherent allocation. - vendor specific string in the form <vendor>,[<device>-]<usage> no-map (optional) - empty property - Indicates the operating system must not create a virtual mapping @@ -85,10 +102,11 @@ memory-region-names (optional) - a list of names, one for each corresponding Example ------- -This example defines 3 contiguous regions are defined for Linux kernel: +This example defines 4 contiguous regions for Linux kernel: one default of all device drivers (named linux,cma@72000000 and 64MiB in size), -one dedicated to the framebuffer device (named framebuffer@78000000, 8MiB), and -one for multimedia processing (named multimedia-memory@77000000, 64MiB). +one dedicated to the framebuffer device (named framebuffer@78000000, 8MiB), +one for multimedia processing (named multimedia-memory@77000000, 64MiB), and +one for restricted dma pool (named restricted_dma_reserved@0x50000000, 64MiB). / { #address-cells = <1>; @@ -120,6 +138,11 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB). compatible = "acme,multimedia-memory"; reg = <0x77000000 0x4000000>; }; + + restricted_dma_reserved: restricted_dma_reserved { + compatible = "restricted-dma-pool"; + reg = <0x50000000 0x4000000>; + }; }; /* ... */ @@ -138,4 +161,11 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB). memory-region = <&multimedia_reserved>; /* ... */ }; + + pcie_device: pcie_device@0,0 { + reg = <0x83010000 0x0 0x00000000 0x0 0x00100000 + 0x83010000 0x0 0x00100000 0x0 0x00100000>; + memory-region = <&restricted_dma_reserved>; + /* ... */ + }; }; diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml index 9bf40952e5b7..b0c41ab1a746 100644 --- a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.yaml @@ -72,6 +72,5 @@ examples: resets = <&iomcu_rst 0x20 3>; pinctrl-names = "default"; pinctrl-0 = <&i2c0_pmx_func &i2c0_cfg_func>; - status = "disabled"; }; ... diff --git a/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml b/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml index 6b2d56cc3f38..13bf6bb3f097 100644 --- a/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml +++ b/Documentation/devicetree/bindings/reset/intel,rcu-gw.yaml @@ -57,7 +57,6 @@ examples: }; pwm: pwm@e0d00000 { - status = "disabled"; compatible = "intel,lgm-pwm"; reg = <0xe0d00000 0x30>; clocks = <&cgu0 1>; diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml index e2d85a1e1d63..a054757f4d9f 100644 --- a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml +++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml @@ -21,6 +21,11 @@ properties: - const: "qcom,sc7180-aoss-cc" - const: "qcom,sdm845-aoss-cc" + - description: on SC7280 SoCs the following compatibles must be specified + items: + - const: "qcom,sc7280-aoss-cc" + - const: "qcom,sdm845-aoss-cc" + - description: on SDM845 SoCs the following compatibles must be specified items: - const: "qcom,sdm845-aoss-cc" diff --git a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml index d7d8cec9419f..831ea8d5d83f 100644 --- a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml +++ b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml @@ -21,6 +21,10 @@ properties: - const: "qcom,sc7180-pdc-global" - const: "qcom,sdm845-pdc-global" + - description: on SC7280 SoCs the following compatibles must be specified + items: + - const: "qcom,sc7280-pdc-global" + - description: on SDM845 SoCs the following compatibles must be specified items: - const: "qcom,sdm845-pdc-global" diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml new file mode 100644 index 000000000000..b13514e6783d --- /dev/null +++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/renesas,rzg2l-usbphy-ctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/G2L USBPHY Control + +maintainers: + - Biju Das <biju.das.jz@bp.renesas.com> + +description: + The RZ/G2L USBPHY Control mainly controls reset and power down of the + USB/PHY. + +properties: + compatible: + items: + - enum: + - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC} + - const: renesas,rzg2l-usbphy-ctrl + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + power-domains: + maxItems: 1 + + '#reset-cells': + const: 1 + description: | + The phandle's argument in the reset specifier is the PHY reset associated + with the USB port. + 0 = Port 1 Phy reset + 1 = Port 2 Phy reset + +required: + - compatible + - reg + - clocks + - resets + - power-domains + - '#reset-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r9a07g044-cpg.h> + + phyrst: usbphy-ctrl@11c40000 { + compatible = "renesas,r9a07g044-usbphy-ctrl", + "renesas,rzg2l-usbphy-ctrl"; + reg = <0x11c40000 0x10000>; + clocks = <&cpg CPG_MOD R9A07G044_USB_PCLK>; + resets = <&cpg R9A07G044_USB_PRESETN>; + power-domains = <&cpg>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml new file mode 100644 index 000000000000..29e4a900cad7 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-glue-reset.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/socionext,uniphier-glue-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier peripheral core reset in glue layer + +description: | + Some peripheral core reset belongs to its own glue layer. Before using + this core reset, it is necessary to control the clocks and resets to + enable this layer. These clocks and resets should be described in each + property. + +maintainers: + - Kunihiko Hayashi <hayashi.kunihiko@socionext.com> + +properties: + compatible: + enum: + - socionext,uniphier-pro4-usb3-reset + - socionext,uniphier-pro5-usb3-reset + - socionext,uniphier-pxs2-usb3-reset + - socionext,uniphier-ld20-usb3-reset + - socionext,uniphier-pxs3-usb3-reset + - socionext,uniphier-pro4-ahci-reset + - socionext,uniphier-pxs2-ahci-reset + - socionext,uniphier-pxs3-ahci-reset + + reg: + maxItems: 1 + + "#reset-cells": + const: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + oneOf: + - items: # for Pro4, Pro5 + - const: gio + - const: link + - items: # for others + - const: link + + resets: + minItems: 1 + maxItems: 2 + + reset-names: + oneOf: + - items: # for Pro4, Pro5 + - const: gio + - const: link + - items: # for others + - const: link + +additionalProperties: false + +required: + - compatible + - reg + - "#reset-cells" + - clocks + - clock-names + - resets + - reset-names + +examples: + - | + usb-glue@65b00000 { + compatible = "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x65b00000 0x400>; + + usb_rst: reset@0 { + compatible = "socionext,uniphier-ld20-usb3-reset"; + reg = <0x0 0x4>; + #reset-cells = <1>; + clock-names = "link"; + clocks = <&sys_clk 14>; + reset-names = "link"; + resets = <&sys_rst 14>; + }; + }; diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt deleted file mode 100644 index 88e06e5e8d23..000000000000 --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt +++ /dev/null @@ -1,61 +0,0 @@ -UniPhier glue reset controller - - -Peripheral core reset in glue layer ------------------------------------ - -Some peripheral core reset belongs to its own glue layer. Before using -this core reset, it is necessary to control the clocks and resets to enable -this layer. These clocks and resets should be described in each property. - -Required properties: -- compatible: Should be - "socionext,uniphier-pro4-usb3-reset" - for Pro4 SoC USB3 - "socionext,uniphier-pro5-usb3-reset" - for Pro5 SoC USB3 - "socionext,uniphier-pxs2-usb3-reset" - for PXs2 SoC USB3 - "socionext,uniphier-ld20-usb3-reset" - for LD20 SoC USB3 - "socionext,uniphier-pxs3-usb3-reset" - for PXs3 SoC USB3 - "socionext,uniphier-pro4-ahci-reset" - for Pro4 SoC AHCI - "socionext,uniphier-pxs2-ahci-reset" - for PXs2 SoC AHCI - "socionext,uniphier-pxs3-ahci-reset" - for PXs3 SoC AHCI -- #reset-cells: Should be 1. -- reg: Specifies offset and length of the register set for the device. -- clocks: A list of phandles to the clock gate for the glue layer. - According to the clock-names, appropriate clocks are required. -- clock-names: Should contain - "gio", "link" - for Pro4 and Pro5 SoCs - "link" - for others -- resets: A list of phandles to the reset control for the glue layer. - According to the reset-names, appropriate resets are required. -- reset-names: Should contain - "gio", "link" - for Pro4 and Pro5 SoCs - "link" - for others - -Example: - - usb-glue@65b00000 { - compatible = "socionext,uniphier-ld20-dwc3-glue", - "simple-mfd"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x65b00000 0x400>; - - usb_rst: reset@0 { - compatible = "socionext,uniphier-ld20-usb3-reset"; - reg = <0x0 0x4>; - #reset-cells = <1>; - clock-names = "link"; - clocks = <&sys_clk 14>; - reset-names = "link"; - resets = <&sys_rst 14>; - }; - - regulator { - ... - }; - - phy { - ... - }; - ... - }; diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml index 1d38ff76d18f..2b1f91603897 100644 --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml @@ -24,10 +24,10 @@ allOf: select: properties: compatible: - items: - - enum: - - sifive,fu540-c000-ccache - - sifive,fu740-c000-ccache + contains: + enum: + - sifive,fu540-c000-ccache + - sifive,fu740-c000-ccache required: - compatible diff --git a/Documentation/devicetree/bindings/riscv/starfive.yaml b/Documentation/devicetree/bindings/riscv/starfive.yaml new file mode 100644 index 000000000000..5b36243fd674 --- /dev/null +++ b/Documentation/devicetree/bindings/riscv/starfive.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/riscv/starfive.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive SoC-based boards + +maintainers: + - Michael Zhu <michael.zhu@starfivetech.com> + - Drew Fustini <drew@beagleboard.org> + +description: + StarFive SoC-based boards + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - items: + - const: beagle,beaglev-starlight-jh7100-r0 + - const: starfive,jh7100 + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml index 61888e07bda0..bb32491ee8ae 100644 --- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml @@ -21,6 +21,7 @@ properties: - enum: - mediatek,mt7622-rng - mediatek,mt7629-rng + - mediatek,mt7986-rng - mediatek,mt8365-rng - mediatek,mt8516-rng - const: mediatek,mt7623-rng diff --git a/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt b/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt deleted file mode 100644 index 5a613a4ec780..000000000000 --- a/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt +++ /dev/null @@ -1,17 +0,0 @@ -Exynos True Random Number Generator - -Required properties: - -- compatible : Should be "samsung,exynos5250-trng". -- reg : Specifies base physical address and size of the registers map. -- clocks : Phandle to clock-controller plus clock-specifier pair. -- clock-names : "secss" as a clock name. - -Example: - - rng@10830600 { - compatible = "samsung,exynos5250-trng"; - reg = <0x10830600 0x100>; - clocks = <&clock CLK_SSS>; - clock-names = "secss"; - }; diff --git a/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml b/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml new file mode 100644 index 000000000000..a50c34d5d199 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/samsung,exynos5250-trng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC True Random Number Generator + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Łukasz Stelmach <l.stelmach@samsung.com> + +properties: + compatible: + const: samsung,exynos5250-trng + + clocks: + maxItems: 1 + + clock-names: + items: + - const: secss + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5250.h> + + rng@10830600 { + compatible = "samsung,exynos5250-trng"; + reg = <0x10830600 0x100>; + clocks = <&clock CLK_SSS>; + clock-names = "secss"; + }; diff --git a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml index 657c13b62b67..056d42daae06 100644 --- a/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml +++ b/Documentation/devicetree/bindings/rtc/faraday,ftrtc010.yaml @@ -30,7 +30,6 @@ properties: maxItems: 1 clocks: - minItems: 2 items: - description: PCLK clocks - description: EXTCLK clocks. Faraday calls it CLK1HZ and says the clock diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml index a2c55303810d..9593840a4a2b 100644 --- a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml +++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml @@ -53,7 +53,6 @@ examples: rtc@51 { compatible = "microcrystal,rv3032"; reg = <0x51>; - status = "okay"; pinctrl-0 = <&rtc_nint_pins>; interrupts-extended = <&gpio1 16 IRQ_TYPE_LEVEL_HIGH>; trickle-resistor-ohms = <7000>; diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index a0bf061b80fe..fa767440f281 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -66,6 +66,12 @@ properties: - const: nxp,lpc3220-uart - items: - enum: + - exar,xr16l2552 + - exar,xr16l2551 + - exar,xr16l2550 + - const: ns8250 + - items: + - enum: - altr,16550-FIFO32 - altr,16550-FIFO64 - altr,16550-FIFO128 diff --git a/Documentation/devicetree/bindings/serial/8250_omap.yaml b/Documentation/devicetree/bindings/serial/8250_omap.yaml index 1c826fcf5828..70ca61688bb9 100644 --- a/Documentation/devicetree/bindings/serial/8250_omap.yaml +++ b/Documentation/devicetree/bindings/serial/8250_omap.yaml @@ -79,6 +79,7 @@ properties: power-domains: true clock-frequency: true current-speed: true + overrun-throttle-ms: true required: - compatible @@ -90,10 +91,11 @@ additionalProperties: false if: properties: compatible: - oneOf: - - const: ti,omap2-uart - - const: ti,omap3-uart - - const: ti,omap4-uart + contains: + enum: + - ti,omap2-uart + - ti,omap3-uart + - ti,omap4-uart then: properties: diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt b/Documentation/devicetree/bindings/serial/cdns,uart.txt deleted file mode 100644 index 4efc560f90ab..000000000000 --- a/Documentation/devicetree/bindings/serial/cdns,uart.txt +++ /dev/null @@ -1,27 +0,0 @@ -Binding for Cadence UART Controller - -Required properties: -- compatible : - Use "xlnx,xuartps","cdns,uart-r1p8" for Zynq-7xxx SoC. - Use "xlnx,zynqmp-uart","cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC. -- reg: Should contain UART controller registers location and length. -- interrupts: Should contain UART controller interrupts. -- clocks: Must contain phandles to the UART clocks - See ../clocks/clock-bindings.txt for details. -- clock-names: Tuple to identify input clocks, must contain "uart_clk" and "pclk" - See ../clocks/clock-bindings.txt for details. - - -Optional properties: -- cts-override : Override the CTS modem status signal. This signal will - always be reported as active instead of being obtained from the modem status - register. Define this if your serial port does not use this pin - -Example: - uart@e0000000 { - compatible = "cdns,uart-r1p8"; - clocks = <&clkc 23>, <&clkc 40>; - clock-names = "uart_clk", "pclk"; - reg = <0xE0000000 0x1000>; - interrupts = <0 27 4>; - }; diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.yaml b/Documentation/devicetree/bindings/serial/cdns,uart.yaml new file mode 100644 index 000000000000..fcdbe6f87e98 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/cdns,uart.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/cdns,uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence UART Controller Device Tree Bindings + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +allOf: + - $ref: /schemas/serial.yaml# + +properties: + compatible: + oneOf: + - description: UART controller for Zynq-7xxx SoC + items: + - const: xlnx,xuartps + - const: cdns,uart-r1p8 + - description: UART controller for Zynq Ultrascale+ MPSoC + items: + - const: xlnx,zynqmp-uart + - const: cdns,uart-r1p12 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: uart_clk + - const: pclk + + cts-override: + description: | + Override the CTS modem status signal. This signal will + always be reported as active instead of being obtained + from the modem status register. Define this if your serial + port does not use this pin. + type: boolean + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + uart0: serial@e0000000 { + compatible = "xlnx,xuartps", "cdns,uart-r1p8"; + clocks = <&clkc 23>, <&clkc 40>; + clock-names = "uart_clk", "pclk"; + reg = <0xE0000000 0x1000>; + interrupts = <0 27 4>; + }; diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index 64c4fb59acd1..b3a0bfef0d54 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -15,6 +15,7 @@ Required properties: * "mediatek,mt7622-uart" for MT7622 compatible UARTS * "mediatek,mt7623-uart" for MT7623 compatible UARTS * "mediatek,mt7629-uart" for MT7629 compatible UARTS + * "mediatek,mt7986-uart", "mediatek,mt6577-uart" for MT7986 compatible UARTS * "mediatek,mt8127-uart" for MT8127 compatible UARTS * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS diff --git a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml index c8b57c7fd08c..ecae9fa8561b 100644 --- a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml +++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml @@ -35,7 +35,6 @@ examples: soc_ctrl0: soc-controller@f0000000 { compatible = "litex,soc-controller"; reg = <0xf0000000 0xc>; - status = "okay"; }; ... diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt deleted file mode 100644 index 783dc81b0f26..000000000000 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt +++ /dev/null @@ -1,87 +0,0 @@ -Qualcomm Always-On Subsystem side channel binding - -This binding describes the hardware component responsible for side channel -requests to the always-on subsystem (AOSS), used for certain power management -requests that is not handled by the standard RPMh interface. Each client in the -SoC has it's own block of message RAM and IRQ for communication with the AOSS. -The protocol used to communicate in the message RAM is known as Qualcomm -Messaging Protocol (QMP) - -The AOSS side channel exposes control over a set of resources, used to control -a set of debug related clocks and to affect the low power state of resources -related to the secondary subsystems. These resources are exposed as a set of -power-domains. - -- compatible: - Usage: required - Value type: <string> - Definition: must be one of: - "qcom,sc7180-aoss-qmp" - "qcom,sc7280-aoss-qmp" - "qcom,sdm845-aoss-qmp" - "qcom,sm8150-aoss-qmp" - "qcom,sm8250-aoss-qmp" - "qcom,sm8350-aoss-qmp" - -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: the base address and size of the message RAM for this - client's communication with the AOSS - -- interrupts: - Usage: required - Value type: <prop-encoded-array> - Definition: should specify the AOSS message IRQ for this client - -- mboxes: - Usage: required - Value type: <prop-encoded-array> - Definition: reference to the mailbox representing the outgoing doorbell - in APCS for this client, as described in mailbox/mailbox.txt - -- #clock-cells: - Usage: optional - Value type: <u32> - Definition: must be 0 - The single clock represents the QDSS clock. - -- #power-domain-cells: - Usage: optional - Value type: <u32> - Definition: must be 1 - The provided power-domains are: - CDSP state (0), LPASS state (1), modem state (2), SLPI - state (3), SPSS state (4) and Venus state (5). - -= SUBNODES -The AOSS side channel also provides the controls for three cooling devices, -these are expressed as subnodes of the QMP node. The name of the node is used -to identify the resource and must therefor be "cx", "mx" or "ebi". - -- #cooling-cells: - Usage: optional - Value type: <u32> - Definition: must be 2 - -= EXAMPLE - -The following example represents the AOSS side-channel message RAM and the -mechanism exposing the power-domains, as found in SDM845. - - aoss_qmp: qmp@c300000 { - compatible = "qcom,sdm845-aoss-qmp"; - reg = <0x0c300000 0x100000>; - interrupts = <GIC_SPI 389 IRQ_TYPE_EDGE_RISING>; - mboxes = <&apss_shared 0>; - - #power-domain-cells = <1>; - - cx_cdev: cx { - #cooling-cells = <2>; - }; - - mx_cdev: mx { - #cooling-cells = <2>; - }; - }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml new file mode 100644 index 000000000000..93e4b737ee1b --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,aoss-qmp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Always-On Subsystem side channel binding + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + This binding describes the hardware component responsible for side channel + requests to the always-on subsystem (AOSS), used for certain power management + requests that is not handled by the standard RPMh interface. Each client in the + SoC has it's own block of message RAM and IRQ for communication with the AOSS. + The protocol used to communicate in the message RAM is known as Qualcomm + Messaging Protocol (QMP) + + The AOSS side channel exposes control over a set of resources, used to control + a set of debug related clocks and to affect the low power state of resources + related to the secondary subsystems. These resources are exposed as a set of + power-domains. + +properties: + compatible: + items: + - enum: + - qcom,sc7180-aoss-qmp + - qcom,sc7280-aoss-qmp + - qcom,sc8180x-aoss-qmp + - qcom,sdm845-aoss-qmp + - qcom,sm8150-aoss-qmp + - qcom,sm8250-aoss-qmp + - qcom,sm8350-aoss-qmp + - const: qcom,aoss-qmp + + reg: + maxItems: 1 + description: + The base address and size of the message RAM for this client's + communication with the AOSS + + interrupts: + maxItems: 1 + description: + Should specify the AOSS message IRQ for this client + + mboxes: + maxItems: 1 + description: + Reference to the mailbox representing the outgoing doorbell in APCS for + this client, as described in mailbox/mailbox.txt + + "#clock-cells": + const: 0 + description: + The single clock represents the QDSS clock. + + "#power-domain-cells": + const: 1 + description: | + The provided power-domains are: + CDSP state (0), LPASS state (1), modem state (2), SLPI + state (3), SPSS state (4) and Venus state (5). + +required: + - compatible + - reg + - interrupts + - mboxes + - "#clock-cells" + +additionalProperties: false + +patternProperties: + "^(cx|mx|ebi)$": + type: object + description: + The AOSS side channel also provides the controls for three cooling devices, + these are expressed as subnodes of the QMP node. The name of the node is + used to identify the resource and must therefor be "cx", "mx" or "ebi". + + properties: + "#cooling-cells": + const: 2 + + required: + - "#cooling-cells" + + additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + aoss_qmp: qmp@c300000 { + compatible = "qcom,sdm845-aoss-qmp", "qcom,aoss-qmp"; + reg = <0x0c300000 0x100000>; + interrupts = <GIC_SPI 389 IRQ_TYPE_EDGE_RISING>; + mboxes = <&apss_shared 0>; + + #clock-cells = <0>; + #power-domain-cells = <1>; + + cx_cdev: cx { + #cooling-cells = <2>; + }; + + mx_cdev: mx { + #cooling-cells = <2>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index 4663c2bcad50..a776cd37c297 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -51,6 +51,9 @@ properties: interconnect-names: const: qup-core + iommus: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index d511f01fcac6..cc3fe5ed7421 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -39,6 +39,7 @@ properties: - qcom,rpm-msm8996 - qcom,rpm-msm8998 - qcom,rpm-sdm660 + - qcom,rpm-sm6115 - qcom,rpm-sm6125 - qcom,rpm-qcs404 diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 62fa72cfea34..dfebf425ca49 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -15,7 +15,6 @@ properties: - items: - enum: - rockchip,rk3288-sgrf - - rockchip,rv1108-pmugrf - rockchip,rv1108-usbgrf - const: syscon - items: @@ -41,6 +40,7 @@ properties: - rockchip,rk3568-grf - rockchip,rk3568-pmugrf - rockchip,rv1108-grf + - rockchip,rv1108-pmugrf - const: syscon - const: simple-mfd @@ -198,21 +198,28 @@ allOf: compatible: contains: enum: - - rockchip,px30-pmugrf - rockchip,px30-grf + - rockchip,px30-pmugrf + - rockchip,rk3188-grf - rockchip,rk3228-grf - rockchip,rk3288-grf - rockchip,rk3328-grf - - rockchip,rk3368-pmugrf - rockchip,rk3368-grf - - rockchip,rk3399-pmugrf + - rockchip,rk3368-pmugrf - rockchip,rk3399-grf + - rockchip,rk3399-pmugrf + - rockchip,rk3568-pmugrf + - rockchip,rv1108-grf + - rockchip,rv1108-pmugrf then: properties: io-domains: - description: - Documentation/devicetree/bindings/power/rockchip-io-domain.txt + type: object + + $ref: "/schemas/power/rockchip-io-domain.yaml#" + + unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index 9790617af1bc..9d128b9e7deb 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -68,6 +68,7 @@ properties: - ti,k2g-pruss # for 66AK2G SoC family - ti,am654-icssg # for K3 AM65x SoC family - ti,j721e-icssg # for K3 J721E SoC family + - ti,am642-icssg # for K3 AM64x SoC family reg: maxItems: 1 @@ -84,6 +85,8 @@ properties: dma-ranges: maxItems: 1 + dma-coherent: true + power-domains: description: | This property is as per sci-pm-domain.txt. @@ -231,8 +234,8 @@ patternProperties: description: | Industrial Ethernet Peripheral to manage/generate Industrial Ethernet functions such as time stamping. Each PRUSS has either 1 IEP (on AM335x, - AM437x, AM57xx & 66AK2G SoCs) or 2 IEPs (on K3 AM65x & J721E SoCs ). IEP - is used for creating PTP clocks and generating PPS signals. + AM437x, AM57xx & 66AK2G SoCs) or 2 IEPs (on K3 AM65x, J721E & AM64x SoCs). + IEP is used for creating PTP clocks and generating PPS signals. type: object @@ -323,17 +326,29 @@ additionalProperties: false # - interrupt-controller # - pru -if: - properties: - compatible: - contains: - enum: - - ti,k2g-pruss - - ti,am654-icssg - - ti,j721e-icssg -then: - required: - - power-domains +allOf: + - if: + properties: + compatible: + contains: + enum: + - ti,k2g-pruss + - ti,am654-icssg + - ti,j721e-icssg + - ti,am642-icssg + then: + required: + - power-domains + + - if: + properties: + compatible: + contains: + enum: + - ti,k2g-pruss + then: + required: + - dma-coherent examples: - | diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt index c483dcec01f8..bd863bd69501 100644 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt @@ -6,6 +6,7 @@ Required properties: "ti,da830-mcasp-audio" : for both DA830 & DA850 platforms "ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, AM43xx, TI81xx) "ti,dra7-mcasp-audio" : for DRA7xx platforms + "ti,omap4-mcasp-audio" : for OMAP4 - reg : Should contain reg specifiers for the entries in the reg-names property. - reg-names : Should contain: diff --git a/Documentation/devicetree/bindings/sound/ics43432.txt b/Documentation/devicetree/bindings/sound/ics43432.txt index b02e3a6c0fef..e6f05f2f6c4e 100644 --- a/Documentation/devicetree/bindings/sound/ics43432.txt +++ b/Documentation/devicetree/bindings/sound/ics43432.txt @@ -1,4 +1,4 @@ -Invensense ICS-43432 MEMS microphone with I2S output. +Invensense ICS-43432-compatible MEMS microphone with I2S output. There are no software configuration options for this device, indeed, the only host connection is the I2S interface. Apart from requirements on clock @@ -8,7 +8,9 @@ contain audio data. A hardware pin determines if the device outputs data on the left or right channel of the I2S frame. Required properties: - - compatible : Must be "invensense,ics43432" + - compatible: should be one of the following. + "invensense,ics43432": For the Invensense ICS43432 + "cui,cmm-4030d-261": For the CUI CMM-4030D-261-I2S-TR Example: diff --git a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml new file mode 100644 index 000000000000..53e9434a6d9d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mt8195-afe-pcm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek AFE PCM controller for mt8195 + +maintainers: + - Trevor Wu <trevor.wu@mediatek.com> + +properties: + compatible: + const: mediatek,mt8195-audio + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + mediatek,topckgen: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of the mediatek topckgen controller + + power-domains: + maxItems: 1 + + clocks: + items: + - description: 26M clock + - description: audio pll1 clock + - description: audio pll2 clock + - description: clock divider for i2si1_mck + - description: clock divider for i2si2_mck + - description: clock divider for i2so1_mck + - description: clock divider for i2so2_mck + - description: clock divider for dptx_mck + - description: a1sys hoping clock + - description: audio intbus clock + - description: audio hires clock + - description: audio local bus clock + - description: mux for dptx_mck + - description: mux for i2so1_mck + - description: mux for i2so2_mck + - description: mux for i2si1_mck + - description: mux for i2si2_mck + - description: audio infra 26M clock + - description: infra bus clock + + clock-names: + items: + - const: clk26m + - const: apll1_ck + - const: apll2_ck + - const: apll12_div0 + - const: apll12_div1 + - const: apll12_div2 + - const: apll12_div3 + - const: apll12_div9 + - const: a1sys_hp_sel + - const: aud_intbus_sel + - const: audio_h_sel + - const: audio_local_bus_sel + - const: dptx_m_sel + - const: i2so1_m_sel + - const: i2so2_m_sel + - const: i2si1_m_sel + - const: i2si2_m_sel + - const: infra_ao_audio_26m_b + - const: scp_adsp_audiodsp + + mediatek,etdm-in1-chn-disabled: + $ref: /schemas/types.yaml#/definitions/uint8-array + maxItems: 24 + description: Specify which input channel should be disabled. + + mediatek,etdm-in2-chn-disabled: + $ref: /schemas/types.yaml#/definitions/uint8-array + maxItems: 16 + description: Specify which input channel should be disabled. + +patternProperties: + "^mediatek,etdm-in[1-2]-mclk-always-on-rate-hz$": + description: Specify etdm in mclk output rate for always on case. + + "^mediatek,etdm-out[1-3]-mclk-always-on-rate-hz$": + description: Specify etdm out mclk output rate for always on case. + + "^mediatek,etdm-in[1-2]-multi-pin-mode$": + type: boolean + description: if present, the etdm data mode is I2S. + + "^mediatek,etdm-out[1-3]-multi-pin-mode$": + type: boolean + description: if present, the etdm data mode is I2S. + + "^mediatek,etdm-in[1-2]-cowork-source$": + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + etdm modules can share the same external clock pin. Specify + which etdm clock source is required by this etdm in moudule. + enum: + - 0 # etdm1_in + - 1 # etdm2_in + - 2 # etdm1_out + - 3 # etdm2_out + + "^mediatek,etdm-out[1-2]-cowork-source$": + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + etdm modules can share the same external clock pin. Specify + which etdm clock source is required by this etdm out moudule. + enum: + - 0 # etdm1_in + - 1 # etdm2_in + - 2 # etdm1_out + - 3 # etdm2_out + +required: + - compatible + - reg + - interrupts + - mediatek,topckgen + - power-domains + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8195-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/mt8195-power.h> + + afe: mt8195-afe-pcm@10890000 { + compatible = "mediatek,mt8195-audio"; + reg = <0x10890000 0x10000>; + interrupts = <GIC_SPI 822 IRQ_TYPE_LEVEL_HIGH 0>; + mediatek,topckgen = <&topckgen>; + power-domains = <&spm MT8195_POWER_DOMAIN_AUDIO>; + clocks = <&clk26m>, + <&topckgen CLK_TOP_APLL1>, + <&topckgen CLK_TOP_APLL2>, + <&topckgen CLK_TOP_APLL12_DIV0>, + <&topckgen CLK_TOP_APLL12_DIV1>, + <&topckgen CLK_TOP_APLL12_DIV2>, + <&topckgen CLK_TOP_APLL12_DIV3>, + <&topckgen CLK_TOP_APLL12_DIV9>, + <&topckgen CLK_TOP_A1SYS_HP_SEL>, + <&topckgen CLK_TOP_AUD_INTBUS_SEL>, + <&topckgen CLK_TOP_AUDIO_H_SEL>, + <&topckgen CLK_TOP_AUDIO_LOCAL_BUS_SEL>, + <&topckgen CLK_TOP_DPTX_M_SEL>, + <&topckgen CLK_TOP_I2SO1_M_SEL>, + <&topckgen CLK_TOP_I2SO2_M_SEL>, + <&topckgen CLK_TOP_I2SI1_M_SEL>, + <&topckgen CLK_TOP_I2SI2_M_SEL>, + <&infracfg_ao CLK_INFRA_AO_AUDIO_26M_B>, + <&scp_adsp CLK_SCP_ADSP_AUDIODSP>; + clock-names = "clk26m", + "apll1_ck", + "apll2_ck", + "apll12_div0", + "apll12_div1", + "apll12_div2", + "apll12_div3", + "apll12_div9", + "a1sys_hp_sel", + "aud_intbus_sel", + "audio_h_sel", + "audio_local_bus_sel", + "dptx_m_sel", + "i2so1_m_sel", + "i2so2_m_sel", + "i2si1_m_sel", + "i2si2_m_sel", + "infra_ao_audio_26m_b", + "scp_adsp_audiodsp"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml new file mode 100644 index 000000000000..20bc0ffd0e34 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mt8195-mt6359-rt1019-rt5682.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT8195 with MT6359, RT1019 and RT5682 ASoC sound card driver + +maintainers: + - Trevor Wu <trevor.wu@mediatek.com> + +description: + This binding describes the MT8195 sound card. + +properties: + compatible: + const: mediatek,mt8195_mt6359_rt1019_rt5682 + + mediatek,platform: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8195 ASoC platform. + + mediatek,dptx-codec: + $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" + description: The phandle of MT8195 HDMI codec node. + +additionalProperties: false + +required: + - compatible + - mediatek,platform + +examples: + - | + + sound: mt8195-sound { + compatible = "mediatek,mt8195_mt6359_rt1019_rt5682"; + mediatek,platform = <&afe>; + pinctrl-names = "default"; + pinctrl-0 = <&aud_pins_default>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index 72ad9ab91832..7d57eb91657a 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -15,9 +15,9 @@ description: properties: compatible: - oneOf: - - const: qcom,sm8250-sndcard - - const: qcom,qrb5165-rb5-sndcard + enum: + - qcom,sm8250-sndcard + - qcom,qrb5165-rb5-sndcard audio-routing: $ref: /schemas/types.yaml#/definitions/non-unique-string-array diff --git a/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml b/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml index 644b68edf3e1..fdb7f295ef2d 100644 --- a/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml +++ b/Documentation/devicetree/bindings/sound/realtek,rt1015p.yaml @@ -15,7 +15,9 @@ description: | properties: compatible: - const: realtek,rt1015p + enum: + - realtek,rt1015p + - realtek,rt1019p sdb-gpios: description: diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index ee936d1aa724..c2930d65728e 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -114,7 +114,7 @@ properties: ports: $ref: /schemas/graph.yaml#/properties/ports - properties: + patternProperties: port(@[0-9a-f]+)?: $ref: audio-graph-port.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml new file mode 100644 index 000000000000..414ff8035a4e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/renesas,rz-ssi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/G2L ASoC Sound Serial Interface (SSIF-2) + +maintainers: + - Biju Das <biju.das.jz@bp.renesas.com> + +properties: + compatible: + items: + - enum: + - renesas,r9a07g044-ssi # RZ/G2{L,LC} + - const: renesas,rz-ssi + + reg: + maxItems: 1 + + interrupts: + maxItems: 4 + + interrupt-names: + items: + - const: int_req + - const: dma_rx + - const: dma_tx + - const: dma_rt + + clocks: + maxItems: 4 + + clock-names: + items: + - const: ssi + - const: ssi_sfr + - const: audio_clk1 + - const: audio_clk2 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + minItems: 1 + maxItems: 2 + description: + The first cell represents a phandle to dmac + The second cell specifies the encoded MID/RID values of the SSI port + connected to the DMA client and the slave channel configuration + parameters. + bits[0:9] - Specifies MID/RID value of a SSI channel as below + MID/RID value of SSI rx0 = 0x256 + MID/RID value of SSI tx0 = 0x255 + MID/RID value of SSI rx1 = 0x25a + MID/RID value of SSI tx1 = 0x259 + MID/RID value of SSI rt2 = 0x25f + MID/RID value of SSI rx3 = 0x262 + MID/RID value of SSI tx3 = 0x261 + bit[10] - HIEN = 1, Detects a request in response to the rising edge + of the signal + bit[11] - LVL = 0, Detects based on the edge + bits[12:14] - AM = 2, Bus cycle mode + bit[15] - TM = 0, Single transfer mode + + dma-names: + oneOf: + - items: + - const: tx + - const: rx + - items: + - const: rt + + '#sound-dai-cells': + const: 0 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - resets + - '#sound-dai-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/r9a07g044-cpg.h> + + ssi0: ssi@10049c00 { + compatible = "renesas,r9a07g044-ssi", + "renesas,rz-ssi"; + 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"; + clocks = <&cpg CPG_MOD R9A07G044_SSI0_PCLK2>, + <&cpg CPG_MOD R9A07G044_SSI0_PCLK_SFR>, + <&audio_clk1>, + <&audio_clk2>; + clock-names = "ssi", "ssi_sfr", "audio_clk1", "audio_clk2"; + power-domains = <&cpg>; + resets = <&cpg R9A07G044_SSI0_RST_M2_REG>; + dmas = <&dmac 0x2655>, + <&dmac 0x2656>; + dma-names = "tx", "rx"; + #sound-dai-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml index 245895b58a2f..5ea16b8ef93f 100644 --- a/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.yaml @@ -20,7 +20,9 @@ properties: - items: - enum: - rockchip,px30-i2s + - rockchip,rk1808-i2s - rockchip,rk3036-i2s + - rockchip,rk3128-i2s - rockchip,rk3188-i2s - rockchip,rk3228-i2s - rockchip,rk3288-i2s @@ -29,6 +31,7 @@ properties: - rockchip,rk3366-i2s - rockchip,rk3368-i2s - rockchip,rk3399-i2s + - rockchip,rv1126-i2s - const: rockchip,rk3066-i2s reg: @@ -61,6 +64,14 @@ properties: power-domains: maxItems: 1 + reset-names: + items: + - const: reset-m + - const: reset-h + + resets: + maxItems: 2 + rockchip,capture-channels: $ref: /schemas/types.yaml#/definitions/uint32 default: 2 diff --git a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml index 62a61b68dfef..d0a24bf928d6 100644 --- a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml +++ b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml @@ -23,6 +23,7 @@ properties: - const: rockchip,rk3366-spdif - const: rockchip,rk3368-spdif - const: rockchip,rk3399-spdif + - const: rockchip,rk3568-spdif - items: - enum: - rockchip,rk3188-spdif diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index 06e83461705c..f97132400bb6 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -180,7 +180,6 @@ examples: pinctrl-names = "default", "sleep"; pinctrl-0 = <&sai2a_pins_a>, <&sai2b_pins_b>; pinctrl-1 = <&sai2a_sleep_pins_a>, <&sai2b_sleep_pins_b>; - status = "okay"; sai2a: audio-controller@4400b004 { #sound-dai-cells = <0>; @@ -190,7 +189,6 @@ examples: dma-names = "tx"; clocks = <&rcc SAI2_K>; clock-names = "sai_ck"; - status = "okay"; }; }; diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml index ec06789b21df..6806f53a4aed 100644 --- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml @@ -127,8 +127,6 @@ examples: compatible = "ti,j721e-cpb-audio"; model = "j721e-cpb"; - status = "okay"; - ti,cpb-mcasp = <&mcasp10>; ti,cpb-codec = <&pcm3168a_1>; diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml index ee9f960de36b..859d369c71e2 100644 --- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml @@ -119,8 +119,6 @@ examples: compatible = "ti,j721e-cpb-ivi-audio"; model = "j721e-cpb-ivi"; - status = "okay"; - ti,cpb-mcasp = <&mcasp10>; ti,cpb-codec = <&pcm3168a_1>; diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index 54d64785aad2..d77c8283526d 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -24,10 +24,10 @@ description: | properties: compatible: - oneOf: - - const: ti,tlv320adc3140 - - const: ti,tlv320adc5140 - - const: ti,tlv320adc6140 + enum: + - ti,tlv320adc3140 + - ti,tlv320adc5140 + - ti,tlv320adc6140 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt b/Documentation/devicetree/bindings/spi/omap-spi.txt deleted file mode 100644 index 487208c256c0..000000000000 --- a/Documentation/devicetree/bindings/spi/omap-spi.txt +++ /dev/null @@ -1,48 +0,0 @@ -OMAP2+ McSPI device - -Required properties: -- compatible : - - "ti,am654-mcspi" for AM654. - - "ti,omap2-mcspi" for OMAP2 & OMAP3. - - "ti,omap4-mcspi" for OMAP4+. -- ti,spi-num-cs : Number of chipselect supported by the instance. -- ti,hwmods: Name of the hwmod associated to the McSPI -- ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as - input. The default is D0 as input and - D1 as output. - -Optional properties: -- dmas: List of DMA specifiers with the controller specific format - as described in the generic DMA client binding. A tx and rx - specifier is required for each chip select. -- dma-names: List of DMA request names. These strings correspond - 1:1 with the DMA specifiers listed in dmas. The string naming - is to be "rxN" and "txN" for RX and TX requests, - respectively, where N equals the chip select number. - -Examples: - -[hwmod populated DMA resources] - -mcspi1: mcspi@1 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "ti,omap4-mcspi"; - ti,hwmods = "mcspi1"; - ti,spi-num-cs = <4>; -}; - -[generic DMA request binding] - -mcspi1: mcspi@1 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "ti,omap4-mcspi"; - ti,hwmods = "mcspi1"; - ti,spi-num-cs = <2>; - dmas = <&edma 42 - &edma 43 - &edma 44 - &edma 45>; - dma-names = "tx0", "rx0", "tx1", "rx1"; -}; diff --git a/Documentation/devicetree/bindings/spi/omap-spi.yaml b/Documentation/devicetree/bindings/spi/omap-spi.yaml new file mode 100644 index 000000000000..e55538186cf6 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/omap-spi.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/omap-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI controller bindings for OMAP and K3 SoCs + +maintainers: + - Aswath Govindraju <a-govindraju@ti.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,am654-mcspi + - ti,am4372-mcspi + - const: ti,omap4-mcspi + - items: + - enum: + - ti,omap2-mcspi + - ti,omap4-mcspi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + ti,spi-num-cs: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of chipselect supported by the instance. + minimum: 1 + maximum: 4 + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + description: + Must be "mcspi<n>", n being the instance number (1-based). + This property is applicable only on legacy platforms mainly omap2/3 + and ti81xx and should not be used on other platforms. + deprecated: true + + ti,pindir-d0-out-d1-in: + description: + Select the D0 pin as output and D1 as input. The default is D0 + as input and D1 as output. + type: boolean + + dmas: + description: + List of DMA specifiers with the controller specific format as + described in the generic DMA client binding. A tx and rx + specifier is required for each chip select. + minItems: 1 + maxItems: 8 + + dma-names: + description: + List of DMA request names. These strings correspond 1:1 with + the DMA sepecifiers listed in dmas. The string names is to be + "rxN" and "txN" for RX and TX requests, respectively. Where N + is the chip select number. + minItems: 1 + maxItems: 8 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +if: + properties: + compatible: + oneOf: + - const: ti,omap2-mcspi + - const: ti,omap4-mcspi + +then: + properties: + ti,hwmods: + items: + - pattern: "^mcspi([1-9])$" + +else: + properties: + ti,hwmods: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/soc/ti,sci_pm_domain.h> + + spi@2100000 { + compatible = "ti,am654-mcspi","ti,omap4-mcspi"; + reg = <0x2100000 0x400>; + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&k3_clks 137 1>; + power-domains = <&k3_pds 137 TI_SCI_PD_EXCLUSIVE>; + #address-cells = <1>; + #size-cells = <0>; + dmas = <&main_udmap 0xc500>, <&main_udmap 0x4500>; + dma-names = "tx0", "rx0"; + }; diff --git a/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml b/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml index 30a62a211984..2f938c293f70 100644 --- a/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml +++ b/Documentation/devicetree/bindings/spi/realtek,rtl-spi.yaml @@ -15,12 +15,12 @@ allOf: properties: compatible: - oneOf: - - const: realtek,rtl8380-spi - - const: realtek,rtl8382-spi - - const: realtek,rtl8391-spi - - const: realtek,rtl8392-spi - - const: realtek,rtl8393-spi + enum: + - realtek,rtl8380-spi + - realtek,rtl8382-spi + - realtek,rtl8391-spi + - realtek,rtl8392-spi + - realtek,rtl8393-spi reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/spi/rockchip-sfc.yaml b/Documentation/devicetree/bindings/spi/rockchip-sfc.yaml new file mode 100644 index 000000000000..339fb39529f3 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/rockchip-sfc.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/rockchip-sfc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip Serial Flash Controller (SFC) + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + - Chris Morgan <macromorgan@hotmail.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + const: rockchip,sfc + description: + The rockchip sfc controller is a standalone IP with version register, + and the driver can handle all the feature difference inside the IP + depending on the version register. + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + + clock-names: + items: + - const: clk_sfc + - const: hclk_sfc + + power-domains: + maxItems: 1 + + rockchip,sfc-no-dma: + description: Disable DMA and utilize FIFO mode only + type: boolean + +patternProperties: + "^flash@[0-3]$": + type: object + properties: + reg: + minimum: 0 + maximum: 3 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/px30-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/px30-power.h> + + sfc: spi@ff3a0000 { + compatible = "rockchip,sfc"; + reg = <0xff3a0000 0x4000>; + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_SFC>, <&cru HCLK_SFC>; + clock-names = "clk_sfc", "hclk_sfc"; + pinctrl-0 = <&sfc_clk &sfc_cs &sfc_bus2>; + pinctrl-names = "default"; + power-domains = <&power PX30_PD_MMC_NAND>; + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + spi-max-frequency = <108000000>; + spi-rx-bus-width = <2>; + spi-tx-bus-width = <2>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index faef4f6f55b8..8246891602e7 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -79,22 +79,7 @@ properties: description: The SPI controller acts as a slave, instead of a master. -allOf: - - if: - not: - required: - - spi-slave - then: - properties: - "#address-cells": - const: 1 - else: - properties: - "#address-cells": - const: 0 - -patternProperties: - "^slave$": + slave: type: object properties: @@ -105,6 +90,7 @@ patternProperties: required: - compatible +patternProperties: "^.*@[0-9a-f]+$": type: object @@ -180,6 +166,20 @@ patternProperties: - compatible - reg +allOf: + - if: + not: + required: + - spi-slave + then: + properties: + "#address-cells": + const: 1 + else: + properties: + "#address-cells": + const: 0 + additionalProperties: true examples: diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt index 4d0e4c15c4ea..2a24969159cc 100644 --- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt @@ -11,6 +11,7 @@ Required properties: - mediatek,mt8135-spi: for mt8135 platforms - mediatek,mt8173-spi: for mt8173 platforms - mediatek,mt8183-spi: for mt8183 platforms + - mediatek,mt6893-spi: for mt6893 platforms - "mediatek,mt8192-spi", "mediatek,mt6765-spi": for mt8192 platforms - "mediatek,mt8195-spi", "mediatek,mt6765-spi": for mt8195 platforms - "mediatek,mt8516-spi", "mediatek,mt2712-spi": for mt8516 platforms diff --git a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt deleted file mode 100644 index 2567c829e2dc..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt +++ /dev/null @@ -1,63 +0,0 @@ -Spreadtrum ADI controller - -ADI is the abbreviation of Anolog-Digital interface, which is used to access -analog chip (such as PMIC) from digital chip. ADI controller follows the SPI -framework for its hardware implementation is alike to SPI bus and its timing -is compatile to SPI timing. - -ADI controller has 50 channels including 2 software read/write channels and -48 hardware channels to access analog chip. For 2 software read/write channels, -users should set ADI registers to access analog chip. For hardware channels, -we can configure them to allow other hardware components to use it independently, -which means we can just link one analog chip address to one hardware channel, -then users can access the mapped analog chip address by this hardware channel -triggered by hardware components instead of ADI software channels. - -Thus we introduce one property named "sprd,hw-channels" to configure hardware -channels, the first value specifies the hardware channel id which is used to -transfer data triggered by hardware automatically, and the second value specifies -the analog chip address where user want to access by hardware components. - -Since we have multi-subsystems will use unique ADI to access analog chip, when -one system is reading/writing data by ADI software channels, that should be under -one hardware spinlock protection to prevent other systems from reading/writing -data by ADI software channels at the same time, or two parallel routine of setting -ADI registers will make ADI controller registers chaos to lead incorrect results. -Then we need one hardware spinlock to synchronize between the multiple subsystems. - -The new version ADI controller supplies multiple master channels for different -subsystem accessing, that means no need to add hardware spinlock to synchronize, -thus change the hardware spinlock support to be optional to keep backward -compatibility. - -Required properties: -- compatible: Should be "sprd,sc9860-adi". -- reg: Offset and length of ADI-SPI controller register space. -- #address-cells: Number of cells required to define a chip select address - on the ADI-SPI bus. Should be set to 1. -- #size-cells: Size of cells required to define a chip select address size - on the ADI-SPI bus. Should be set to 0. - -Optional properties: -- hwlocks: Reference to a phandle of a hwlock provider node. -- hwlock-names: Reference to hwlock name strings defined in the same order - as the hwlocks, should be "adi". -- sprd,hw-channels: This is an array of channel values up to 49 channels. - The first value specifies the hardware channel id which is used to - transfer data triggered by hardware automatically, and the second - value specifies the analog chip address where user want to access - by hardware components. - -SPI slave nodes must be children of the SPI controller node and can contain -properties described in Documentation/devicetree/bindings/spi/spi-bus.txt. - -Example: - adi_bus: spi@40030000 { - compatible = "sprd,sc9860-adi"; - reg = <0 0x40030000 0 0x10000>; - hwlocks = <&hwlock1 0>; - hwlock-names = "adi"; - #address-cells = <1>; - #size-cells = <0>; - sprd,hw-channels = <30 0x8c20>; - }; diff --git a/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml b/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml new file mode 100644 index 000000000000..fe014020da69 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/spi/sprd,spi-adi.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Spreadtrum ADI controller + +maintainers: + - Orson Zhai <orsonzhai@gmail.com> + - Baolin Wang <baolin.wang7@gmail.com> + - Chunyan Zhang <zhang.lyra@gmail.com> + +description: | + ADI is the abbreviation of Anolog-Digital interface, which is used to access + analog chip (such as PMIC) from digital chip. ADI controller follows the SPI + framework for its hardware implementation is alike to SPI bus and its timing + is compatile to SPI timing. + + ADI controller has 50 channels including 2 software read/write channels and + 48 hardware channels to access analog chip. For 2 software read/write channels, + users should set ADI registers to access analog chip. For hardware channels, + we can configure them to allow other hardware components to use it independently, + which means we can just link one analog chip address to one hardware channel, + then users can access the mapped analog chip address by this hardware channel + triggered by hardware components instead of ADI software channels. + + Thus we introduce one property named "sprd,hw-channels" to configure hardware + channels, the first value specifies the hardware channel id which is used to + transfer data triggered by hardware automatically, and the second value specifies + the analog chip address where user want to access by hardware components. + + Since we have multi-subsystems will use unique ADI to access analog chip, when + one system is reading/writing data by ADI software channels, that should be under + one hardware spinlock protection to prevent other systems from reading/writing + data by ADI software channels at the same time, or two parallel routine of setting + ADI registers will make ADI controller registers chaos to lead incorrect results. + Then we need one hardware spinlock to synchronize between the multiple subsystems. + + The new version ADI controller supplies multiple master channels for different + subsystem accessing, that means no need to add hardware spinlock to synchronize, + thus change the hardware spinlock support to be optional to keep backward + compatibility. + +allOf: + - $ref: /spi/spi-controller.yaml# + +properties: + compatible: + enum: + - sprd,sc9860-adi + - sprd,sc9863-adi + - sprd,ums512-adi + + reg: + maxItems: 1 + + hwlocks: + maxItems: 1 + + hwlock-names: + const: adi + + sprd,hw-channels: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + description: A list of hardware channels + minItems: 1 + maxItems: 48 + items: + items: + - description: The hardware channel id which is used to transfer data + triggered by hardware automatically, channel id 0-1 are for software + use, 2-49 are hardware channels. + minimum: 2 + maximum: 49 + - description: The analog chip address where user want to access by + hardware components. + +required: + - compatible + - reg + - '#address-cells' + - '#size-cells' + +unevaluatedProperties: false + +examples: + - | + aon { + #address-cells = <2>; + #size-cells = <2>; + + adi_bus: spi@40030000 { + compatible = "sprd,sc9860-adi"; + reg = <0 0x40030000 0 0x10000>; + hwlocks = <&hwlock1 0>; + hwlock-names = "adi"; + #address-cells = <1>; + #size-cells = <0>; + sprd,hw-channels = <30 0x8c20>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 4a2eaf28e3fd..d3b9e9b600a2 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -48,6 +48,7 @@ properties: - qcom,sc7180-tsens - qcom,sc7280-tsens - qcom,sc8180x-tsens + - qcom,sdm630-tsens - qcom,sdm845-tsens - qcom,sm8150-tsens - qcom,sm8250-tsens diff --git a/Documentation/devicetree/bindings/timer/arm,sp804.yaml b/Documentation/devicetree/bindings/timer/arm,sp804.yaml index 960e2bd66a97..41be7cdab2ec 100644 --- a/Documentation/devicetree/bindings/timer/arm,sp804.yaml +++ b/Documentation/devicetree/bindings/timer/arm,sp804.yaml @@ -23,9 +23,9 @@ select: properties: compatible: contains: - oneOf: - - const: arm,sp804 - - const: hisilicon,sp804 + enum: + - arm,sp804 + - hisilicon,sp804 required: - compatible diff --git a/Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt b/Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt deleted file mode 100644 index e502c11b2211..000000000000 --- a/Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt +++ /dev/null @@ -1,23 +0,0 @@ -* EFM32 timer hardware - -The efm32 Giant Gecko SoCs come with four 16 bit timers. Two counters can be -connected to form a 32 bit counter. Each timer has three Compare/Capture -channels and can be used as PWM or Quadrature Decoder. Available clock sources -are the cpu's HFPERCLK (with a 10-bit prescaler) or an external pin. - -Required properties: -- compatible : Should be "energymicro,efm32-timer" -- reg : Address and length of the register set -- clocks : Should contain a reference to the HFPERCLK - -Optional properties: -- interrupts : Reference to the timer interrupt - -Example: - -timer@40010c00 { - compatible = "energymicro,efm32-timer"; - reg = <0x40010c00 0x400>; - interrupts = <14>; - clocks = <&cmu clk_HFPERCLKTIMER3>; -}; diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt deleted file mode 100644 index d65fdce7c7f0..000000000000 --- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt +++ /dev/null @@ -1,27 +0,0 @@ -Rockchip rk timer - -Required properties: -- compatible: should be: - "rockchip,rv1108-timer", "rockchip,rk3288-timer": for Rockchip RV1108 - "rockchip,rk3036-timer", "rockchip,rk3288-timer": for Rockchip RK3036 - "rockchip,rk3066-timer", "rockchip,rk3288-timer": for Rockchip RK3066 - "rockchip,rk3188-timer", "rockchip,rk3288-timer": for Rockchip RK3188 - "rockchip,rk3228-timer", "rockchip,rk3288-timer": for Rockchip RK3228 - "rockchip,rk3229-timer", "rockchip,rk3288-timer": for Rockchip RK3229 - "rockchip,rk3288-timer": for Rockchip RK3288 - "rockchip,rk3368-timer", "rockchip,rk3288-timer": for Rockchip RK3368 - "rockchip,rk3399-timer": for Rockchip RK3399 -- reg: base address of the timer register starting with TIMERS CONTROL register -- interrupts: should contain the interrupts for Timer0 -- clocks : must contain an entry for each entry in clock-names -- clock-names : must include the following entries: - "timer", "pclk" - -Example: - timer: timer@ff810000 { - compatible = "rockchip,rk3288-timer"; - reg = <0xff810000 0x20>; - interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&xin24m>, <&cru PCLK_TIMER>; - clock-names = "timer", "pclk"; - }; diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml new file mode 100644 index 000000000000..e26ecb5893ae --- /dev/null +++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/rockchip,rk-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip Timer Device Tree Bindings + +maintainers: + - Daniel Lezcano <daniel.lezcano@linaro.org> + +properties: + compatible: + oneOf: + - const: rockchip,rk3288-timer + - const: rockchip,rk3399-timer + - items: + - enum: + - rockchip,rv1108-timer + - rockchip,rk3036-timer + - rockchip,rk3066-timer + - rockchip,rk3188-timer + - rockchip,rk3228-timer + - rockchip,rk3229-timer + - rockchip,rk3288-timer + - rockchip,rk3368-timer + - rockchip,px30-timer + - const: rockchip,rk3288-timer + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: pclk + - const: timer + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/rk3288-cru.h> + + timer: timer@ff810000 { + compatible = "rockchip,rk3288-timer"; + reg = <0xff810000 0x20>; + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru PCLK_TIMER>, <&xin24m>; + clock-names = "pclk", "timer"; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 919a4bf03a5a..1e4b3464d734 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -33,6 +33,8 @@ properties: - ad,ad7414 # ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems - ad,adm9240 + # AD5110 - Nonvolatile Digital Potentiometer + - adi,ad5110 # Analog Devices ADP5585 Keypad Decoder and I/O Expansion - adi,adp5585 # Analog Devices ADP5585 Keypad Decoder and I/O Expansion with support for Row5 @@ -61,6 +63,8 @@ properties: - capella,cm32181 # CM3232: Ambient Light Sensor - capella,cm3232 + # CM3323: Ambient Light Sensor + - capella,cm3323 # High-Precision Digital Thermometer - dallas,ds1631 # Total-Elapsed-Time Recorder with Alarm @@ -143,6 +147,8 @@ properties: - maxim,ds1803-100 # Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs - maxim,max1237 + # Temperature Sensor, I2C interface + - maxim,max1619 # 10-bit 10 kOhm linear programable voltage divider - maxim,max5481 # 10-bit 50 kOhm linear programable voltage divider @@ -269,6 +275,8 @@ properties: - sensirion,sgpc3 # Sensirion multi-pixel gas sensor with I2C interface - sensirion,sgp30 + # Sensirion gas sensor with I2C interface + - sensirion,sgp40 # Sensortek 3 axis accelerometer - sensortek,stk8312 # Sensortek 3 axis accelerometer diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index 8089dc956ba3..8913497624de 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -34,6 +34,7 @@ properties: - allwinner,sun6i-a31-ehci - allwinner,sun7i-a20-ehci - allwinner,sun8i-a23-ehci + - allwinner,sun8i-a83t-ehci - allwinner,sun8i-h3-ehci - allwinner,sun8i-r40-ehci - allwinner,sun9i-a80-ehci @@ -142,6 +143,11 @@ properties: iommus: maxItems: 1 + dr_mode: + enum: + - host + - otg + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml index 0f5f6ea702d0..acbf94fa5f74 100644 --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml @@ -24,6 +24,7 @@ properties: - allwinner,sun6i-a31-ohci - allwinner,sun7i-a20-ohci - allwinner,sun8i-a23-ohci + - allwinner,sun8i-a83t-ohci - allwinner,sun8i-h3-ohci - allwinner,sun8i-r40-ohci - allwinner,sun9i-a80-ohci @@ -109,6 +110,11 @@ properties: iommus: maxItems: 1 + dr_mode: + enum: + - host + - otg + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index 240882b12565..11f7bacd4e2b 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -31,6 +31,7 @@ properties: - mediatek,mt8173-xhci - mediatek,mt8183-xhci - mediatek,mt8192-xhci + - mediatek,mt8195-xhci - const: mediatek,mtk-xhci reg: @@ -152,6 +153,11 @@ properties: description: The mask to disable u3ports, bit0 for u3port0, bit1 for u3port1, ... etc + mediatek,u2p-dis-msk: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The mask to disable u2ports, bit0 for u2port0, + bit1 for u2port1, ... etc + "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index dbc7876e0a0b..77db1233516e 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -38,7 +38,18 @@ properties: - const: ippc interrupts: - maxItems: 1 + description: + use "interrupts-extended" when the interrupts are connected to the + separate interrupt controllers + minItems: 1 + items: + - description: SSUSB device controller interrupt + - description: optional, wakeup interrupt used to support runtime PM + + interrupt-names: + items: + - const: device + - const: wakeup power-domains: description: A phandle to USB power domain node to control USB's MTCMOS @@ -106,7 +117,7 @@ properties: extcon: deprecated: true description: | - Phandle to the extcon device detecting the IDDIG/VBUS state, neede + Phandle to the extcon device detecting the IDDIG state, needed when supports dual-role mode. It's considered valid for compatibility reasons, not allowed for new bindings, and use "usb-role-switch" property instead. @@ -116,6 +127,10 @@ properties: description: Support role switch. type: boolean + role-switch-default-mode: + enum: [host, peripheral] + default: host + connector: $ref: /connector/usb-connector.yaml# description: @@ -166,6 +181,12 @@ properties: description: The mask to disable u3ports, bit0 for u3port0, bit1 for u3port1, ... etc + mediatek,u2p-dis-msk: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The mask to disable u2ports, bit0 for u2port0, + bit1 for u2port1, ... etc; but can't disable u2port0 if dual role mode + is enabled, so will be skipped in this case. + # Required child node when support dual-role patternProperties: "^usb@[0-9a-f]+$": @@ -178,6 +199,7 @@ patternProperties: dependencies: connector: [ 'usb-role-switch' ] port: [ 'usb-role-switch' ] + role-switch-default-mode: [ 'usb-role-switch' ] wakeup-source: [ 'mediatek,syscon-wakeup' ] required: @@ -230,7 +252,7 @@ examples: }; }; - # Enable/disable device by an input gpio for VBUS pin + # Dual role switch by gpio-usb-b-connector - | #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/power/mt2712-power.h> @@ -244,13 +266,27 @@ examples: power-domains = <&scpsys MT2712_POWER_DOMAIN_USB2>; clocks = <&topckgen CLK_TOP_USB30_SEL>; clock-names = "sys_ck"; - dr_mode = "peripheral"; + dr_mode = "otg"; usb-role-switch; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + host0: usb@11270000 { + compatible = "mediatek,mt2712-xhci", "mediatek,mtk-xhci"; + reg = <0x11270000 0x1000>; + reg-names = "mac"; + interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT2712_POWER_DOMAIN_USB>; + clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>; + clock-names = "sys_ck", "ref_ck"; + }; connector { compatible = "gpio-usb-b-connector", "usb-b-connector"; type = "micro"; - vbus-gpios = <&pio 13 GPIO_ACTIVE_HIGH>; + id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>; + vbus-supply = <&usb_p0_vbus>; }; }; @@ -268,6 +304,7 @@ examples: wakeup-source; dr_mode = "otg"; usb-role-switch; + role-switch-default-mode = "host"; #address-cells = <1>; #size-cells = <1>; ranges; diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml index 84ddacfdbe9b..03d62d60ce5f 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml @@ -19,6 +19,7 @@ properties: - enum: - mediatek,mt8516-musb - mediatek,mt2701-musb + - mediatek,mt7623-musb - const: mediatek,mtk-musb reg: diff --git a/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml b/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml index a88f99adfe8e..f238848ad094 100644 --- a/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml +++ b/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml @@ -25,14 +25,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: Host controller interrupt - description: Device controller interrupt in isp1761 interrupt-names: minItems: 1 - maxItems: 2 items: - const: host - const: peripheral diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index 4e6451789806..e70afc40edb2 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -17,6 +17,7 @@ properties: - qcom,msm8998-dwc3 - qcom,sc7180-dwc3 - qcom,sc7280-dwc3 + - qcom,sdm660-dwc3 - qcom,sdm845-dwc3 - qcom,sdx55-dwc3 - qcom,sm4250-dwc3 diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index ad73339ffe1d..012fe80a7611 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -17,7 +17,9 @@ properties: - const: renesas,rza1-usbhs - items: - - const: renesas,usbhs-r7s9210 # RZ/A2 + - enum: + - renesas,usbhs-r7s9210 # RZ/A2 + - renesas,usbhs-r9a07g044 # RZ/G2{L,LC} - const: renesas,rza2-usbhs - items: @@ -59,7 +61,8 @@ properties: - description: USB 2.0 clock selector interrupts: - maxItems: 1 + minItems: 1 + maxItems: 4 renesas,buswait: $ref: /schemas/types.yaml#/definitions/uint32 @@ -108,6 +111,25 @@ required: - clocks - interrupts +allOf: + - if: + properties: + compatible: + contains: + const: renesas,usbhs-r9a07g044 + then: + properties: + interrupts: + items: + - description: U2P_IXL_INT + - description: U2P_INT_DMA[0] + - description: U2P_INT_DMA[1] + - description: U2P_INT_DMAERR + else: + properties: + interrupts: + maxItems: 1 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 41416fbd92aa..078fb7889593 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -289,10 +289,21 @@ properties: maximum: 16 tx-fifo-resize: - description: Determines if the FIFO *has* to be reallocated - deprecated: true + description: Determines if the TX fifos can be dynamically resized depending + on the number of IN endpoints used and if bursting is supported. This + may help improve bandwidth on platforms with higher system latencies, as + increased fifo space allows for the controller to prefetch data into its + internal memory. type: boolean + tx-fifo-max-num: + description: Specifies the max number of packets the txfifo resizing logic + can account for when higher endpoint bursting is used. (bMaxBurst > 6) The + higher the number, the more fifo space the txfifo resizing logic will + allocate for that endpoint. + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 3 + snps,incr-burst-type-adjustment: description: Value for INCR burst type of GSBUSCFG0 register, undefined length INCR diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 07fb0d25fc15..a867f7102c35 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -271,6 +271,8 @@ patternProperties: description: Shenzen Chuangsiqi Technology Co.,Ltd. "^cubietech,.*": description: Cubietech, Ltd. + "^cui,.*": + description: CUI Devices "^cypress,.*": description: Cypress Semiconductor Corporation "^cznic,.*": @@ -339,6 +341,8 @@ patternProperties: description: eGalax_eMPIA Technology Inc "^einfochips,.*": description: Einfochips + "^eink,.*": + description: E Ink Corporation "^elan,.*": description: Elan Microelectronic Corp. "^element14,.*": @@ -563,6 +567,8 @@ patternProperties: description: ITE Tech. Inc. "^itead,.*": description: ITEAD Intelligent Systems Co.Ltd + "^itian,.*": + description: ITian Corporation "^iwave,.*": description: iWave Systems Technologies Pvt. Ltd. "^jdi,.*": @@ -735,6 +741,8 @@ patternProperties: description: MiraMEMS Sensing Technology Co., Ltd. "^mitsubishi,.*": description: Mitsubishi Electric Corporation + "^mntre,.*": + description: MNT Research GmbH "^modtronix,.*": description: Modtronix Engineering "^mosaixtech,.*": @@ -936,6 +944,8 @@ patternProperties: description: Chengdu Kaixuan Information Technology Co., Ltd. "^qiaodian,.*": description: QiaoDian XianShi Corporation + "^qishenglong,.*": + description: Shenzhen QiShenglong Industrialist Co., Ltd. "^qnap,.*": description: QNAP Systems, Inc. "^radxa,.*": @@ -1066,6 +1076,8 @@ patternProperties: description: Silicon Integrated Systems Corp. "^sitronix,.*": description: Sitronix Technology Corporation + "^skov,.*": + description: SKOV A/S "^skyworks,.*": description: Skyworks Solutions, Inc. "^smartlabs,.*": @@ -1111,6 +1123,10 @@ patternProperties: "^st-ericsson,.*": description: ST-Ericsson deprecated: true + "^storlink,.*": + description: StorLink Semiconductors, Inc. + "^storm,.*": + description: Storm Semiconductor, Inc. "^summit,.*": description: Summit microelectronics "^sunchip,.*": @@ -1143,6 +1159,8 @@ patternProperties: description: TechNexion "^technologic,.*": description: Technologic Systems + "^teltonika,.*": + description: Teltonika Networks "^tempo,.*": description: Tempo Semiconductor "^techstar,.*": @@ -1165,6 +1183,8 @@ patternProperties: description: Tecon Microprocessor Technologies, LLC. "^topeet,.*": description: Topeet + "^topic,.*": + description: Topic Embedded Systems "^toppoly,.*": description: TPO (deprecated, use tpo) deprecated: true @@ -1184,6 +1204,8 @@ patternProperties: description: TPO "^tq,.*": description: TQ-Systems GmbH + "^traverse,.*": + description: Traverse Technologies Australia Pty Ltd "^tronfy,.*": description: Tronfy "^tronsmart,.*": @@ -1268,6 +1290,8 @@ patternProperties: description: Shenzhen whwave Electronics, Inc. "^wi2wi,.*": description: Wi2Wi, Inc. + "^wiligear,.*": + description: Wiligear, Ltd. "^winbond,.*": description: Winbond Electronics corp. "^winstar,.*": diff --git a/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml b/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml new file mode 100644 index 000000000000..f2105eedac2c --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/maxim,max63xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim 63xx Watchdog Timers + +allOf: + - $ref: "watchdog.yaml#" + +maintainers: + - Marc Zyngier <maz@kernel.org> + - Linus Walleij <linus.walleij@linaro.org> + +properties: + compatible: + oneOf: + - const: maxim,max6369 + - const: maxim,max6370 + - const: maxim,max6371 + - const: maxim,max6372 + - const: maxim,max6373 + - const: maxim,max6374 + + reg: + description: This is a 1-byte memory-mapped address + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + wdt: watchdog@50000000 { + compatible = "maxim,max6369"; + reg = <0x50000000 0x1>; + timeout-sec = <10>; + }; + +... diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index 416d716403f6..a4e31ce96e0e 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -13,6 +13,7 @@ Required properties: "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623 "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 + "mediatek,mt7986-wdt", "mediatek,mt6589-wdt": for MT7986 "mediatek,mt8183-wdt": for MT8183 "mediatek,mt8516-wdt", "mediatek,mt6589-wdt": for MT8516 "mediatek,mt8192-wdt": for MT8192 diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 7f21425d9435..f5ac4c90b237 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -88,6 +88,9 @@ consider though: - The DMA buffer FD is also pollable, see `Implicit Fence Poll Support`_ below for details. +- The DMA buffer FD also supports a few dma-buf-specific ioctls, see + `DMA Buffer ioctls`_ below for details. + Basic Operation and Device DMA Access ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -106,6 +109,16 @@ Implicit Fence Poll Support .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: implicit fence polling +DMA-BUF statistics +~~~~~~~~~~~~~~~~~~ +.. kernel-doc:: drivers/dma-buf/dma-buf-sysfs-stats.c + :doc: overview + +DMA Buffer ioctls +~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/uapi/linux/dma-buf.h + Kernel Functions and Structures Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/driver-api/early-userspace/early_userspace_support.rst b/Documentation/driver-api/early-userspace/early_userspace_support.rst index 8a58c61932ff..61bdeac1bae5 100644 --- a/Documentation/driver-api/early-userspace/early_userspace_support.rst +++ b/Documentation/driver-api/early-userspace/early_userspace_support.rst @@ -69,17 +69,17 @@ early userspace image can be built by an unprivileged user. As a technical note, when directories and files are specified, the entire CONFIG_INITRAMFS_SOURCE is passed to -usr/gen_initramfs_list.sh. This means that CONFIG_INITRAMFS_SOURCE +usr/gen_initramfs.sh. This means that CONFIG_INITRAMFS_SOURCE can really be interpreted as any legal argument to -gen_initramfs_list.sh. If a directory is specified as an argument then +gen_initramfs.sh. If a directory is specified as an argument then the contents are scanned, uid/gid translation is performed, and usr/gen_init_cpio file directives are output. If a directory is -specified as an argument to usr/gen_initramfs_list.sh then the +specified as an argument to usr/gen_initramfs.sh then the contents of the file are simply copied to the output. All of the output directives from directory scanning and file contents copying are processed by usr/gen_init_cpio. -See also 'usr/gen_initramfs_list.sh -h'. +See also 'usr/gen_initramfs.sh -h'. Where's this all leading? ========================= diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst index 198aadafd3e7..8d650b4e2ce6 100644 --- a/Documentation/driver-api/fpga/fpga-bridge.rst +++ b/Documentation/driver-api/fpga/fpga-bridge.rst @@ -4,11 +4,11 @@ FPGA Bridge API to implement a new FPGA bridge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* struct fpga_bridge — The FPGA Bridge structure -* struct fpga_bridge_ops — Low level Bridge driver ops -* devm_fpga_bridge_create() — Allocate and init a bridge struct -* fpga_bridge_register() — Register a bridge -* fpga_bridge_unregister() — Unregister a bridge +* struct fpga_bridge - The FPGA Bridge structure +* struct fpga_bridge_ops - Low level Bridge driver ops +* devm_fpga_bridge_create() - Allocate and init a bridge struct +* fpga_bridge_register() - Register a bridge +* fpga_bridge_unregister() - Unregister a bridge .. kernel-doc:: include/linux/fpga/fpga-bridge.h :functions: fpga_bridge diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst index 917ee22db429..4d926b452cb3 100644 --- a/Documentation/driver-api/fpga/fpga-mgr.rst +++ b/Documentation/driver-api/fpga/fpga-mgr.rst @@ -101,12 +101,12 @@ in state. API for implementing a new FPGA Manager driver ---------------------------------------------- -* ``fpga_mgr_states`` — Values for :c:expr:`fpga_manager->state`. -* struct fpga_manager — the FPGA manager struct -* struct fpga_manager_ops — Low level FPGA manager driver ops -* devm_fpga_mgr_create() — Allocate and init a manager struct -* fpga_mgr_register() — Register an FPGA manager -* fpga_mgr_unregister() — Unregister an FPGA manager +* ``fpga_mgr_states`` - Values for :c:expr:`fpga_manager->state`. +* struct fpga_manager - the FPGA manager struct +* struct fpga_manager_ops - Low level FPGA manager driver ops +* devm_fpga_mgr_create() - Allocate and init a manager struct +* fpga_mgr_register() - Register an FPGA manager +* fpga_mgr_unregister() - Unregister an FPGA manager .. kernel-doc:: include/linux/fpga/fpga-mgr.h :functions: fpga_mgr_states diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst index 002392dab04f..fb4da4240e96 100644 --- a/Documentation/driver-api/fpga/fpga-programming.rst +++ b/Documentation/driver-api/fpga/fpga-programming.rst @@ -84,10 +84,10 @@ will generate that list. Here's some sample code of what to do next:: API for programming an FPGA --------------------------- -* fpga_region_program_fpga() — Program an FPGA -* fpga_image_info() — Specifies what FPGA image to program -* fpga_image_info_alloc() — Allocate an FPGA image info struct -* fpga_image_info_free() — Free an FPGA image info struct +* fpga_region_program_fpga() - Program an FPGA +* fpga_image_info() - Specifies what FPGA image to program +* fpga_image_info_alloc() - Allocate an FPGA image info struct +* fpga_image_info_free() - Free an FPGA image info struct .. kernel-doc:: drivers/fpga/fpga-region.c :functions: fpga_region_program_fpga diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst index 363a8171ab0a..2636a27c11b2 100644 --- a/Documentation/driver-api/fpga/fpga-region.rst +++ b/Documentation/driver-api/fpga/fpga-region.rst @@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_. API to add a new FPGA region ---------------------------- -* struct fpga_region — The FPGA region struct -* devm_fpga_region_create() — Allocate and init a region struct -* fpga_region_register() — Register an FPGA region -* fpga_region_unregister() — Unregister an FPGA region +* struct fpga_region - The FPGA region struct +* devm_fpga_region_create() - Allocate and init a region struct +* fpga_region_register() - Register an FPGA region +* fpga_region_unregister() - Unregister an FPGA region The FPGA region's probe function will need to get a reference to the FPGA Manager it will be using to do the programming. This usually would happen during the region's probe function. -* fpga_mgr_get() — Get a reference to an FPGA manager, raise ref count -* of_fpga_mgr_get() — Get a reference to an FPGA manager, raise ref count, +* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count +* of_fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count, given a device node. -* fpga_mgr_put() — Put an FPGA manager +* fpga_mgr_put() - Put an FPGA manager The FPGA region will need to specify which bridges to control while programming the FPGA. The region driver can build a list of bridges during probe time @@ -66,11 +66,11 @@ the list of bridges to program just before programming (:c:expr:`fpga_region->get_bridges`). The FPGA bridge framework supplies the following APIs to handle building or tearing down that list. -* fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a +* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a list -* of_fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a +* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a list, given a device node -* fpga_bridges_put() — Given a list of bridges, put them +* fpga_bridges_put() - Given a list of bridges, put them .. kernel-doc:: include/linux/fpga/fpga-region.h :functions: fpga_region diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst index 3366a991b4aa..47869ca8ccf0 100644 --- a/Documentation/driver-api/gpio/consumer.rst +++ b/Documentation/driver-api/gpio/consumer.rst @@ -72,6 +72,10 @@ for the GPIO. Values can be: * GPIOD_OUT_HIGH_OPEN_DRAIN same as GPIOD_OUT_HIGH but also enforce the line to be electrically used with open drain. +Note that the initial value is *logical* and the physical line level depends on +whether the line is configured active high or active low (see +:ref:`active_low_semantics`). + The two last flags are used for use cases where open drain is mandatory, such as I2C: if the line is not already configured as open drain in the mappings (see board.txt), then open drain will be enforced anyway and a warning will be @@ -252,6 +256,8 @@ that can't be accessed from hardIRQ handlers, these calls act the same as the spinlock-safe calls. +.. _active_low_semantics: + The active low and open drain semantics --------------------------------------- As a consumer should not have to care about the physical line level, all of the @@ -309,9 +315,11 @@ work on the raw line value:: void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value) int gpiod_direction_output_raw(struct gpio_desc *desc, int value) -The active low state of a GPIO can also be queried using the following call:: +The active low state of a GPIO can also be queried and toggled using the +following calls:: int gpiod_is_active_low(const struct gpio_desc *desc) + void gpiod_toggle_active_low(struct gpio_desc *desc) Note that these functions should only be used with great moderation; a driver should not have to care about the physical line level or open drain semantics. diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index d6b0d779859b..bbc53920d4dd 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -547,13 +547,10 @@ To use the helpers please keep the following in mind: the irqchip can initialize. E.g. .dev and .can_sleep shall be set up properly. -- Nominally set all handlers to handle_bad_irq() in the setup call and pass - handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is - expected for GPIO driver that irqchip .set_type() callback will be called - before using/enabling each GPIO IRQ. Then set the handler to - handle_level_irq() and/or handle_edge_irq() in the irqchip .set_type() - callback depending on what your controller supports and what is requested - by the consumer. +- Nominally set gpio_irq_chip.handler to handle_bad_irq. Then, if your irqchip + is cascaded, set the handler to handle_level_irq() and/or handle_edge_irq() + in the irqchip .set_type() callback depending on what your controller + supports and what is requested by the consumer. Locking IRQ usage diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index f5a3207aa7fa..c57c609ad2eb 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -85,7 +85,6 @@ available subsections can be seen below. io-mapping io_ordering generic-counter - lightnvm-pblk memory-devices/index men-chameleon-bus ntb diff --git a/Documentation/driver-api/lightnvm-pblk.rst b/Documentation/driver-api/lightnvm-pblk.rst deleted file mode 100644 index 1040ed1cec81..000000000000 --- a/Documentation/driver-api/lightnvm-pblk.rst +++ /dev/null @@ -1,21 +0,0 @@ -pblk: Physical Block Device Target -================================== - -pblk implements a fully associative, host-based FTL that exposes a traditional -block I/O interface. Its primary responsibilities are: - - - Map logical addresses onto physical addresses (4KB granularity) in a - logical-to-physical (L2P) table. - - Maintain the integrity and consistency of the L2P table as well as its - recovery from normal tear down and power outage. - - Deal with controller- and media-specific constrains. - - Handle I/O errors. - - Implement garbage collection. - - Maintain consistency across the I/O stack during synchronization points. - -For more information please refer to: - - http://lightnvm.io - -which maintains updated FAQs, manual pages, technical documentation, tools, -contacts, etc. diff --git a/Documentation/driver-api/media/camera-sensor.rst b/Documentation/driver-api/media/camera-sensor.rst index 7160336aa475..c7d4891bd24e 100644 --- a/Documentation/driver-api/media/camera-sensor.rst +++ b/Documentation/driver-api/media/camera-sensor.rst @@ -3,10 +3,10 @@ Writing camera sensor drivers ============================= -CSI-2 ------ +CSI-2 and parallel (BT.601 and BT.656) busses +--------------------------------------------- -Please see what is written on :ref:`MIPI_CSI_2`. +Please see :ref:`transmitter-receiver`. Handling clocks --------------- @@ -26,15 +26,16 @@ user. ACPI ~~~~ -Read the "clock-frequency" _DSD property to denote the frequency. The driver can -rely on this frequency being used. +Read the ``clock-frequency`` _DSD property to denote the frequency. The driver +can rely on this frequency being used. Devicetree ~~~~~~~~~~ -The currently preferred way to achieve this is using "assigned-clock-rates" -property. See Documentation/devicetree/bindings/clock/clock-bindings.txt for -more information. The driver then gets the frequency using clk_get_rate(). +The currently preferred way to achieve this is using ``assigned-clocks``, +``assigned-clock-parents`` and ``assigned-clock-rates`` properties. See +``Documentation/devicetree/bindings/clock/clock-bindings.txt`` for more +information. The driver then gets the frequency using ``clk_get_rate()``. This approach has the drawback that there's no guarantee that the frequency hasn't been modified directly or indirectly by another driver, or supported by @@ -55,7 +56,7 @@ processing pipeline as one or more sub-devices with different cropping and scaling configurations. The output size of the device is the result of a series of cropping and scaling operations from the device's pixel array's size. -An example of such a driver is the smiapp driver (see drivers/media/i2c/smiapp). +An example of such a driver is the CCS driver (see ``drivers/media/i2c/ccs``). Register list based drivers ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -67,7 +68,7 @@ level are independent. How a driver picks such configuration is based on the format set on a source pad at the end of the device's internal pipeline. Most sensor drivers are implemented this way, see e.g. -drivers/media/i2c/imx319.c for an example. +``drivers/media/i2c/imx319.c`` for an example. Frame interval configuration ---------------------------- @@ -94,9 +95,10 @@ large variety of devices beyond camera sensors. Devices that have no analogue crop, use the full source image size, i.e. pixel array size. Horizontal and vertical blanking are specified by ``V4L2_CID_HBLANK`` and -``V4L2_CID_VBLANK``, respectively. The unit of these controls are lines. The -pixel rate is specified by ``V4L2_CID_PIXEL_RATE`` in the same sub-device. The -unit of that control is Hz. +``V4L2_CID_VBLANK``, respectively. The unit of the ``V4L2_CID_HBLANK`` control +is pixels and the unit of the ``V4L2_CID_VBLANK`` is lines. The pixel rate in +the sensor's **pixel array** is specified by ``V4L2_CID_PIXEL_RATE`` in the same +sub-device. The unit of that control is pixels per second. Register list based drivers need to implement read-only sub-device nodes for the purpose. Devices that are not register list based need these to configure the @@ -125,14 +127,14 @@ general, the device must be powered on at least when its registers are being accessed and when it is streaming. Existing camera sensor drivers may rely on the old -:c:type:`v4l2_subdev_core_ops`->s_power() callback for bridge or ISP drivers to +struct v4l2_subdev_core_ops->s_power() callback for bridge or ISP drivers to manage their power state. This is however **deprecated**. If you feel you need to begin calling an s_power from an ISP or a bridge driver, instead please add runtime PM support to the sensor driver you are using. Likewise, new drivers should not use s_power. Please see examples in e.g. ``drivers/media/i2c/ov8856.c`` and -``drivers/media/i2c/smiapp/smiapp-core.c``. The two drivers work in both ACPI +``drivers/media/i2c/ccs/ccs-core.c``. The two drivers work in both ACPI and DT based systems. Control framework @@ -149,16 +151,3 @@ used to obtain device's power state after the power state transition: The function returns a non-zero value if it succeeded getting the power count or runtime PM was disabled, in either of which cases the driver may proceed to access the device. - -Controls --------- - -For camera sensors that are connected to a bus where transmitter and receiver -require common configuration set by drivers, such as CSI-2 or parallel (BT.601 -or BT.656) bus, the ``V4L2_CID_LINK_FREQ`` control is mandatory on transmitter -drivers. Receiver drivers can use the ``V4L2_CID_LINK_FREQ`` to query the -frequency used on the bus. - -The transmitter drivers should also implement ``V4L2_CID_PIXEL_RATE`` control in -order to tell the maximum pixel rate to the receiver. This is required on raw -camera sensors. diff --git a/Documentation/driver-api/media/cec-core.rst b/Documentation/driver-api/media/cec-core.rst index 56345eae9a26..c6194ee81c41 100644 --- a/Documentation/driver-api/media/cec-core.rst +++ b/Documentation/driver-api/media/cec-core.rst @@ -130,9 +130,12 @@ To enable/disable the hardware:: int (*adap_enable)(struct cec_adapter *adap, bool enable); This callback enables or disables the CEC hardware. Enabling the CEC hardware -means powering it up in a state where no logical addresses are claimed. This -op assumes that the physical address (adap->phys_addr) is valid when enable is -true and will not change while the CEC adapter remains enabled. The initial +means powering it up in a state where no logical addresses are claimed. The +physical address will always be valid if CEC_CAP_NEEDS_HPD is set. If that +capability is not set, then the physical address can change while the CEC +hardware is enabled. CEC drivers should not set CEC_CAP_NEEDS_HPD unless +the hardware design requires that as this will make it impossible to wake +up displays that pull the HPD low when in standby mode. The initial state of the CEC adapter after calling cec_allocate_adapter() is disabled. Note that adap_enable must return 0 if enable is false. diff --git a/Documentation/driver-api/media/csi2.rst b/Documentation/driver-api/media/csi2.rst deleted file mode 100644 index 11c52b0be8b8..000000000000 --- a/Documentation/driver-api/media/csi2.rst +++ /dev/null @@ -1,94 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -.. _MIPI_CSI_2: - -MIPI CSI-2 -========== - -CSI-2 is a data bus intended for transferring images from cameras to -the host SoC. It is defined by the `MIPI alliance`_. - -.. _`MIPI alliance`: http://www.mipi.org/ - -Media bus formats ------------------ - -See :ref:`v4l2-mbus-pixelcode` for details on which media bus formats should -be used for CSI-2 interfaces. - -Transmitter drivers -------------------- - -CSI-2 transmitter, such as a sensor or a TV tuner, drivers need to -provide the CSI-2 receiver with information on the CSI-2 bus -configuration. These include the V4L2_CID_LINK_FREQ and -V4L2_CID_PIXEL_RATE controls and -(:c:type:`v4l2_subdev_video_ops`->s_stream() callback). These -interface elements must be present on the sub-device represents the -CSI-2 transmitter. - -The V4L2_CID_LINK_FREQ control is used to tell the receiver driver the -frequency (and not the symbol rate) of the link. The V4L2_CID_PIXEL_RATE -control may be used by the receiver to obtain the pixel rate the transmitter -uses. The :c:type:`v4l2_subdev_video_ops`->s_stream() callback provides an -ability to start and stop the stream. - -The value of the V4L2_CID_PIXEL_RATE is calculated as follows:: - - pixel_rate = link_freq * 2 * nr_of_lanes * 16 / k / bits_per_sample - -where - -.. list-table:: variables in pixel rate calculation - :header-rows: 1 - - * - variable or constant - - description - * - link_freq - - The value of the V4L2_CID_LINK_FREQ integer64 menu item. - * - nr_of_lanes - - Number of data lanes used on the CSI-2 link. This can - be obtained from the OF endpoint configuration. - * - 2 - - Two bits are transferred per clock cycle per lane. - * - bits_per_sample - - Number of bits per sample. - * - k - - 16 for D-PHY and 7 for C-PHY - -The transmitter drivers must, if possible, configure the CSI-2 -transmitter to *LP-11 mode* whenever the transmitter is powered on but -not active, and maintain *LP-11 mode* until stream on. Only at stream -on should the transmitter activate the clock on the clock lane and -transition to *HS mode*. - -Some transmitters do this automatically but some have to be explicitly -programmed to do so, and some are unable to do so altogether due to -hardware constraints. - -Stopping the transmitter -^^^^^^^^^^^^^^^^^^^^^^^^ - -A transmitter stops sending the stream of images as a result of -calling the ``.s_stream()`` callback. Some transmitters may stop the -stream at a frame boundary whereas others stop immediately, -effectively leaving the current frame unfinished. The receiver driver -should not make assumptions either way, but function properly in both -cases. - -Receiver drivers ----------------- - -Before the receiver driver may enable the CSI-2 transmitter by using -the :c:type:`v4l2_subdev_video_ops`->s_stream(), it must have powered -the transmitter up by using the -:c:type:`v4l2_subdev_core_ops`->s_power() callback. This may take -place either indirectly by using :c:func:`v4l2_pipeline_pm_get` or -directly. - -Formats -------- - -The media bus pixel codes document parallel formats. Should the pixel data be -transported over a serial bus, the media bus pixel code that describes a -parallel format that transfers a sample on a single clock cycle is used. diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst index 813d7db59da7..08e206567408 100644 --- a/Documentation/driver-api/media/index.rst +++ b/Documentation/driver-api/media/index.rst @@ -37,7 +37,7 @@ Documentation/userspace-api/media/index.rst rc-core mc-core cec-core - csi2 + tx-rx camera-sensor drivers/index diff --git a/Documentation/driver-api/media/tx-rx.rst b/Documentation/driver-api/media/tx-rx.rst new file mode 100644 index 000000000000..e1e9258dd862 --- /dev/null +++ b/Documentation/driver-api/media/tx-rx.rst @@ -0,0 +1,133 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _transmitter-receiver: + +Pixel data transmitter and receiver drivers +=========================================== + +V4L2 supports various devices that transmit and receive pixel data. Examples of +these devices include a camera sensor, a TV tuner and a parallel or a CSI-2 +receiver in an SoC. + +Bus types +--------- + +The following busses are the most common. This section discusses these two only. + +MIPI CSI-2 +^^^^^^^^^^ + +CSI-2 is a data bus intended for transferring images from cameras to +the host SoC. It is defined by the `MIPI alliance`_. + +.. _`MIPI alliance`: https://www.mipi.org/ + +Parallel +^^^^^^^^ + +`BT.601`_ and `BT.656`_ are the most common parallel busses. + +.. _`BT.601`: https://en.wikipedia.org/wiki/Rec._601 +.. _`BT.656`: https://en.wikipedia.org/wiki/ITU-R_BT.656 + +Transmitter drivers +------------------- + +Transmitter drivers generally need to provide the receiver drivers with the +configuration of the transmitter. What is required depends on the type of the +bus. These are common for both busses. + +Media bus pixel code +^^^^^^^^^^^^^^^^^^^^ + +See :ref:`v4l2-mbus-pixelcode`. + +Link frequency +^^^^^^^^^^^^^^ + +The :ref:`V4L2_CID_LINK_FREQ <v4l2-cid-link-freq>` control is used to tell the +receiver the frequency of the bus (i.e. it is not the same as the symbol rate). + +``.s_stream()`` callback +^^^^^^^^^^^^^^^^^^^^^^^^ + +The struct struct v4l2_subdev_video_ops->s_stream() callback is used by the +receiver driver to control the transmitter driver's streaming state. + + +CSI-2 transmitter drivers +------------------------- + +Pixel rate +^^^^^^^^^^ + +The pixel rate on the bus is calculated as follows:: + + pixel_rate = link_freq * 2 * nr_of_lanes * 16 / k / bits_per_sample + +where + +.. list-table:: variables in pixel rate calculation + :header-rows: 1 + + * - variable or constant + - description + * - link_freq + - The value of the ``V4L2_CID_LINK_FREQ`` integer64 menu item. + * - nr_of_lanes + - Number of data lanes used on the CSI-2 link. This can + be obtained from the OF endpoint configuration. + * - 2 + - Data is transferred on both rising and falling edge of the signal. + * - bits_per_sample + - Number of bits per sample. + * - k + - 16 for D-PHY and 7 for C-PHY + +.. note:: + + The pixel rate calculated this way is **not** the same thing as the + pixel rate on the camera sensor's pixel array which is indicated by the + :ref:`V4L2_CID_PIXEL_RATE <v4l2-cid-pixel-rate>` control. + +LP-11 and LP-111 modes +^^^^^^^^^^^^^^^^^^^^^^ + +As part of transitioning to high speed mode, a CSI-2 transmitter typically +briefly sets the bus to LP-11 or LP-111 state, depending on the PHY. This period +may be as short as 100 µs, during which the receiver observes this state and +proceeds its own part of high speed mode transition. + +Most receivers are capable of autonomously handling this once the software has +configured them to do so, but there are receivers which require software +involvement in observing LP-11 or LP-111 state. 100 µs is a brief period to hit +in software, especially when there is no interrupt telling something is +happening. + +One way to address this is to configure the transmitter side explicitly to LP-11 +or LP-111 mode, which requires support from the transmitter hardware. This is +not universally available. Many devices return to this state once streaming is +stopped while the state after power-on is LP-00 or LP-000. + +The ``.pre_streamon()`` callback may be used to prepare a transmitter for +transitioning to streaming state, but not yet start streaming. Similarly, the +``.post_streamoff()`` callback is used to undo what was done by the +``.pre_streamon()`` callback. The caller of ``.pre_streamon()`` is thus required +to call ``.post_streamoff()`` for each successful call of ``.pre_streamon()``. + +In the context of CSI-2, the ``.pre_streamon()`` callback is used to transition +the transmitter to the LP-11 or LP-111 mode. This also requires powering on the +device, so this should be only done when it is needed. + +Receiver drivers that do not need explicit LP-11 or LP-111 mode setup are waived +from calling the two callbacks. + +Stopping the transmitter +^^^^^^^^^^^^^^^^^^^^^^^^ + +A transmitter stops sending the stream of images as a result of +calling the ``.s_stream()`` callback. Some transmitters may stop the +stream at a frame boundary whereas others stop immediately, +effectively leaving the current frame unfinished. The receiver driver +should not make assumptions either way, but function properly in both +cases. diff --git a/Documentation/driver-api/nfc/nfc-hci.rst b/Documentation/driver-api/nfc/nfc-hci.rst index eb8a1a14e919..f10fe53aa9fe 100644 --- a/Documentation/driver-api/nfc/nfc-hci.rst +++ b/Documentation/driver-api/nfc/nfc-hci.rst @@ -181,7 +181,7 @@ xmit_from_hci(): The llc must be registered with nfc before it can be used. Do that by calling:: - nfc_llc_register(const char *name, struct nfc_llc_ops *ops); + nfc_llc_register(const char *name, const struct nfc_llc_ops *ops); Again, note that the llc does not handle the physical link. It is thus very easy to mix any physical link with any llc for a given chip driver. diff --git a/Documentation/driver-api/thermal/nouveau_thermal.rst b/Documentation/driver-api/thermal/nouveau_thermal.rst index 79ece266cf6d..aa10db6df309 100644 --- a/Documentation/driver-api/thermal/nouveau_thermal.rst +++ b/Documentation/driver-api/thermal/nouveau_thermal.rst @@ -90,7 +90,7 @@ Bug reports ----------- Thermal management on Nouveau is new and may not work on all cards. If you have -inquiries, please ping mupuf on IRC (#nouveau, freenode). +inquiries, please ping mupuf on IRC (#nouveau, OFTC). Bug reports should be filled on Freedesktop's bug tracker. Please follow https://nouveau.freedesktop.org/wiki/Bugs diff --git a/Documentation/driver-api/vfio.rst b/Documentation/driver-api/vfio.rst index 606eed8823ce..c663b6f97825 100644 --- a/Documentation/driver-api/vfio.rst +++ b/Documentation/driver-api/vfio.rst @@ -255,11 +255,13 @@ vfio_unregister_group_dev() respectively:: void vfio_init_group_dev(struct vfio_device *device, struct device *dev, const struct vfio_device_ops *ops); + void vfio_uninit_group_dev(struct vfio_device *device); int vfio_register_group_dev(struct vfio_device *device); void vfio_unregister_group_dev(struct vfio_device *device); The driver should embed the vfio_device in its own structure and call -vfio_init_group_dev() to pre-configure it before going to registration. +vfio_init_group_dev() to pre-configure it before going to registration +and call vfio_uninit_group_dev() after completing the un-registration. vfio_register_group_dev() indicates to the core to begin tracking the iommu_group of the specified dev and register the dev as owned by a VFIO bus driver. Once vfio_register_group_dev() returns it is possible for userspace to diff --git a/Documentation/fault-injection/fault-injection.rst b/Documentation/fault-injection/fault-injection.rst index f47d05ed0d94..4a25c5eb6f07 100644 --- a/Documentation/fault-injection/fault-injection.rst +++ b/Documentation/fault-injection/fault-injection.rst @@ -24,6 +24,10 @@ Available fault injection capabilities injects futex deadlock and uaddr fault errors. +- fail_sunrpc + + injects kernel RPC client and server failures. + - fail_make_request injects disk IO errors on devices permitted by setting @@ -151,6 +155,20 @@ configuration of fault-injection capabilities. default is 'N', setting it to 'Y' will disable failure injections when dealing with private (address space) futexes. +- /sys/kernel/debug/fail_sunrpc/ignore-client-disconnect: + + Format: { 'Y' | 'N' } + + default is 'N', setting it to 'Y' will disable disconnect + injection on the RPC client. + +- /sys/kernel/debug/fail_sunrpc/ignore-server-disconnect: + + Format: { 'Y' | 'N' } + + default is 'N', setting it to 'Y' will disable disconnect + injection on the RPC server. + - /sys/kernel/debug/fail_function/inject: Format: { 'function-name' | '!function-name' | '' } diff --git a/Documentation/fault-injection/provoke-crashes.rst b/Documentation/fault-injection/provoke-crashes.rst index a20ba5d93932..3abe84225613 100644 --- a/Documentation/fault-injection/provoke-crashes.rst +++ b/Documentation/fault-injection/provoke-crashes.rst @@ -29,8 +29,7 @@ recur_count cpoint_name Where in the kernel to trigger the action. It can be one of INT_HARDWARE_ENTRY, INT_HW_IRQ_EN, INT_TASKLET_ENTRY, - FS_DEVRW, MEM_SWAPOUT, TIMERADD, SCSI_DISPATCH_CMD, - IDE_CORE_CP, or DIRECT + FS_DEVRW, MEM_SWAPOUT, TIMERADD, SCSI_QUEUE_RQ, or DIRECT. cpoint_type Indicates the action to be taken on hitting the crash point. diff --git a/Documentation/filesystems/cifs/index.rst b/Documentation/filesystems/cifs/index.rst new file mode 100644 index 000000000000..1c8597a679ab --- /dev/null +++ b/Documentation/filesystems/cifs/index.rst @@ -0,0 +1,10 @@ +=============================== +CIFS +=============================== + + +.. toctree:: + :maxdepth: 1 + + ksmbd + cifsroot diff --git a/Documentation/filesystems/cifs/ksmbd.rst b/Documentation/filesystems/cifs/ksmbd.rst new file mode 100644 index 000000000000..a1326157d53f --- /dev/null +++ b/Documentation/filesystems/cifs/ksmbd.rst @@ -0,0 +1,165 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +KSMBD - SMB3 Kernel Server +========================== + +KSMBD is a linux kernel server which implements SMB3 protocol in kernel space +for sharing files over network. + +KSMBD architecture +================== + +The subset of performance related operations belong in kernelspace and +the other subset which belong to operations which are not really related with +performance in userspace. So, DCE/RPC management that has historically resulted +into number of buffer overflow issues and dangerous security bugs and user +account management are implemented in user space as ksmbd.mountd. +File operations that are related with performance (open/read/write/close etc.) +in kernel space (ksmbd). This also allows for easier integration with VFS +interface for all file operations. + +ksmbd (kernel daemon) +--------------------- + +When the server daemon is started, It starts up a forker thread +(ksmbd/interface name) at initialization time and open a dedicated port 445 +for listening to SMB requests. Whenever new clients make request, Forker +thread will accept the client connection and fork a new thread for dedicated +communication channel between the client and the server. It allows for parallel +processing of SMB requests(commands) from clients as well as allowing for new +clients to make new connections. Each instance is named ksmbd/1~n(port number) +to indicate connected clients. Depending on the SMB request types, each new +thread can decide to pass through the commands to the user space (ksmbd.mountd), +currently DCE/RPC commands are identified to be handled through the user space. +To further utilize the linux kernel, it has been chosen to process the commands +as workitems and to be executed in the handlers of the ksmbd-io kworker threads. +It allows for multiplexing of the handlers as the kernel take care of initiating +extra worker threads if the load is increased and vice versa, if the load is +decreased it destroys the extra worker threads. So, after connection is +established with client. Dedicated ksmbd/1..n(port number) takes complete +ownership of receiving/parsing of SMB commands. Each received command is worked +in parallel i.e., There can be multiple clients commands which are worked in +parallel. After receiving each command a separated kernel workitem is prepared +for each command which is further queued to be handled by ksmbd-io kworkers. +So, each SMB workitem is queued to the kworkers. This allows the benefit of load +sharing to be managed optimally by the default kernel and optimizing client +performance by handling client commands in parallel. + +ksmbd.mountd (user space daemon) +-------------------------------- + +ksmbd.mountd is userspace process to, transfer user account and password that +are registered using ksmbd.adduser(part of utils for user space). Further it +allows sharing information parameters that parsed from smb.conf to ksmbd in +kernel. For the execution part it has a daemon which is continuously running +and connected to the kernel interface using netlink socket, it waits for the +requests(dcerpc and share/user info). It handles RPC calls (at a minimum few +dozen) that are most important for file server from NetShareEnum and +NetServerGetInfo. Complete DCE/RPC response is prepared from the user space +and passed over to the associated kernel thread for the client. + + +KSMBD Feature Status +==================== + +============================== ================================================= +Feature name Status +============================== ================================================= +Dialects Supported. SMB2.1 SMB3.0, SMB3.1.1 dialects + (intentionally excludes security vulnerable SMB1 + dialect). +Auto Negotiation Supported. +Compound Request Supported. +Oplock Cache Mechanism Supported. +SMB2 leases(v1 lease) Supported. +Directory leases(v2 lease) Planned for future. +Multi-credits Supported. +NTLM/NTLMv2 Supported. +HMAC-SHA256 Signing Supported. +Secure negotiate Supported. +Signing Update Supported. +Pre-authentication integrity Supported. +SMB3 encryption(CCM, GCM) Supported. (CCM and GCM128 supported, GCM256 in + progress) +SMB direct(RDMA) Partially Supported. SMB3 Multi-channel is + required to connect to Windows client. +SMB3 Multi-channel Partially Supported. Planned to implement + replay/retry mechanisms for future. +SMB3.1.1 POSIX extension Supported. +ACLs Partially Supported. only DACLs available, SACLs + (auditing) is planned for the future. For + ownership (SIDs) ksmbd generates random subauth + values(then store it to disk) and use uid/gid + get from inode as RID for local domain SID. + The current acl implementation is limited to + standalone server, not a domain member. + Integration with Samba tools is being worked on + to allow future support for running as a domain + member. +Kerberos Supported. +Durable handle v1,v2 Planned for future. +Persistent handle Planned for future. +SMB2 notify Planned for future. +Sparse file support Supported. +DCE/RPC support Partially Supported. a few calls(NetShareEnumAll, + NetServerGetInfo, SAMR, LSARPC) that are needed + for file server handled via netlink interface + from ksmbd.mountd. Additional integration with + Samba tools and libraries via upcall is being + investigated to allow support for additional + DCE/RPC management calls (and future support + for Witness protocol e.g.) +ksmbd/nfsd interoperability Planned for future. The features that ksmbd + support are Leases, Notify, ACLs and Share modes. +============================== ================================================= + + +How to run +========== + +1. Download ksmbd-tools and compile them. + - https://github.com/cifsd-team/ksmbd-tools + +2. Create user/password for SMB share. + + # mkdir /etc/ksmbd/ + # ksmbd.adduser -a <Enter USERNAME for SMB share access> + +3. Create /etc/ksmbd/smb.conf file, add SMB share in smb.conf file + - Refer smb.conf.example and + https://github.com/cifsd-team/ksmbd-tools/blob/master/Documentation/configuration.txt + +4. Insert ksmbd.ko module + + # insmod ksmbd.ko + +5. Start ksmbd user space daemon + # ksmbd.mountd + +6. Access share from Windows or Linux using CIFS + +Shutdown KSMBD +============== + +1. kill user and kernel space daemon + # sudo ksmbd.control -s + +How to turn debug print on +========================== + +Each layer +/sys/class/ksmbd-control/debug + +1. Enable all component prints + # sudo ksmbd.control -d "all" + +2. Enable one of components(smb, auth, vfs, oplock, ipc, conn, rdma) + # sudo ksmbd.control -d "smb" + +3. Show what prints are enable. + # cat/sys/class/ksmbd-control/debug + [smb] auth vfs oplock ipc conn [rdma] + +4. Disable prints: + If you try the selected component once more, It is disabled without brackets. diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index 832839fcf4c3..b97579b7d8fb 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -84,6 +84,9 @@ cache_strategy=%s Select a strategy for cached decompression from now on: It still does in-place I/O decompression for the rest compressed physical clusters. ========== ============================================= +dax={always,never} Use direct access (no page cache). See + Documentation/filesystems/dax.rst. +dax A legacy option which is an alias for ``dax=always``. =================== ========================================================= On-disk details @@ -153,13 +156,14 @@ may not. All metadatas can be now observed in two different spaces (views): Xattrs, extents, data inline are followed by the corresponding inode with proper alignment, and they could be optional for different data mappings. - _currently_ total 4 valid data mappings are supported: + _currently_ total 5 data layouts are supported: == ==================================================================== 0 flat file data without data inline (no extent); 1 fixed-sized output data compression (with non-compacted indexes); 2 flat file data with tail packing data inline (no extent); - 3 fixed-sized output data compression (with compacted indexes, v5.3+). + 3 fixed-sized output data compression (with compacted indexes, v5.3+); + 4 chunk-based file (v5.15+). == ==================================================================== The size of the optional xattrs is indicated by i_xattr_count in inode @@ -210,6 +214,17 @@ Note that apart from the offset of the first filename, nameoff0 also indicates the total number of directory entries in this block since it is no need to introduce another on-disk field at all. +Chunk-based file +---------------- +In order to support chunk-based data deduplication, a new inode data layout has +been supported since Linux v5.15: Files are split in equal-sized data chunks +with ``extents`` area of the inode metadata indicating how to get the chunk +data: these can be simply as a 4-byte block address array or in the 8-byte +chunk index form (see struct erofs_inode_chunk_index in erofs_fs.h for more +details.) + +By the way, chunk-based files are all uncompressed for now. + Data compression ---------------- EROFS implements LZ4 fixed-sized output compression which generates fixed-sized diff --git a/Documentation/filesystems/ext4/globals.rst b/Documentation/filesystems/ext4/globals.rst index 368bf7662b96..b17418974fd3 100644 --- a/Documentation/filesystems/ext4/globals.rst +++ b/Documentation/filesystems/ext4/globals.rst @@ -11,3 +11,4 @@ have static metadata at fixed locations. .. include:: bitmaps.rst .. include:: mmp.rst .. include:: journal.rst +.. include:: orphan.rst diff --git a/Documentation/filesystems/ext4/inodes.rst b/Documentation/filesystems/ext4/inodes.rst index a65baffb4ebf..6c5ce666e63f 100644 --- a/Documentation/filesystems/ext4/inodes.rst +++ b/Documentation/filesystems/ext4/inodes.rst @@ -498,11 +498,11 @@ structure -- inode change time (ctime), access time (atime), data modification time (mtime), and deletion time (dtime). The four fields are 32-bit signed integers that represent seconds since the Unix epoch (1970-01-01 00:00:00 GMT), which means that the fields will overflow in -January 2038. For inodes that are not linked from any directory but are -still open (orphan inodes), the dtime field is overloaded for use with -the orphan list. The superblock field ``s_last_orphan`` points to the -first inode in the orphan list; dtime is then the number of the next -orphaned inode, or zero if there are no more orphans. +January 2038. If the filesystem does not have orphan_file feature, inodes +that are not linked from any directory but are still open (orphan inodes) have +the dtime field overloaded for use with the orphan list. The superblock field +``s_last_orphan`` points to the first inode in the orphan list; dtime is then +the number of the next orphaned inode, or zero if there are no more orphans. If the inode structure size ``sb->s_inode_size`` is larger than 128 bytes and the ``i_inode_extra`` field is large enough to encompass the diff --git a/Documentation/filesystems/ext4/orphan.rst b/Documentation/filesystems/ext4/orphan.rst new file mode 100644 index 000000000000..bb19ecd1b626 --- /dev/null +++ b/Documentation/filesystems/ext4/orphan.rst @@ -0,0 +1,52 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Orphan file +----------- + +In unix there can inodes that are unlinked from directory hierarchy but that +are still alive because they are open. In case of crash the filesystem has to +clean up these inodes as otherwise they (and the blocks referenced from them) +would leak. Similarly if we truncate or extend the file, we need not be able +to perform the operation in a single journalling transaction. In such case we +track the inode as orphan so that in case of crash extra blocks allocated to +the file get truncated. + +Traditionally ext4 tracks orphan inodes in a form of single linked list where +superblock contains the inode number of the last orphan inode (s\_last\_orphan +field) and then each inode contains inode number of the previously orphaned +inode (we overload i\_dtime inode field for this). However this filesystem +global single linked list is a scalability bottleneck for workloads that result +in heavy creation of orphan inodes. When orphan file feature +(COMPAT\_ORPHAN\_FILE) is enabled, the filesystem has a special inode +(referenced from the superblock through s\_orphan_file_inum) with several +blocks. Each of these blocks has a structure: + +.. list-table:: + :widths: 8 8 24 40 + :header-rows: 1 + + * - Offset + - Type + - Name + - Description + * - 0x0 + - Array of \_\_le32 entries + - Orphan inode entries + - Each \_\_le32 entry is either empty (0) or it contains inode number of + an orphan inode. + * - blocksize - 8 + - \_\_le32 + - ob\_magic + - Magic value stored in orphan block tail (0x0b10ca04) + * - blocksize - 4 + - \_\_le32 + - ob\_checksum + - Checksum of the orphan block. + +When a filesystem with orphan file feature is writeably mounted, we set +RO\_COMPAT\_ORPHAN\_PRESENT feature in the superblock to indicate there may +be valid orphan entries. In case we see this feature when mounting the +filesystem, we read the whole orphan file and process all orphan inodes found +there as usual. When cleanly unmounting the filesystem we remove the +RO\_COMPAT\_ORPHAN\_PRESENT feature to avoid unnecessary scanning of the orphan +file and also make the filesystem fully compatible with older kernels. diff --git a/Documentation/filesystems/ext4/special_inodes.rst b/Documentation/filesystems/ext4/special_inodes.rst index 9061aabba827..94f304e3a0a7 100644 --- a/Documentation/filesystems/ext4/special_inodes.rst +++ b/Documentation/filesystems/ext4/special_inodes.rst @@ -36,3 +36,20 @@ ext4 reserves some inode for special features, as follows: * - 11 - Traditional first non-reserved inode. Usually this is the lost+found directory. See s\_first\_ino in the superblock. +Note that there are also some inodes allocated from non-reserved inode numbers +for other filesystem features which are not referenced from standard directory +hierarchy. These are generally reference from the superblock. They are: + +.. list-table:: + :widths: 20 50 + :header-rows: 1 + + * - Superblock field + - Description + + * - s\_lpf\_ino + - Inode number of lost+found directory. + * - s\_prj\_quota\_inum + - Inode number of quota file tracking project quotas + * - s\_orphan\_file\_inum + - Inode number of file tracking orphan inodes. diff --git a/Documentation/filesystems/ext4/super.rst b/Documentation/filesystems/ext4/super.rst index 2eb1ab20498d..f6a548e957bb 100644 --- a/Documentation/filesystems/ext4/super.rst +++ b/Documentation/filesystems/ext4/super.rst @@ -479,7 +479,11 @@ The ext4 superblock is laid out as follows in - Filename charset encoding flags. * - 0x280 - \_\_le32 - - s\_reserved[95] + - s\_orphan\_file\_inum + - Orphan file inode number. + * - 0x284 + - \_\_le32 + - s\_reserved[94] - Padding to the end of the block. * - 0x3FC - \_\_le32 @@ -603,6 +607,11 @@ following: the journal, JBD2 incompat feature (JBD2\_FEATURE\_INCOMPAT\_FAST\_COMMIT) gets set (COMPAT\_FAST\_COMMIT). + * - 0x1000 + - Orphan file allocated. This is the special file for more efficient + tracking of unlinked but still open inodes. When there may be any + entries in the file, we additionally set proper rocompat feature + (RO\_COMPAT\_ORPHAN\_PRESENT). .. _super_incompat: @@ -713,6 +722,10 @@ the following: - Filesystem tracks project quotas. (RO\_COMPAT\_PROJECT) * - 0x8000 - Verity inodes may be present on the filesystem. (RO\_COMPAT\_VERITY) + * - 0x10000 + - Indicates orphan file may have valid orphan entries and thus we need + to clean them up when mounting the filesystem + (RO\_COMPAT\_ORPHAN\_PRESENT). .. _super_def_hash: diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index ff9e7cc97c65..09de6ebbbdfa 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -185,6 +185,7 @@ fault_type=%d Support configuring fault injection type, should be FAULT_KVMALLOC 0x000000002 FAULT_PAGE_ALLOC 0x000000004 FAULT_PAGE_GET 0x000000008 + FAULT_ALLOC_BIO 0x000000010 (obsolete) FAULT_ALLOC_NID 0x000000020 FAULT_ORPHAN 0x000000040 FAULT_BLOCK 0x000000080 @@ -195,6 +196,7 @@ fault_type=%d Support configuring fault injection type, should be FAULT_CHECKPOINT 0x000001000 FAULT_DISCARD 0x000002000 FAULT_WRITE_IO 0x000004000 + FAULT_SLAB_ALLOC 0x000008000 =================== =========== mode=%s Control block allocation mode which supports "adaptive" and "lfs". In "lfs" mode, there should be no random @@ -312,6 +314,14 @@ inlinecrypt When possible, encrypt/decrypt the contents of encrypted Documentation/block/inline-encryption.rst. atgc Enable age-threshold garbage collection, it provides high effectiveness and efficiency on background GC. +discard_unit=%s Control discard unit, the argument can be "block", "segment" + and "section", issued discard command's offset/size will be + aligned to the unit, by default, "discard_unit=block" is set, + so that small discard functionality is enabled. + For blkzoned device, "discard_unit=section" will be set by + default, it is helpful for large sized SMR or ZNS devices to + reduce memory cost by getting rid of fs metadata supports small + discard. ======================== ============================================================ Debugfs Entries @@ -857,8 +867,11 @@ Compression implementation directly in order to guarantee potential data updates later to the space. Instead, the main goal is to reduce data writes to flash disk as much as possible, resulting in extending disk life time as well as relaxing IO - congestion. Alternatively, we've added ioctl interface to reclaim compressed - space and show it to user after putting the immutable bit. + congestion. Alternatively, we've added ioctl(F2FS_IOC_RELEASE_COMPRESS_BLOCKS) + interface to reclaim compressed space and show it to user after putting the + immutable bit. Immutable bit, after release, it doesn't allow writing/mmaping + on the file, until reserving compressed space via + ioctl(F2FS_IOC_RESERVE_COMPRESS_BLOCKS) or truncating filesize to zero. Compress metadata layout:: diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 44b67ebd6e40..0eb799d9d05a 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -1063,11 +1063,6 @@ astute users may notice some differences in behavior: - DAX (Direct Access) is not supported on encrypted files. -- The st_size of an encrypted symlink will not necessarily give the - length of the symlink target as required by POSIX. It will actually - give the length of the ciphertext, which will be slightly longer - than the plaintext due to NUL-padding and an extra 2-byte overhead. - - The maximum length of an encrypted symlink is 2 bytes shorter than the maximum length of an unencrypted symlink. For example, on an EXT4 filesystem with a 4K block size, unencrypted symlinks can be up @@ -1235,12 +1230,12 @@ the user-supplied name to get the ciphertext. Lookups without the key are more complicated. The raw ciphertext may contain the ``\0`` and ``/`` characters, which are illegal in -filenames. Therefore, readdir() must base64-encode the ciphertext for -presentation. For most filenames, this works fine; on ->lookup(), the -filesystem just base64-decodes the user-supplied name to get back to -the raw ciphertext. +filenames. Therefore, readdir() must base64url-encode the ciphertext +for presentation. For most filenames, this works fine; on ->lookup(), +the filesystem just base64url-decodes the user-supplied name to get +back to the raw ciphertext. -However, for very long filenames, base64 encoding would cause the +However, for very long filenames, base64url encoding would cause the filename length to exceed NAME_MAX. To prevent this, readdir() actually presents long filenames in an abbreviated form which encodes a strong "hash" of the ciphertext filename, along with the optional diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst new file mode 100644 index 000000000000..1229a75ec75d --- /dev/null +++ b/Documentation/filesystems/idmappings.rst @@ -0,0 +1,1026 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Idmappings +========== + +Most filesystem developers will have encountered idmappings. They are used when +reading from or writing ownership to disk, reporting ownership to userspace, or +for permission checking. This document is aimed at filesystem developers that +want to know how idmappings work. + +Formal notes +------------ + +An idmapping is essentially a translation of a range of ids into another or the +same range of ids. The notational convention for idmappings that is widely used +in userspace is:: + + u:k:r + +``u`` indicates the first element in the upper idmapset ``U`` and ``k`` +indicates the first element in the lower idmapset ``K``. The ``r`` parameter +indicates the range of the idmapping, i.e. how many ids are mapped. From now +on, we will always prefix ids with ``u`` or ``k`` to make it clear whether +we're talking about an id in the upper or lower idmapset. + +To see what this looks like in practice, let's take the following idmapping:: + + u22:k10000:r3 + +and write down the mappings it will generate:: + + u22 -> k10000 + u23 -> k10001 + u24 -> k10002 + +From a mathematical viewpoint ``U`` and ``K`` are well-ordered sets and an +idmapping is an order isomorphism from ``U`` into ``K``. So ``U`` and ``K`` are +order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of +the set of all possible ids useable on a given system. + +Looking at this mathematically briefly will help us highlight some properties +that make it easier to understand how we can translate between idmappings. For +example, we know that the inverse idmapping is an order isomorphism as well:: + + k10000 -> u22 + k10001 -> u23 + k10002 -> u24 + +Given that we are dealing with order isomorphisms plus the fact that we're +dealing with subsets we can embedd idmappings into each other, i.e. we can +sensibly translate between different idmappings. For example, assume we've been +given the three idmappings:: + + 1. u0:k10000:r10000 + 2. u0:k20000:r10000 + 3. u0:k30000:r10000 + +and id ``k11000`` which has been generated by the first idmapping by mapping +``u1000`` from the upper idmapset down to ``k11000`` in the lower idmapset. + +Because we're dealing with order isomorphic subsets it is meaningful to ask +what id ``k11000`` corresponds to in the second or third idmapping. The +straightfoward algorithm to use is to apply the inverse of the first idmapping, +mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using +either the second idmapping mapping or third idmapping mapping. The second +idmapping would map ``u1000`` down to ``21000``. The third idmapping would map +``u1000`` down to ``u31000``. + +If we were given the same task for the following three idmappings:: + + 1. u0:k10000:r10000 + 2. u0:k20000:r200 + 3. u0:k30000:r300 + +we would fail to translate as the sets aren't order isomorphic over the full +range of the first idmapping anymore (However they are order isomorphic over +the full range of the second idmapping.). Neither the second or third idmapping +contain ``u1000`` in the upper idmapset ``U``. This is equivalent to not having +an id mapped. We can simply say that ``u1000`` is unmapped in the second and +third idmapping. The kernel will report unmapped ids as the overflowuid +``(uid_t)-1`` or overflowgid ``(gid_t)-1`` to userspace. + +The algorithm to calculate what a given id maps to is pretty simple. First, we +need to verify that the range can contain our target id. We will skip this step +for simplicity. After that if we want to know what ``id`` maps to we can do +simple calculations: + +- If we want to map from left to right:: + + u:k:r + id - u + k = n + +- If we want to map from right to left:: + + u:k:r + id - k + u = n + +Instead of "left to right" we can also say "down" and instead of "right to +left" we can also say "up". Obviously mapping down and up invert each other. + +To see whether the simple formulas above work, consider the following two +idmappings:: + + 1. u0:k20000:r10000 + 2. u500:k30000:r10000 + +Assume we are given ``k21000`` in the lower idmapset of the first idmapping. We +want to know what id this was mapped from in the upper idmapset of the first +idmapping. So we're mapping up in the first idmapping:: + + id - k + u = n + k21000 - k20000 + u0 = u1000 + +Now assume we are given the id ``u1100`` in the upper idmapset of the second +idmapping and we want to know what this id maps down to in the lower idmapset +of the second idmapping. This means we're mapping down in the second +idmapping:: + + id - u + k = n + u1100 - u500 + k30000 = k30600 + +General notes +------------- + +In the context of the kernel an idmapping can be interpreted as mapping a range +of userspace ids into a range of kernel ids:: + + userspace-id:kernel-id:range + +A userspace id is always an element in the upper idmapset of an idmapping of +type ``uid_t`` or ``gid_t`` and a kernel id is always an element in the lower +idmapset of an idmapping of type ``kuid_t`` or ``kgid_t``. From now on +"userspace id" will be used to refer to the well known ``uid_t`` and ``gid_t`` +types and "kernel id" will be used to refer to ``kuid_t`` and ``kgid_t``. + +The kernel is mostly concerned with kernel ids. They are used when performing +permission checks and are stored in an inode's ``i_uid`` and ``i_gid`` field. +A userspace id on the other hand is an id that is reported to userspace by the +kernel, or is passed by userspace to the kernel, or a raw device id that is +written or read from disk. + +Note that we are only concerned with idmappings as the kernel stores them not +how userspace would specify them. + +For the rest of this document we will prefix all userspace ids with ``u`` and +all kernel ids with ``k``. Ranges of idmappings will be prefixed with ``r``. So +an idmapping will be written as ``u0:k10000:r10000``. + +For example, the id ``u1000`` is an id in the upper idmapset or "userspace +idmapset" starting with ``u1000``. And it is mapped to ``k11000`` which is a +kernel id in the lower idmapset or "kernel idmapset" starting with ``k10000``. + +A kernel id is always created by an idmapping. Such idmappings are associated +with user namespaces. Since we mainly care about how idmappings work we're not +going to be concerned with how idmappings are created nor how they are used +outside of the filesystem context. This is best left to an explanation of user +namespaces. + +The initial user namespace is special. It always has an idmapping of the +following form:: + + u0:k0:r4294967295 + +which is an identity idmapping over the full range of ids available on this +system. + +Other user namespaces usually have non-identity idmappings such as:: + + u0:k10000:r10000 + +When a process creates or wants to change ownership of a file, or when the +ownership of a file is read from disk by a filesystem, the userspace id is +immediately translated into a kernel id according to the idmapping associated +with the relevant user namespace. + +For instance, consider a file that is stored on disk by a filesystem as being +owned by ``u1000``: + +- If a filesystem were to be mounted in the initial user namespaces (as most + filesystems are) then the initial idmapping will be used. As we saw this is + simply the identity idmapping. This would mean id ``u1000`` read from disk + would be mapped to id ``k1000``. So an inode's ``i_uid`` and ``i_gid`` field + would contain ``k1000``. + +- If a filesystem were to be mounted with an idmapping of ``u0:k10000:r10000`` + then ``u1000`` read from disk would be mapped to ``k11000``. So an inode's + ``i_uid`` and ``i_gid`` would contain ``k11000``. + +Translation algorithms +---------------------- + +We've already seen briefly that it is possible to translate between different +idmappings. We'll now take a closer look how that works. + +Crossmapping +~~~~~~~~~~~~ + +This translation algorithm is used by the kernel in quite a few places. For +example, it is used when reporting back the ownership of a file to userspace +via the ``stat()`` system call family. + +If we've been given ``k11000`` from one idmapping we can map that id up in +another idmapping. In order for this to work both idmappings need to contain +the same kernel id in their kernel idmapsets. For example, consider the +following idmappings:: + + 1. u0:k10000:r10000 + 2. u20000:k10000:r10000 + +and we are mapping ``u1000`` down to ``k11000`` in the first idmapping . We can +then translate ``k11000`` into a userspace id in the second idmapping using the +kernel idmapset of the second idmapping:: + + /* Map the kernel id up into a userspace id in the second idmapping. */ + from_kuid(u20000:k10000:r10000, k11000) = u21000 + +Note, how we can get back to the kernel id in the first idmapping by inverting +the algorithm:: + + /* Map the userspace id down into a kernel id in the second idmapping. */ + make_kuid(u20000:k10000:r10000, u21000) = k11000 + + /* Map the kernel id up into a userspace id in the first idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + +This algorithm allows us to answer the question what userspace id a given +kernel id corresponds to in a given idmapping. In order to be able to answer +this question both idmappings need to contain the same kernel id in their +respective kernel idmapsets. + +For example, when the kernel reads a raw userspace id from disk it maps it down +into a kernel id according to the idmapping associated with the filesystem. +Let's assume the filesystem was mounted with an idmapping of +``u0:k20000:r10000`` and it reads a file owned by ``u1000`` from disk. This +means ``u1000`` will be mapped to ``k21000`` which is what will be stored in +the inode's ``i_uid`` and ``i_gid`` field. + +When someone in userspace calls ``stat()`` or a related function to get +ownership information about the file the kernel can't simply map the id back up +according to the filesystem's idmapping as this would give the wrong owner if +the caller is using an idmapping. + +So the kernel will map the id back up in the idmapping of the caller. Let's +assume the caller has the slighly unconventional idmapping +``u3000:k20000:r10000`` then ``k21000`` would map back up to ``u4000``. +Consequently the user would see that this file is owned by ``u4000``. + +Remapping +~~~~~~~~~ + +It is possible to translate a kernel id from one idmapping to another one via +the userspace idmapset of the two idmappings. This is equivalent to remapping +a kernel id. + +Let's look at an example. We are given the following two idmappings:: + + 1. u0:k10000:r10000 + 2. u0:k20000:r10000 + +and we are given ``k11000`` in the first idmapping. In order to translate this +kernel id in the first idmapping into a kernel id in the second idmapping we +need to perform two steps: + +1. Map the kernel id up into a userspace id in the first idmapping:: + + /* Map the kernel id up into a userspace id in the first idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + +2. Map the userspace id down into a kernel id in the second idmapping:: + + /* Map the userspace id down into a kernel id in the second idmapping. */ + make_kuid(u0:k20000:r10000, u1000) = k21000 + +As you can see we used the userspace idmapset in both idmappings to translate +the kernel id in one idmapping to a kernel id in another idmapping. + +This allows us to answer the question what kernel id we would need to use to +get the same userspace id in another idmapping. In order to be able to answer +this question both idmappings need to contain the same userspace id in their +respective userspace idmapsets. + +Note, how we can easily get back to the kernel id in the first idmapping by +inverting the algorithm: + +1. Map the kernel id up into a userspace id in the second idmapping:: + + /* Map the kernel id up into a userspace id in the second idmapping. */ + from_kuid(u0:k20000:r10000, k21000) = u1000 + +2. Map the userspace id down into a kernel id in the first idmapping:: + + /* Map the userspace id down into a kernel id in the first idmapping. */ + make_kuid(u0:k10000:r10000, u1000) = k11000 + +Another way to look at this translation is to treat it as inverting one +idmapping and applying another idmapping if both idmappings have the relevant +userspace id mapped. This will come in handy when working with idmapped mounts. + +Invalid translations +~~~~~~~~~~~~~~~~~~~~ + +It is never valid to use an id in the kernel idmapset of one idmapping as the +id in the userspace idmapset of another or the same idmapping. While the kernel +idmapset always indicates an idmapset in the kernel id space the userspace +idmapset indicates a userspace id. So the following translations are forbidden:: + + /* Map the userspace id down into a kernel id in the first idmapping. */ + make_kuid(u0:k10000:r10000, u1000) = k11000 + + /* INVALID: Map the kernel id down into a kernel id in the second idmapping. */ + make_kuid(u10000:k20000:r10000, k110000) = k21000 + ~~~~~~~ + +and equally wrong:: + + /* Map the kernel id up into a userspace id in the first idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + + /* INVALID: Map the userspace id up into a userspace id in the second idmapping. */ + from_kuid(u20000:k0:r10000, u1000) = k21000 + ~~~~~ + +Idmappings when creating filesystem objects +------------------------------------------- + +The concepts of mapping an id down or mapping an id up are expressed in the two +kernel functions filesystem developers are rather familiar with and which we've +already used in this document:: + + /* Map the userspace id down into a kernel id. */ + make_kuid(idmapping, uid) + + /* Map the kernel id up into a userspace id. */ + from_kuid(idmapping, kuid) + +We will take an abbreviated look into how idmappings figure into creating +filesystem objects. For simplicity we will only look at what happens when the +VFS has already completed path lookup right before it calls into the filesystem +itself. So we're concerned with what happens when e.g. ``vfs_mkdir()`` is +called. We will also assume that the directory we're creating filesystem +objects in is readable and writable for everyone. + +When creating a filesystem object the caller will look at the caller's +filesystem ids. These are just regular ``uid_t`` and ``gid_t`` userspace ids +but they are exclusively used when determining file ownership which is why they +are called "filesystem ids". They are usually identical to the uid and gid of +the caller but can differ. We will just assume they are always identical to not +get lost in too many details. + +When the caller enters the kernel two things happen: + +1. Map the caller's userspace ids down into kernel ids in the caller's + idmapping. + (To be precise, the kernel will simply look at the kernel ids stashed in the + credentials of the current task but for our education we'll pretend this + translation happens just in time.) +2. Verify that the caller's kernel ids can be mapped up to userspace ids in the + filesystem's idmapping. + +The second step is important as regular filesystem will ultimately need to map +the kernel id back up into a userspace id when writing to disk. +So with the second step the kernel guarantees that a valid userspace id can be +written to disk. If it can't the kernel will refuse the creation request to not +even remotely risk filesystem corruption. + +The astute reader will have realized that this is simply a varation of the +crossmapping algorithm we mentioned above in a previous section. First, the +kernel maps the caller's userspace id down into a kernel id according to the +caller's idmapping and then maps that kernel id up according to the +filesystem's idmapping. + +Example 1 +~~~~~~~~~ + +:: + + caller id: u1000 + caller idmapping: u0:k0:r4294967295 + filesystem idmapping: u0:k0:r4294967295 + +Both the caller and the filesystem use the identity idmapping: + +1. Map the caller's userspace ids into kernel ids in the caller's idmapping:: + + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Verify that the caller's kernel ids can be mapped to userspace ids in the + filesystem's idmapping. + + For this second step the kernel will call the function + ``fsuidgid_has_mapping()`` which ultimately boils down to calling + ``from_kuid()``:: + + from_kuid(u0:k0:r4294967295, k1000) = u1000 + +In this example both idmappings are the same so there's nothing exciting going +on. Ultimately the userspace id that lands on disk will be ``u1000``. + +Example 2 +~~~~~~~~~ + +:: + + caller id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k20000:r10000 + +1. Map the caller's userspace ids down into kernel ids in the caller's + idmapping:: + + make_kuid(u0:k10000:r10000, u1000) = k11000 + +2. Verify that the caller's kernel ids can be mapped up to userspace ids in the + filesystem's idmapping:: + + from_kuid(u0:k20000:r10000, k11000) = u-1 + +It's immediately clear that while the caller's userspace id could be +successfully mapped down into kernel ids in the caller's idmapping the kernel +ids could not be mapped up according to the filesystem's idmapping. So the +kernel will deny this creation request. + +Note that while this example is less common, because most filesystem can't be +mounted with non-initial idmappings this is a general problem as we can see in +the next examples. + +Example 3 +~~~~~~~~~ + +:: + + caller id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k0:r4294967295 + +1. Map the caller's userspace ids down into kernel ids in the caller's + idmapping:: + + make_kuid(u0:k10000:r10000, u1000) = k11000 + +2. Verify that the caller's kernel ids can be mapped up to userspace ids in the + filesystem's idmapping:: + + from_kuid(u0:k0:r4294967295, k11000) = u11000 + +We can see that the translation always succeeds. The userspace id that the +filesystem will ultimately put to disk will always be identical to the value of +the kernel id that was created in the caller's idmapping. This has mainly two +consequences. + +First, that we can't allow a caller to ultimately write to disk with another +userspace id. We could only do this if we were to mount the whole fileystem +with the caller's or another idmapping. But that solution is limited to a few +filesystems and not very flexible. But this is a use-case that is pretty +important in containerized workloads. + +Second, the caller will usually not be able to create any files or access +directories that have stricter permissions because none of the filesystem's +kernel ids map up into valid userspace ids in the caller's idmapping + +1. Map raw userspace ids down to kernel ids in the filesystem's idmapping:: + + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Map kernel ids up to userspace ids in the caller's idmapping:: + + from_kuid(u0:k10000:r10000, k1000) = u-1 + +Example 4 +~~~~~~~~~ + +:: + + file id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k0:r4294967295 + +In order to report ownership to userspace the kernel uses the crossmapping +algorithm introduced in a previous section: + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k10000:r10000, k1000) = u-1 + +The crossmapping algorithm fails in this case because the kernel id in the +filesystem idmapping cannot be mapped up to a userspace id in the caller's +idmapping. Thus, the kernel will report the ownership of this file as the +overflowid. + +Example 5 +~~~~~~~~~ + +:: + + file id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k20000:r10000 + +In order to report ownership to userspace the kernel uses the crossmapping +algorithm introduced in a previous section: + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k20000:r10000, u1000) = k21000 + +2. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k10000:r10000, k21000) = u-1 + +Again, the crossmapping algorithm fails in this case because the kernel id in +the filesystem idmapping cannot be mapped to a userspace id in the caller's +idmapping. Thus, the kernel will report the ownership of this file as the +overflowid. + +Note how in the last two examples things would be simple if the caller would be +using the initial idmapping. For a filesystem mounted with the initial +idmapping it would be trivial. So we only consider a filesystem with an +idmapping of ``u0:k20000:r10000``: + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k20000:r10000, u1000) = k21000 + +2. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k0:r4294967295, k21000) = u21000 + +Idmappings on idmapped mounts +----------------------------- + +The examples we've seen in the previous section where the caller's idmapping +and the filesystem's idmapping are incompatible causes various issues for +workloads. For a more complex but common example, consider two containers +started on the host. To completely prevent the two containers from affecting +each other, an administrator may often use different non-overlapping idmappings +for the two containers:: + + container1 idmapping: u0:k10000:r10000 + container2 idmapping: u0:k20000:r10000 + filesystem idmapping: u0:k30000:r10000 + +An administrator wanting to provide easy read-write access to the following set +of files:: + + dir id: u0 + dir/file1 id: u1000 + dir/file2 id: u2000 + +to both containers currently can't. + +Of course the administrator has the option to recursively change ownership via +``chown()``. For example, they could change ownership so that ``dir`` and all +files below it can be crossmapped from the filesystem's into the container's +idmapping. Let's assume they change ownership so it is compatible with the +first container's idmapping:: + + dir id: u10000 + dir/file1 id: u11000 + dir/file2 id: u12000 + +This would still leave ``dir`` rather useless to the second container. In fact, +``dir`` and all files below it would continue to appear owned by the overflowid +for the second container. + +Or consider another increasingly popular example. Some service managers such as +systemd implement a concept called "portable home directories". A user may want +to use their home directories on different machines where they are assigned +different login userspace ids. Most users will have ``u1000`` as the login id +on their machine at home and all files in their home directory will usually be +owned by ``u1000``. At uni or at work they may have another login id such as +``u1125``. This makes it rather difficult to interact with their home directory +on their work machine. + +In both cases changing ownership recursively has grave implications. The most +obvious one is that ownership is changed globally and permanently. In the home +directory case this change in ownership would even need to happen everytime the +user switches from their home to their work machine. For really large sets of +files this becomes increasingly costly. + +If the user is lucky, they are dealing with a filesystem that is mountable +inside user namespaces. But this would also change ownership globally and the +change in ownership is tied to the lifetime of the filesystem mount, i.e. the +superblock. The only way to change ownership is to completely unmount the +filesystem and mount it again in another user namespace. This is usually +impossible because it would mean that all users currently accessing the +filesystem can't anymore. And it means that ``dir`` still can't be shared +between two containers with different idmappings. +But usually the user doesn't even have this option since most filesystems +aren't mountable inside containers. And not having them mountable might be +desirable as it doesn't require the filesystem to deal with malicious +filesystem images. + +But the usecases mentioned above and more can be handled by idmapped mounts. +They allow to expose the same set of dentries with different ownership at +different mounts. This is achieved by marking the mounts with a user namespace +through the ``mount_setattr()`` system call. The idmapping associated with it +is then used to translate from the caller's idmapping to the filesystem's +idmapping and vica versa using the remapping algorithm we introduced above. + +Idmapped mounts make it possible to change ownership in a temporary and +localized way. The ownership changes are restricted to a specific mount and the +ownership changes are tied to the lifetime of the mount. All other users and +locations where the filesystem is exposed are unaffected. + +Filesystems that support idmapped mounts don't have any real reason to support +being mountable inside user namespaces. A filesystem could be exposed +completely under an idmapped mount to get the same effect. This has the +advantage that filesystems can leave the creation of the superblock to +privileged users in the initial user namespace. + +However, it is perfectly possible to combine idmapped mounts with filesystems +mountable inside user namespaces. We will touch on this further below. + +Remapping helpers +~~~~~~~~~~~~~~~~~ + +Idmapping functions were added that translate between idmappings. They make use +of the remapping algorithm we've introduced earlier. We're going to look at +two: + +- ``i_uid_into_mnt()`` and ``i_gid_into_mnt()`` + + The ``i_*id_into_mnt()`` functions translate filesystem's kernel ids into + kernel ids in the mount's idmapping:: + + /* Map the filesystem's kernel id up into a userspace id in the filesystem's idmapping. */ + from_kuid(filesystem, kid) = uid + + /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */ + make_kuid(mount, uid) = kuid + +- ``mapped_fsuid()`` and ``mapped_fsgid()`` + + The ``mapped_fs*id()`` functions translate the caller's kernel ids into + kernel ids in the filesystem's idmapping. This translation is achieved by + remapping the caller's kernel ids using the mount's idmapping:: + + /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(mount, kid) = uid + + /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(filesystem, uid) = kuid + +Note that these two functions invert each other. Consider the following +idmappings:: + + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k20000:r10000 + mount idmapping: u0:k10000:r10000 + +Assume a file owned by ``u1000`` is read from disk. The filesystem maps this id +to ``k21000`` according to it's idmapping. This is what is stored in the +inode's ``i_uid`` and ``i_gid`` fields. + +When the caller queries the ownership of this file via ``stat()`` the kernel +would usually simply use the crossmapping algorithm and map the filesystem's +kernel id up to a userspace id in the caller's idmapping. + +But when the caller is accessing the file on an idmapped mount the kernel will +first call ``i_uid_into_mnt()`` thereby translating the filesystem's kernel id +into a kernel id in the mount's idmapping:: + + i_uid_into_mnt(k21000): + /* Map the filesystem's kernel id up into a userspace id. */ + from_kuid(u0:k20000:r10000, k21000) = u1000 + + /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */ + make_kuid(u0:k10000:r10000, u1000) = k11000 + +Finally, when the kernel reports the owner to the caller it will turn the +kernel id in the mount's idmapping into a userspace id in the caller's +idmapping:: + + from_kuid(u0:k10000:r10000, k11000) = u1000 + +We can test whether this algorithm really works by verifying what happens when +we create a new file. Let's say the user is creating a file with ``u1000``. + +The kernel maps this to ``k11000`` in the caller's idmapping. Usually the +kernel would now apply the crossmapping, verifying that ``k11000`` can be +mapped to a userspace id in the filesystem's idmapping. Since ``k11000`` can't +be mapped up in the filesystem's idmapping directly this creation request +fails. + +But when the caller is accessing the file on an idmapped mount the kernel will +first call ``mapped_fs*id()`` thereby translating the caller's kernel id into +a kernel id according to the mount's idmapping:: + + mapped_fsuid(k11000): + /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + + /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(u0:k20000:r10000, u1000) = k21000 + +When finally writing to disk the kernel will then map ``k21000`` up into a +userspace id in the filesystem's idmapping:: + + from_kuid(u0:k20000:r10000, k21000) = u1000 + +As we can see, we end up with an invertible and therefore information +preserving algorithm. A file created from ``u1000`` on an idmapped mount will +also be reported as being owned by ``u1000`` and vica versa. + +Let's now briefly reconsider the failing examples from earlier in the context +of idmapped mounts. + +Example 2 reconsidered +~~~~~~~~~~~~~~~~~~~~~~ + +:: + + caller id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k20000:r10000 + mount idmapping: u0:k10000:r10000 + +When the caller is using a non-initial idmapping the common case is to attach +the same idmapping to the mount. We now perform three steps: + +1. Map the caller's userspace ids into kernel ids in the caller's idmapping:: + + make_kuid(u0:k10000:r10000, u1000) = k11000 + +2. Translate the caller's kernel id into a kernel id in the filesystem's + idmapping:: + + mapped_fsuid(k11000): + /* Map the kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + + /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(u0:k20000:r10000, u1000) = k21000 + +2. Verify that the caller's kernel ids can be mapped to userspace ids in the + filesystem's idmapping:: + + from_kuid(u0:k20000:r10000, k21000) = u1000 + +So the ownership that lands on disk will be ``u1000``. + +Example 3 reconsidered +~~~~~~~~~~~~~~~~~~~~~~ + +:: + + caller id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k0:r4294967295 + mount idmapping: u0:k10000:r10000 + +The same translation algorithm works with the third example. + +1. Map the caller's userspace ids into kernel ids in the caller's idmapping:: + + make_kuid(u0:k10000:r10000, u1000) = k11000 + +2. Translate the caller's kernel id into a kernel id in the filesystem's + idmapping:: + + mapped_fsuid(k11000): + /* Map the kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(u0:k10000:r10000, k11000) = u1000 + + /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Verify that the caller's kernel ids can be mapped to userspace ids in the + filesystem's idmapping:: + + from_kuid(u0:k0:r4294967295, k21000) = u1000 + +So the ownership that lands on disk will be ``u1000``. + +Example 4 reconsidered +~~~~~~~~~~~~~~~~~~~~~~ + +:: + + file id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k0:r4294967295 + mount idmapping: u0:k10000:r10000 + +In order to report ownership to userspace the kernel now does three steps using +the translation algorithm we introduced earlier: + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Translate the kernel id into a kernel id in the mount's idmapping:: + + i_uid_into_mnt(k1000): + /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ + from_kuid(u0:k0:r4294967295, k1000) = u1000 + + /* Map the userspace id down into a kernel id in the mounts's idmapping. */ + make_kuid(u0:k10000:r10000, u1000) = k11000 + +3. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k10000:r10000, k11000) = u1000 + +Earlier, the caller's kernel id couldn't be crossmapped in the filesystems's +idmapping. With the idmapped mount in place it now can be crossmapped into the +filesystem's idmapping via the mount's idmapping. The file will now be created +with ``u1000`` according to the mount's idmapping. + +Example 5 reconsidered +~~~~~~~~~~~~~~~~~~~~~~ + +:: + + file id: u1000 + caller idmapping: u0:k10000:r10000 + filesystem idmapping: u0:k20000:r10000 + mount idmapping: u0:k10000:r10000 + +Again, in order to report ownership to userspace the kernel now does three +steps using the translation algorithm we introduced earlier: + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k20000:r10000, u1000) = k21000 + +2. Translate the kernel id into a kernel id in the mount's idmapping:: + + i_uid_into_mnt(k21000): + /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ + from_kuid(u0:k20000:r10000, k21000) = u1000 + + /* Map the userspace id down into a kernel id in the mounts's idmapping. */ + make_kuid(u0:k10000:r10000, u1000) = k11000 + +3. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k10000:r10000, k11000) = u1000 + +Earlier, the file's kernel id couldn't be crossmapped in the filesystems's +idmapping. With the idmapped mount in place it now can be crossmapped into the +filesystem's idmapping via the mount's idmapping. The file is now owned by +``u1000`` according to the mount's idmapping. + +Changing ownership on a home directory +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +We've seen above how idmapped mounts can be used to translate between +idmappings when either the caller, the filesystem or both uses a non-initial +idmapping. A wide range of usecases exist when the caller is using +a non-initial idmapping. This mostly happens in the context of containerized +workloads. The consequence is as we have seen that for both, filesystem's +mounted with the initial idmapping and filesystems mounted with non-initial +idmappings, access to the filesystem isn't working because the kernel ids can't +be crossmapped between the caller's and the filesystem's idmapping. + +As we've seen above idmapped mounts provide a solution to this by remapping the +caller's or filesystem's idmapping according to the mount's idmapping. + +Aside from containerized workloads, idmapped mounts have the advantage that +they also work when both the caller and the filesystem use the initial +idmapping which means users on the host can change the ownership of directories +and files on a per-mount basis. + +Consider our previous example where a user has their home directory on portable +storage. At home they have id ``u1000`` and all files in their home directory +are owned by ``u1000`` whereas at uni or work they have login id ``u1125``. + +Taking their home directory with them becomes problematic. They can't easily +access their files, they might not be able to write to disk without applying +lax permissions or ACLs and even if they can, they will end up with an annoying +mix of files and directories owned by ``u1000`` and ``u1125``. + +Idmapped mounts allow to solve this problem. A user can create an idmapped +mount for their home directory on their work computer or their computer at home +depending on what ownership they would prefer to end up on the portable storage +itself. + +Let's assume they want all files on disk to belong to ``u1000``. When the user +plugs in their portable storage at their work station they can setup a job that +creates an idmapped mount with the minimal idmapping ``u1000:k1125:r1``. So now +when they create a file the kernel performs the following steps we already know +from above::: + + caller id: u1125 + caller idmapping: u0:k0:r4294967295 + filesystem idmapping: u0:k0:r4294967295 + mount idmapping: u1000:k1125:r1 + +1. Map the caller's userspace ids into kernel ids in the caller's idmapping:: + + make_kuid(u0:k0:r4294967295, u1125) = k1125 + +2. Translate the caller's kernel id into a kernel id in the filesystem's + idmapping:: + + mapped_fsuid(k1125): + /* Map the kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(u1000:k1125:r1, k1125) = u1000 + + /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Verify that the caller's kernel ids can be mapped to userspace ids in the + filesystem's idmapping:: + + from_kuid(u0:k0:r4294967295, k1000) = u1000 + +So ultimately the file will be created with ``u1000`` on disk. + +Now let's briefly look at what ownership the caller with id ``u1125`` will see +on their work computer: + +:: + + file id: u1000 + caller idmapping: u0:k0:r4294967295 + filesystem idmapping: u0:k0:r4294967295 + mount idmapping: u1000:k1125:r1 + +1. Map the userspace id on disk down into a kernel id in the filesystem's + idmapping:: + + make_kuid(u0:k0:r4294967295, u1000) = k1000 + +2. Translate the kernel id into a kernel id in the mount's idmapping:: + + i_uid_into_mnt(k1000): + /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ + from_kuid(u0:k0:r4294967295, k1000) = u1000 + + /* Map the userspace id down into a kernel id in the mounts's idmapping. */ + make_kuid(u1000:k1125:r1, u1000) = k1125 + +3. Map the kernel id up into a userspace id in the caller's idmapping:: + + from_kuid(u0:k0:r4294967295, k1125) = u1125 + +So ultimately the caller will be reported that the file belongs to ``u1125`` +which is the caller's userspace id on their workstation in our example. + +The raw userspace id that is put on disk is ``u1000`` so when the user takes +their home directory back to their home computer where they are assigned +``u1000`` using the initial idmapping and mount the filesystem with the initial +idmapping they will see all those files owned by ``u1000``. + +Shortcircuting +-------------- + +Currently, the implementation of idmapped mounts enforces that the filesystem +is mounted with the initial idmapping. The reason is simply that none of the +filesystems that we targeted were mountable with a non-initial idmapping. But +that might change soon enough. As we've seen above, thanks to the properties of +idmappings the translation works for both filesystems mounted with the initial +idmapping and filesystem with non-initial idmappings. + +Based on this current restriction to filesystem mounted with the initial +idmapping two noticeable shortcuts have been taken: + +1. We always stash a reference to the initial user namespace in ``struct + vfsmount``. Idmapped mounts are thus mounts that have a non-initial user + namespace attached to them. + + In order to support idmapped mounts this needs to be changed. Instead of + stashing the initial user namespace the user namespace the filesystem was + mounted with must be stashed. An idmapped mount is then any mount that has + a different user namespace attached then the filesystem was mounted with. + This has no user-visible consequences. + +2. The translation algorithms in ``mapped_fs*id()`` and ``i_*id_into_mnt()`` + are simplified. + + Let's consider ``mapped_fs*id()`` first. This function translates the + caller's kernel id into a kernel id in the filesystem's idmapping via + a mount's idmapping. The full algorithm is:: + + mapped_fsuid(kid): + /* Map the kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(mount-idmapping, kid) = uid + + /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ + make_kuid(filesystem-idmapping, uid) = kuid + + We know that the filesystem is always mounted with the initial idmapping as + we enforce this in ``mount_setattr()``. So this can be shortened to:: + + mapped_fsuid(kid): + /* Map the kernel id up into a userspace id in the mount's idmapping. */ + from_kuid(mount-idmapping, kid) = uid + + /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ + KUIDT_INIT(uid) = kuid + + Similarly, for ``i_*id_into_mnt()`` which translated the filesystem's kernel + id into a mount's kernel id:: + + i_uid_into_mnt(kid): + /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ + from_kuid(filesystem-idmapping, kid) = uid + + /* Map the userspace id down into a kernel id in the mounts's idmapping. */ + make_kuid(mount-idmapping, uid) = kuid + + Again, we know that the filesystem is always mounted with the initial + idmapping as we enforce this in ``mount_setattr()``. So this can be + shortened to:: + + i_uid_into_mnt(kid): + /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ + __kuid_val(kid) = uid + + /* Map the userspace id down into a kernel id in the mounts's idmapping. */ + make_kuid(mount-idmapping, uid) = kuid + +Handling filesystems mounted with non-initial idmappings requires that the +translation functions be converted to their full form. They can still be +shortcircuited on non-idmapped mounts. This has no user-visible consequences. diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index 246af51b277a..c0ad233963ae 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -34,6 +34,7 @@ algorithms work. quota seq_file sharedsubtree + idmappings automount-support @@ -72,7 +73,7 @@ Documentation for filesystem implementations. befs bfs btrfs - cifs/cifsroot + cifs/index ceph coda configfs @@ -100,6 +101,7 @@ Documentation for filesystem implementations. nilfs2 nfs/index ntfs + ntfs3 ocfs2 ocfs2-online-filecheck omfs diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 2183fd8cc350..d36fe79167b3 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -70,7 +70,7 @@ prototypes:: const char *(*get_link) (struct dentry *, struct inode *, struct delayed_call *); void (*truncate) (struct inode *); int (*permission) (struct inode *, int, unsigned int); - int (*get_acl)(struct inode *, int); + struct posix_acl * (*get_acl)(struct inode *, int, bool); int (*setattr) (struct dentry *, struct iattr *); int (*getattr) (const struct path *, struct kstat *, u32, unsigned int); ssize_t (*listxattr) (struct dentry *, char *, size_t); @@ -271,19 +271,19 @@ prototypes:: locking rules: All except set_page_dirty and freepage may block -====================== ======================== ========= -ops PageLocked(page) i_rwsem -====================== ======================== ========= +====================== ======================== ========= =============== +ops PageLocked(page) i_rwsem invalidate_lock +====================== ======================== ========= =============== writepage: yes, unlocks (see below) -readpage: yes, unlocks +readpage: yes, unlocks shared writepages: set_page_dirty no -readahead: yes, unlocks -readpages: no +readahead: yes, unlocks shared +readpages: no shared write_begin: locks the page exclusive write_end: yes, unlocks exclusive bmap: -invalidatepage: yes +invalidatepage: yes exclusive releasepage: yes freepage: yes direct_IO: @@ -295,7 +295,7 @@ is_partially_uptodate: yes error_remove_page: yes swap_activate: no swap_deactivate: no -====================== ======================== ========= +====================== ======================== ========= =============== ->write_begin(), ->write_end() and ->readpage() may be called from the request handler (/dev/loop). @@ -378,7 +378,10 @@ keep it that way and don't breed new callers. ->invalidatepage() is called when the filesystem must attempt to drop some or all of the buffers from the page when it is being truncated. It returns zero on success. If ->invalidatepage is zero, the kernel uses -block_invalidatepage() instead. +block_invalidatepage() instead. The filesystem must exclusively acquire +invalidate_lock before invalidating page cache in truncate / hole punch path +(and thus calling into ->invalidatepage) to block races between page cache +invalidation and page cache filling functions (fault, read, ...). ->releasepage() is called when the kernel is about to try to drop the buffers from the page in preparation for freeing it. It returns zero to @@ -506,6 +509,7 @@ prototypes:: ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); + int (*iopoll) (struct kiocb *kiocb, bool spin); int (*iterate) (struct file *, struct dir_context *); int (*iterate_shared) (struct file *, struct dir_context *); __poll_t (*poll) (struct file *, struct poll_table_struct *); @@ -518,12 +522,6 @@ prototypes:: int (*fsync) (struct file *, loff_t start, loff_t end, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); - ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, - loff_t *); - ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, - loff_t *); - ssize_t (*sendfile) (struct file *, loff_t *, size_t, read_actor_t, - void __user *); ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int); unsigned long (*get_unmapped_area)(struct file *, unsigned long, @@ -536,6 +534,14 @@ prototypes:: size_t, unsigned int); int (*setlease)(struct file *, long, struct file_lock **, void **); long (*fallocate)(struct file *, int, loff_t, loff_t); + void (*show_fdinfo)(struct seq_file *m, struct file *f); + unsigned (*mmap_capabilities)(struct file *); + ssize_t (*copy_file_range)(struct file *, loff_t, struct file *, + loff_t, size_t, unsigned int); + loff_t (*remap_file_range)(struct file *file_in, loff_t pos_in, + struct file *file_out, loff_t pos_out, + loff_t len, unsigned int remap_flags); + int (*fadvise)(struct file *, loff_t, loff_t, int); locking rules: All may block. @@ -570,6 +576,25 @@ in sys_read() and friends. the lease within the individual filesystem to record the result of the operation +->fallocate implementation must be really careful to maintain page cache +consistency when punching holes or performing other operations that invalidate +page cache contents. Usually the filesystem needs to call +truncate_inode_pages_range() to invalidate relevant range of the page cache. +However the filesystem usually also needs to update its internal (and on disk) +view of file offset -> disk block mapping. Until this update is finished, the +filesystem needs to block page faults and reads from reloading now-stale page +cache contents from the disk. Since VFS acquires mapping->invalidate_lock in +shared mode when loading pages from disk (filemap_fault(), filemap_read(), +readahead paths), the fallocate implementation must take the invalidate_lock to +prevent reloading. + +->copy_file_range and ->remap_file_range implementations need to serialize +against modifications of file data while the operation is running. For +blocking changes through write(2) and similar operations inode->i_rwsem can be +used. To block changes to file contents via a memory mapping during the +operation, the filesystem must take mapping->invalidate_lock to coordinate +with ->page_mkwrite. + dquot_operations ================ @@ -627,11 +652,11 @@ pfn_mkwrite: yes access: yes ============= ========= =========================== -->fault() is called when a previously not present pte is about -to be faulted in. The filesystem must find and return the page associated -with the passed in "pgoff" in the vm_fault structure. If it is possible that -the page may be truncated and/or invalidated, then the filesystem must lock -the page, then ensure it is not already truncated (the page lock will block +->fault() is called when a previously not present pte is about to be faulted +in. The filesystem must find and return the page associated with the passed in +"pgoff" in the vm_fault structure. If it is possible that the page may be +truncated and/or invalidated, then the filesystem must lock invalidate_lock, +then ensure the page is not already truncated (invalidate_lock will block subsequent truncate), and then return with VM_FAULT_LOCKED, and the page locked. The VM will unlock the page. @@ -644,12 +669,14 @@ page table entry. Pointer to entry associated with the page is passed in "pte" field in vm_fault structure. Pointers to entries for other offsets should be calculated relative to "pte". -->page_mkwrite() is called when a previously read-only pte is -about to become writeable. The filesystem again must ensure that there are -no truncate/invalidate races, and then return with the page locked. If -the page has been truncated, the filesystem should not look up a new page -like the ->fault() handler, but simply return with VM_FAULT_NOPAGE, which -will cause the VM to retry the fault. +->page_mkwrite() is called when a previously read-only pte is about to become +writeable. The filesystem again must ensure that there are no +truncate/invalidate races or races with operations such as ->remap_file_range +or ->copy_file_range, and then return with the page locked. Usually +mapping->invalidate_lock is suitable for proper serialization. If the page has +been truncated, the filesystem should not look up a new page like the ->fault() +handler, but simply return with VM_FAULT_NOPAGE, which will cause the VM to +retry the fault. ->pfn_mkwrite() is the same as page_mkwrite but when the pte is VM_PFNMAP or VM_MIXEDMAP with a page-less entry. Expected return is diff --git a/Documentation/filesystems/mandatory-locking.rst b/Documentation/filesystems/mandatory-locking.rst deleted file mode 100644 index 9ce73544a8f0..000000000000 --- a/Documentation/filesystems/mandatory-locking.rst +++ /dev/null @@ -1,188 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -===================================================== -Mandatory File Locking For The Linux Operating System -===================================================== - - Andy Walker <andy@lysaker.kvaerner.no> - - 15 April 1996 - - (Updated September 2007) - -0. Why you should avoid mandatory locking ------------------------------------------ - -The Linux implementation is prey to a number of difficult-to-fix race -conditions which in practice make it not dependable: - - - The write system call checks for a mandatory lock only once - at its start. It is therefore possible for a lock request to - be granted after this check but before the data is modified. - A process may then see file data change even while a mandatory - lock was held. - - Similarly, an exclusive lock may be granted on a file after - the kernel has decided to proceed with a read, but before the - read has actually completed, and the reading process may see - the file data in a state which should not have been visible - to it. - - Similar races make the claimed mutual exclusion between lock - and mmap similarly unreliable. - -1. What is mandatory locking? ------------------------------- - -Mandatory locking is kernel enforced file locking, as opposed to the more usual -cooperative file locking used to guarantee sequential access to files among -processes. File locks are applied using the flock() and fcntl() system calls -(and the lockf() library routine which is a wrapper around fcntl().) It is -normally a process' responsibility to check for locks on a file it wishes to -update, before applying its own lock, updating the file and unlocking it again. -The most commonly used example of this (and in the case of sendmail, the most -troublesome) is access to a user's mailbox. The mail user agent and the mail -transfer agent must guard against updating the mailbox at the same time, and -prevent reading the mailbox while it is being updated. - -In a perfect world all processes would use and honour a cooperative, or -"advisory" locking scheme. However, the world isn't perfect, and there's -a lot of poorly written code out there. - -In trying to address this problem, the designers of System V UNIX came up -with a "mandatory" locking scheme, whereby the operating system kernel would -block attempts by a process to write to a file that another process holds a -"read" -or- "shared" lock on, and block attempts to both read and write to a -file that a process holds a "write " -or- "exclusive" lock on. - -The System V mandatory locking scheme was intended to have as little impact as -possible on existing user code. The scheme is based on marking individual files -as candidates for mandatory locking, and using the existing fcntl()/lockf() -interface for applying locks just as if they were normal, advisory locks. - -.. Note:: - - 1. In saying "file" in the paragraphs above I am actually not telling - the whole truth. System V locking is based on fcntl(). The granularity of - fcntl() is such that it allows the locking of byte ranges in files, in - addition to entire files, so the mandatory locking rules also have byte - level granularity. - - 2. POSIX.1 does not specify any scheme for mandatory locking, despite - borrowing the fcntl() locking scheme from System V. The mandatory locking - scheme is defined by the System V Interface Definition (SVID) Version 3. - -2. Marking a file for mandatory locking ---------------------------------------- - -A file is marked as a candidate for mandatory locking by setting the group-id -bit in its file mode but removing the group-execute bit. This is an otherwise -meaningless combination, and was chosen by the System V implementors so as not -to break existing user programs. - -Note that the group-id bit is usually automatically cleared by the kernel when -a setgid file is written to. This is a security measure. The kernel has been -modified to recognize the special case of a mandatory lock candidate and to -refrain from clearing this bit. Similarly the kernel has been modified not -to run mandatory lock candidates with setgid privileges. - -3. Available implementations ----------------------------- - -I have considered the implementations of mandatory locking available with -SunOS 4.1.x, Solaris 2.x and HP-UX 9.x. - -Generally I have tried to make the most sense out of the behaviour exhibited -by these three reference systems. There are many anomalies. - -All the reference systems reject all calls to open() for a file on which -another process has outstanding mandatory locks. This is in direct -contravention of SVID 3, which states that only calls to open() with the -O_TRUNC flag set should be rejected. The Linux implementation follows the SVID -definition, which is the "Right Thing", since only calls with O_TRUNC can -modify the contents of the file. - -HP-UX even disallows open() with O_TRUNC for a file with advisory locks, not -just mandatory locks. That would appear to contravene POSIX.1. - -mmap() is another interesting case. All the operating systems mentioned -prevent mandatory locks from being applied to an mmap()'ed file, but HP-UX -also disallows advisory locks for such a file. SVID actually specifies the -paranoid HP-UX behaviour. - -In my opinion only MAP_SHARED mappings should be immune from locking, and then -only from mandatory locks - that is what is currently implemented. - -SunOS is so hopeless that it doesn't even honour the O_NONBLOCK flag for -mandatory locks, so reads and writes to locked files always block when they -should return EAGAIN. - -I'm afraid that this is such an esoteric area that the semantics described -below are just as valid as any others, so long as the main points seem to -agree. - -4. Semantics ------------- - -1. Mandatory locks can only be applied via the fcntl()/lockf() locking - interface - in other words the System V/POSIX interface. BSD style - locks using flock() never result in a mandatory lock. - -2. If a process has locked a region of a file with a mandatory read lock, then - other processes are permitted to read from that region. If any of these - processes attempts to write to the region it will block until the lock is - released, unless the process has opened the file with the O_NONBLOCK - flag in which case the system call will return immediately with the error - status EAGAIN. - -3. If a process has locked a region of a file with a mandatory write lock, all - attempts to read or write to that region block until the lock is released, - unless a process has opened the file with the O_NONBLOCK flag in which case - the system call will return immediately with the error status EAGAIN. - -4. Calls to open() with O_TRUNC, or to creat(), on a existing file that has - any mandatory locks owned by other processes will be rejected with the - error status EAGAIN. - -5. Attempts to apply a mandatory lock to a file that is memory mapped and - shared (via mmap() with MAP_SHARED) will be rejected with the error status - EAGAIN. - -6. Attempts to create a shared memory map of a file (via mmap() with MAP_SHARED) - that has any mandatory locks in effect will be rejected with the error status - EAGAIN. - -5. Which system calls are affected? ------------------------------------ - -Those which modify a file's contents, not just the inode. That gives read(), -write(), readv(), writev(), open(), creat(), mmap(), truncate() and -ftruncate(). truncate() and ftruncate() are considered to be "write" actions -for the purposes of mandatory locking. - -The affected region is usually defined as stretching from the current position -for the total number of bytes read or written. For the truncate calls it is -defined as the bytes of a file removed or added (we must also consider bytes -added, as a lock can specify just "the whole file", rather than a specific -range of bytes.) - -Note 3: I may have overlooked some system calls that need mandatory lock -checking in my eagerness to get this code out the door. Please let me know, or -better still fix the system calls yourself and submit a patch to me or Linus. - -6. Warning! ------------ - -Not even root can override a mandatory lock, so runaway processes can wreak -havoc if they lock crucial files. The way around it is to change the file -permissions (remove the setgid bit) before trying to read or write to it. -Of course, that might be a bit tricky if the system is hung :-( - -7. The "mand" mount option --------------------------- -Mandatory locking is disabled on all filesystems by default, and must be -administratively enabled by mounting with "-o mand". That mount option -is only allowed if the mounting task has the CAP_SYS_ADMIN capability. - -Since kernel v4.5, it is possible to disable mandatory locking -altogether by setting CONFIG_MANDATORY_FILE_LOCKING to "n". A kernel -with this disabled will reject attempts to mount filesystems with the -"mand" mount option with the error status EPERM. diff --git a/Documentation/filesystems/ntfs3.rst b/Documentation/filesystems/ntfs3.rst new file mode 100644 index 000000000000..ffe9ea0c1499 --- /dev/null +++ b/Documentation/filesystems/ntfs3.rst @@ -0,0 +1,106 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===== +NTFS3 +===== + + +Summary and Features +==================== + +NTFS3 is fully functional NTFS Read-Write driver. The driver works with +NTFS versions up to 3.1, normal/compressed/sparse files +and journal replaying. File system type to use on mount is 'ntfs3'. + +- This driver implements NTFS read/write support for normal, sparse and + compressed files. +- Supports native journal replaying; +- Supports extended attributes + Predefined extended attributes: + - 'system.ntfs_security' gets/sets security + descriptor (SECURITY_DESCRIPTOR_RELATIVE) + - 'system.ntfs_attrib' gets/sets ntfs file/dir attributes. + Note: applied to empty files, this allows to switch type between + sparse(0x200), compressed(0x800) and normal; +- Supports NFS export of mounted NTFS volumes. + +Mount Options +============= + +The list below describes mount options supported by NTFS3 driver in addition to +generic ones. + +=============================================================================== + +nls=name This option informs the driver how to interpret path + strings and translate them to Unicode and back. If + this option is not set, the default codepage will be + used (CONFIG_NLS_DEFAULT). + Examples: + 'nls=utf8' + +uid= +gid= +umask= Controls the default permissions for files/directories created + after the NTFS volume is mounted. + +fmask= +dmask= Instead of specifying umask which applies both to + files and directories, fmask applies only to files and + dmask only to directories. + +nohidden Files with the Windows-specific HIDDEN (FILE_ATTRIBUTE_HIDDEN) + attribute will not be shown under Linux. + +sys_immutable Files with the Windows-specific SYSTEM + (FILE_ATTRIBUTE_SYSTEM) attribute will be marked as system + immutable files. + +discard Enable support of the TRIM command for improved performance + on delete operations, which is recommended for use with the + solid-state drives (SSD). + +force Forces the driver to mount partitions even if 'dirty' flag + (volume dirty) is set. Not recommended for use. + +sparse Create new files as "sparse". + +showmeta Use this parameter to show all meta-files (System Files) on + a mounted NTFS partition. + By default, all meta-files are hidden. + +prealloc Preallocate space for files excessively when file size is + increasing on writes. Decreases fragmentation in case of + parallel write operations to different files. + +no_acs_rules "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, but + they will stay as root + +acl Support POSIX ACLs (Access Control Lists). Effective if + supported by Kernel. Not to be confused with NTFS ACLs. + The option specified as acl enables support for POSIX ACLs. + +noatime All files and directories will not update their last access + time attribute if a partition is mounted with this parameter. + This option can speed up file system operation. + +=============================================================================== + +ToDo list +========= + +- Full journaling support (currently journal replaying is supported) over JBD. + + +References +========== +https://www.paragon-software.com/home/ntfs-linux-professional/ + - Commercial version of the NTFS driver for Linux. + +almaz.alexandrovich@paragon-software.com + - Direct e-mail address for feedback and requests on the NTFS3 implementation. diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index 455ca86eb4fc..7da6c30ed596 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -427,6 +427,9 @@ b) If a file residing on a lower layer is opened for read-only and then memory mapped with MAP_SHARED, then subsequent changes to the file are not reflected in the memory mapping. +c) If a file residing on a lower layer is being executed, then opening that +file for write or truncating the file will not be denied with ETXTBSY. + The following options allow overlayfs to act more like a standards compliant filesystem: diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.rst b/Documentation/filesystems/ramfs-rootfs-initramfs.rst index 4598b0d90b60..164960631925 100644 --- a/Documentation/filesystems/ramfs-rootfs-initramfs.rst +++ b/Documentation/filesystems/ramfs-rootfs-initramfs.rst @@ -170,7 +170,7 @@ Documentation/driver-api/early-userspace/early_userspace_support.rst for more de The kernel does not depend on external cpio tools. If you specify a directory instead of a configuration file, the kernel's build infrastructure creates a configuration file from that directory (usr/Makefile calls -usr/gen_initramfs_list.sh), and proceeds to package up that directory +usr/gen_initramfs.sh), and proceeds to package up that directory using the config file (by feeding it to usr/gen_init_cpio, which is created from usr/gen_init_cpio.c). The kernel's build-time cpio creation code is entirely self-contained, and the kernel's boot-time extractor is also diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index 14c31eced416..bf5c48066fac 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -432,7 +432,7 @@ As of kernel 2.6.22, the following members are defined: const char *(*get_link) (struct dentry *, struct inode *, struct delayed_call *); int (*permission) (struct user_namespace *, struct inode *, int); - int (*get_acl)(struct inode *, int); + struct posix_acl * (*get_acl)(struct inode *, int, bool); int (*setattr) (struct user_namespace *, struct dentry *, struct iattr *); int (*getattr) (struct user_namespace *, const struct path *, struct kstat *, u32, unsigned int); ssize_t (*listxattr) (struct dentry *, char *, size_t); diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst index 75df90d1e54c..ef9eec71f6f3 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -10,7 +10,7 @@ Authors: - Xu Yilun <yilun.xu@intel.com> The Device Feature List (DFL) FPGA framework (and drivers according to -this framework) hides the very details of low layer hardwares and provides +this framework) hides the very details of low layer hardware and provides unified interfaces to userspace. Applications could use these interfaces to configure, enumerate, open and access FPGA accelerators on platforms which implement the DFL in the device memory. Besides this, the DFL framework @@ -205,7 +205,7 @@ given Device Feature Lists and create platform devices for feature devices also abstracts operations for the private features and exposes common ops to feature device drivers. -The FPGA DFL Device could be different hardwares, e.g. PCIe device, platform +The FPGA DFL Device could be different hardware, e.g. PCIe device, platform device and etc. Its driver module is always loaded first once the device is created by the system. This driver plays an infrastructural role in the driver architecture. It locates the DFLs in the device memory, handles them diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..1ef7951ded5e 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -159,6 +159,8 @@ KMS Core Structures and Functions .. kernel-doc:: drivers/gpu/drm/drm_mode_config.c :export: +.. _kms_base_object_abstraction: + Modeset Base Object Abstraction =============================== @@ -463,6 +465,35 @@ KMS Properties This section of the documentation is primarily aimed at user-space developers. For the driver APIs, see the other sections. +Requirements +------------ + +KMS drivers might need to add extra properties to support new features. Each +new property introduced in a driver needs to meet a few requirements, in +addition to the one mentioned above: + +* It must be standardized, documenting: + + * The full, exact, name string; + * If the property is an enum, all the valid value name strings; + * What values are accepted, and what these values mean; + * What the property does and how it can be used; + * How the property might interact with other, existing properties. + +* It must provide a generic helper in the core code to register that + property on the object it attaches to. + +* Its content must be decoded by the core and provided in the object's + associated state structure. That includes anything drivers might want + to precompute, like struct drm_clip_rect for planes. + +* Its initial state must match the behavior prior to the property + introduction. This might be a fixed value matching what the hardware + does, or it may be inherited from the state the firmware left the + system in during boot. + +* An IGT test must be submitted where reasonable. + Property Types and Blob Property Support ---------------------------------------- @@ -508,8 +539,8 @@ Plane Composition Properties Damage Tracking Properties -------------------------- -.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c - :doc: overview +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: damage tracking Color Management Properties --------------------------- diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 04bdc7a91d53..199afb503ab1 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -37,6 +37,15 @@ Primary Nodes, DRM Master and Authentication .. kernel-doc:: include/drm/drm_auth.h :internal: + +.. _drm_leasing: + +DRM Display Resource Leasing +============================ + +.. kernel-doc:: drivers/gpu/drm/drm_lease.c + :doc: drm leasing + Open-Source Userspace Requirements ================================== @@ -457,6 +466,19 @@ Userspace API Structures .. kernel-doc:: include/uapi/drm/drm_mode.h :doc: overview +.. _crtc_index: + +CRTC index +---------- + +CRTC's have both an object ID and an index, and they are not the same thing. +The index is used in cases where a densely packed identifier for a CRTC is +needed, for instance a bitmask of CRTC's. The member possible_crtcs of struct +drm_mode_get_plane is an example. + +DRM_IOCTL_MODE_GETRESOURCES populates a structure with an array of CRTC ID's, +and the CRTC index is its position in this array. + .. kernel-doc:: include/uapi/drm/drm.h :internal: diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 42ce0196930a..204ebdaadb45 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -422,9 +422,16 @@ Batchbuffer Parsing User Batchbuffer Execution -------------------------- +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_context_types.h + .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c :doc: User command execution +Scheduling +---------- +.. kernel-doc:: drivers/gpu/drm/i915/i915_scheduler_types.h + :functions: i915_sched_engine + Logical Rings, Logical Ring Contexts and Execlists -------------------------------------------------- @@ -518,6 +525,14 @@ GuC-based command submission .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c :doc: GuC-based command submission +GuC ABI +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h + HuC --- .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst b/Documentation/gpu/rfc/i915_gem_lmem.rst index 675ba8620d66..b421a3c1806e 100644 --- a/Documentation/gpu/rfc/i915_gem_lmem.rst +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst @@ -18,114 +18,5 @@ real, with all the uAPI bits is: * Route shmem backend over to TTM SYSTEM for discrete * TTM purgeable object support * Move i915 buddy allocator over to TTM - * MMAP ioctl mode(see `I915 MMAP`_) - * SET/GET ioctl caching(see `I915 SET/GET CACHING`_) * Send RFC(with mesa-dev on cc) for final sign off on the uAPI * Add pciid for DG1 and turn on uAPI for real - -New object placement and region query uAPI -========================================== -Starting from DG1 we need to give userspace the ability to allocate buffers from -device local-memory. Currently the driver supports gem_create, which can place -buffers in system memory via shmem, and the usual assortment of other -interfaces, like dumb buffers and userptr. - -To support this new capability, while also providing a uAPI which will work -beyond just DG1, we propose to offer three new bits of uAPI: - -DRM_I915_QUERY_MEMORY_REGIONS ------------------------------ -New query ID which allows userspace to discover the list of supported memory -regions(like system-memory and local-memory) for a given device. We identify -each region with a class and instance pair, which should be unique. The class -here would be DEVICE or SYSTEM, and the instance would be zero, on platforms -like DG1. - -Side note: The class/instance design is borrowed from our existing engine uAPI, -where we describe every physical engine in terms of its class, and the -particular instance, since we can have more than one per class. - -In the future we also want to expose more information which can further -describe the capabilities of a region. - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :functions: drm_i915_gem_memory_class drm_i915_gem_memory_class_instance drm_i915_memory_region_info drm_i915_query_memory_regions - -GEM_CREATE_EXT --------------- -New ioctl which is basically just gem_create but now allows userspace to provide -a chain of possible extensions. Note that if we don't provide any extensions and -set flags=0 then we get the exact same behaviour as gem_create. - -Side note: We also need to support PXP[1] in the near future, which is also -applicable to integrated platforms, and adds its own gem_create_ext extension, -which basically lets userspace mark a buffer as "protected". - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :functions: drm_i915_gem_create_ext - -I915_GEM_CREATE_EXT_MEMORY_REGIONS ----------------------------------- -Implemented as an extension for gem_create_ext, we would now allow userspace to -optionally provide an immutable list of preferred placements at creation time, -in priority order, for a given buffer object. For the placements we expect -them each to use the class/instance encoding, as per the output of the regions -query. Having the list in priority order will be useful in the future when -placing an object, say during eviction. - -.. kernel-doc:: include/uapi/drm/i915_drm.h - :functions: drm_i915_gem_create_ext_memory_regions - -One fair criticism here is that this seems a little over-engineered[2]. If we -just consider DG1 then yes, a simple gem_create.flags or something is totally -all that's needed to tell the kernel to allocate the buffer in local-memory or -whatever. However looking to the future we need uAPI which can also support -upcoming Xe HP multi-tile architecture in a sane way, where there can be -multiple local-memory instances for a given device, and so using both class and -instance in our uAPI to describe regions is desirable, although specifically -for DG1 it's uninteresting, since we only have a single local-memory instance. - -Existing uAPI issues -==================== -Some potential issues we still need to resolve. - -I915 MMAP ---------- -In i915 there are multiple ways to MMAP GEM object, including mapping the same -object using different mapping types(WC vs WB), i.e multiple active mmaps per -object. TTM expects one MMAP at most for the lifetime of the object. If it -turns out that we have to backpedal here, there might be some potential -userspace fallout. - -I915 SET/GET CACHING --------------------- -In i915 we have set/get_caching ioctl. TTM doesn't let us to change this, but -DG1 doesn't support non-snooped pcie transactions, so we can just always -allocate as WB for smem-only buffers. If/when our hw gains support for -non-snooped pcie transactions then we must fix this mode at allocation time as -a new GEM extension. - -This is related to the mmap problem, because in general (meaning, when we're -not running on intel cpus) the cpu mmap must not, ever, be inconsistent with -allocation mode. - -Possible idea is to let the kernel picks the mmap mode for userspace from the -following table: - -smem-only: WB. Userspace does not need to call clflush. - -smem+lmem: We only ever allow a single mode, so simply allocate this as uncached -memory, and always give userspace a WC mapping. GPU still does snooped access -here(assuming we can't turn it off like on DG1), which is a bit inefficient. - -lmem only: always WC - -This means on discrete you only get a single mmap mode, all others must be -rejected. That's probably going to be a new default mode or something like -that. - -Links -===== -[1] https://patchwork.freedesktop.org/series/86798/ - -[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791 diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h b/Documentation/gpu/rfc/i915_parallel_execbuf.h new file mode 100644 index 000000000000..8cbe2c4e0172 --- /dev/null +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h @@ -0,0 +1,122 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2021 Intel Corporation + */ + +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see i915_context_engines_parallel_submit */ + +/** + * struct drm_i915_context_engines_parallel_submit - Configure engine for + * parallel submission. + * + * Setup a slot in the context engine map to allow multiple BBs to be submitted + * in a single execbuf IOCTL. Those BBs will then be scheduled to run on the GPU + * in parallel. Multiple hardware contexts are created internally in the i915 + * run these BBs. Once a slot is configured for N BBs only N BBs can be + * submitted in each execbuf IOCTL and this is implicit behavior e.g. The user + * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL knows how + * many BBs there are based on the slot's configuration. The N BBs are the last + * N buffer objects or first N if I915_EXEC_BATCH_FIRST is set. + * + * The default placement behavior is to create implicit bonds between each + * context if each context maps to more than 1 physical engine (e.g. context is + * a virtual engine). Also we only allow contexts of same engine class and these + * contexts must be in logically contiguous order. Examples of the placement + * behavior described below. Lastly, the default is to not allow BBs to + * preempted mid BB rather insert coordinated preemption on all hardware + * contexts between each set of BBs. Flags may be added in the future to change + * both of these default behaviors. + * + * Returns -EINVAL if hardware context placement configuration is invalid or if + * the placement configuration isn't supported on the platform / submission + * interface. + * Returns -ENODEV if extension isn't supported on the platform / submission + * interface. + * + * .. code-block:: none + * + * Example 1 pseudo code: + * CS[X] = generic engine of same class, logical instance X + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE + * set_engines(INVALID) + * set_parallel(engine_index=0, width=2, num_siblings=1, + * engines=CS[0],CS[1]) + * + * Results in the following valid placement: + * CS[0], CS[1] + * + * Example 2 pseudo code: + * CS[X] = generic engine of same class, logical instance X + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE + * set_engines(INVALID) + * set_parallel(engine_index=0, width=2, num_siblings=2, + * engines=CS[0],CS[2],CS[1],CS[3]) + * + * Results in the following valid placements: + * CS[0], CS[1] + * CS[2], CS[3] + * + * This can also be thought of as 2 virtual engines described by 2-D array + * in the engines the field with bonds placed between each index of the + * virtual engines. e.g. CS[0] is bonded to CS[1], CS[2] is bonded to + * CS[3]. + * VE[0] = CS[0], CS[2] + * VE[1] = CS[1], CS[3] + * + * Example 3 pseudo code: + * CS[X] = generic engine of same class, logical instance X + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE + * set_engines(INVALID) + * set_parallel(engine_index=0, width=2, num_siblings=2, + * engines=CS[0],CS[1],CS[1],CS[3]) + * + * Results in the following valid and invalid placements: + * CS[0], CS[1] + * CS[1], CS[3] - Not logical contiguous, return -EINVAL + */ +struct drm_i915_context_engines_parallel_submit { + /** + * @base: base user extension. + */ + struct i915_user_extension base; + + /** + * @engine_index: slot for parallel engine + */ + __u16 engine_index; + + /** + * @width: number of contexts per parallel engine + */ + __u16 width; + + /** + * @num_siblings: number of siblings per context + */ + __u16 num_siblings; + + /** + * @mbz16: reserved for future use; must be zero + */ + __u16 mbz16; + + /** + * @flags: all undefined flags must be zero, currently not defined flags + */ + __u64 flags; + + /** + * @mbz64: reserved for future use; must be zero + */ + __u64 mbz64[3]; + + /** + * @engines: 2-d array of engine instances to configure parallel engine + * + * length = width (i) * num_siblings (j) + * index = j + i * num_siblings + */ + struct i915_engine_class_instance engines[0]; + +} __packed; + diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst new file mode 100644 index 000000000000..cbda75065dad --- /dev/null +++ b/Documentation/gpu/rfc/i915_scheduler.rst @@ -0,0 +1,148 @@ +========================================= +I915 GuC Submission/DRM Scheduler Section +========================================= + +Upstream plan +============= +For upstream the overall plan for landing GuC submission and integrating the +i915 with the DRM scheduler is: + +* Merge basic GuC submission + * Basic submission support for all gen11+ platforms + * Not enabled by default on any current platforms but can be enabled via + modparam enable_guc + * Lots of rework will need to be done to integrate with DRM scheduler so + no need to nit pick everything in the code, it just should be + functional, no major coding style / layering errors, and not regress + execlists + * Update IGTs / selftests as needed to work with GuC submission + * Enable CI on supported platforms for a baseline + * Rework / get CI heathly for GuC submission in place as needed +* Merge new parallel submission uAPI + * Bonding uAPI completely incompatible with GuC submission, plus it has + severe design issues in general, which is why we want to retire it no + matter what + * New uAPI adds I915_CONTEXT_ENGINES_EXT_PARALLEL context setup step + which configures a slot with N contexts + * After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to + a slot in a single execbuf IOCTL and the batches run on the GPU in + paralllel + * Initially only for GuC submission but execlists can be supported if + needed +* Convert the i915 to use the DRM scheduler + * GuC submission backend fully integrated with DRM scheduler + * All request queues removed from backend (e.g. all backpressure + handled in DRM scheduler) + * Resets / cancels hook in DRM scheduler + * Watchdog hooks into DRM scheduler + * Lots of complexity of the GuC backend can be pulled out once + integrated with DRM scheduler (e.g. state machine gets + simplier, locking gets simplier, etc...) + * Execlists backend will minimum required to hook in the DRM scheduler + * Legacy interface + * Features like timeslicing / preemption / virtual engines would + be difficult to integrate with the DRM scheduler and these + features are not required for GuC submission as the GuC does + these things for us + * ROI low on fully integrating into DRM scheduler + * Fully integrating would add lots of complexity to DRM + scheduler + * Port i915 priority inheritance / boosting feature in DRM scheduler + * Used for i915 page flip, may be useful to other DRM drivers as + well + * Will be an optional feature in the DRM scheduler + * Remove in-order completion assumptions from DRM scheduler + * Even when using the DRM scheduler the backends will handle + preemption, timeslicing, etc... so it is possible for jobs to + finish out of order + * Pull out i915 priority levels and use DRM priority levels + * Optimize DRM scheduler as needed + +TODOs for GuC submission upstream +================================= + +* Need an update to GuC firmware / i915 to enable error state capture +* Open source tool to decode GuC logs +* Public GuC spec + +New uAPI for basic GuC submission +================================= +No major changes are required to the uAPI for basic GuC submission. The only +change is a new scheduler attribute: I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP. +This attribute indicates the 2k i915 user priority levels are statically mapped +into 3 levels as follows: + +* -1k to -1 Low priority +* 0 Medium priority +* 1 to 1k High priority + +This is needed because the GuC only has 4 priority bands. The highest priority +band is reserved with the kernel. This aligns with the DRM scheduler priority +levels too. + +Spec references: +---------------- +* https://www.khronos.org/registry/EGL/extensions/IMG/EGL_IMG_context_priority.txt +* https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/chap5.html#devsandqueues-priority +* https://spec.oneapi.com/level-zero/latest/core/api.html#ze-command-queue-priority-t + +New parallel submission uAPI +============================ +The existing bonding uAPI is completely broken with GuC submission because +whether a submission is a single context submit or parallel submit isn't known +until execbuf time activated via the I915_SUBMIT_FENCE. To submit multiple +contexts in parallel with the GuC the context must be explicitly registered with +N contexts and all N contexts must be submitted in a single command to the GuC. +The GuC interfaces do not support dynamically changing between N contexts as the +bonding uAPI does. Hence the need for a new parallel submission interface. Also +the legacy bonding uAPI is quite confusing and not intuitive at all. Furthermore +I915_SUBMIT_FENCE is by design a future fence, so not really something we should +continue to support. + +The new parallel submission uAPI consists of 3 parts: + +* Export engines logical mapping +* A 'set_parallel' extension to configure contexts for parallel + submission +* Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL + +Export engines logical mapping +------------------------------ +Certain use cases require BBs to be placed on engine instances in logical order +(e.g. split-frame on gen11+). The logical mapping of engine instances can change +based on fusing. Rather than making UMDs be aware of fusing, simply expose the +logical mapping with the existing query engine info IOCTL. Also the GuC +submission interface currently only supports submitting multiple contexts to +engines in logical order which is a new requirement compared to execlists. +Lastly, all current platforms have at most 2 engine instances and the logical +order is the same as uAPI order. This will change on platforms with more than 2 +engine instances. + +A single bit will be added to drm_i915_engine_info.flags indicating that the +logical instance has been returned and a new field, +drm_i915_engine_info.logical_instance, returns the logical instance. + +A 'set_parallel' extension to configure contexts for parallel submission +------------------------------------------------------------------------ +The 'set_parallel' extension configures a slot for parallel submission of N BBs. +It is a setup step that must be called before using any of the contexts. See +I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE or I915_CONTEXT_ENGINES_EXT_BOND for +similar existing examples. Once a slot is configured for parallel submission the +execbuf2 IOCTL can be called submitting N BBs in a single IOCTL. Initially only +supports GuC submission. Execlists supports can be added later if needed. + +Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and +drm_i915_context_engines_parallel_submit to the uAPI to implement this +extension. + +.. kernel-doc:: Documentation/gpu/rfc/i915_parallel_execbuf.h + :functions: drm_i915_context_engines_parallel_submit + +Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL +------------------------------------------------------------------- +Contexts that have been configured with the 'set_parallel' extension can only +submit N BBs in a single execbuf2 IOCTL. The BBs are either the last N objects +in the drm_i915_gem_exec_object2 list or the first N if I915_EXEC_BATCH_FIRST is +set. The number of BBs is implicit based on the slot submitted and how it has +been configured by 'set_parallel' or other extensions. No uAPI changes are +required to the execbuf2 IOCTL. diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index 05670442ca1b..91e93a705230 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -19,3 +19,7 @@ host such documentation: .. toctree:: i915_gem_lmem.rst + +.. toctree:: + + i915_scheduler.rst diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 2c9b376da5ca..941f0e7e5eef 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -98,9 +98,17 @@ with VKMS maintainers. IGT better support ------------------ -- Investigate: (1) test cases on kms_plane that are failing due to timeout on - capturing CRC; (2) when running kms_flip test cases in sequence, some - successful individual test cases are failing randomly. +Debugging: + +- kms_plane: some test cases are failing due to timeout on capturing CRC; + +- kms_flip: when running test cases in sequence, some successful individual + test cases are failing randomly; when individually, some successful test + cases display in the log the following error:: + + [drm:vkms_prepare_fb [vkms]] ERROR vmap failed: -4 + +Virtual hardware (vblank-less) mode: - VKMS already has support for vblanks simulated via hrtimers, which can be tested with kms_flip test; in some way, we can say that VKMS already mimics @@ -116,7 +124,17 @@ Add Plane Features There's lots of plane features we could add support for: -- Real overlay planes, not just cursor. +- Multiple overlay planes. [Good to get started] + +- Clearing primary plane: clear primary plane before plane composition (at the + start) for correctness of pixel blend ops. It also guarantees alpha channel + is cleared in the target buffer for stable crc. [Good to get started] + +- ARGB format on primary plane: blend the primary plane into background with + translucent alpha. + +- Support when the primary plane isn't exactly matching the output size: blend + the primary plane into the black background. - Full alpha blending on all planes. @@ -129,13 +147,8 @@ There's lots of plane features we could add support for: cursor api). For all of these, we also want to review the igt test coverage and make sure -all relevant igt testcases work on vkms. - -Prime Buffer Sharing --------------------- - -- Syzbot report - WARNING in vkms_gem_free_object: - https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0 +all relevant igt testcases work on vkms. They are good options for internship +project. Runtime Configuration --------------------- @@ -153,7 +166,7 @@ module. Use/Test-cases: the refresh rate. The currently proposed solution is to expose vkms configuration through -configfs. All existing module options should be supported through configfs +configfs. All existing module options should be supported through configfs too. Writeback support @@ -162,6 +175,7 @@ Writeback support - The writeback and CRC capture operations share the use of composer_enabled boolean to ensure vblanks. Probably, when these operations work together, composer_enabled needs to refcounting the composer state to proper work. + [Good to get started] - Add support for cloned writeback outputs and related test cases using a cloned output in the IGT kms_writeback. diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst new file mode 100644 index 000000000000..1f4bb4ba2e4b --- /dev/null +++ b/Documentation/hwmon/aquacomputer_d5next.rst @@ -0,0 +1,61 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver aquacomputer-d5next +================================= + +Supported devices: + +* Aquacomputer D5 Next watercooling pump + +Author: Aleksa Savic + +Description +----------- + +This driver exposes hardware sensors of the Aquacomputer D5 Next watercooling +pump, which communicates through a proprietary USB HID protocol. + +Available sensors are pump and fan speed, power, voltage and current, as +well as coolant temperature. Also available through debugfs are the serial +number, firmware version and power-on count. + +Attaching a fan is optional and allows it to be controlled using temperature +curves directly from the pump. If it's not connected, the fan-related sensors +will report zeroes. + +The pump can be configured either through software or via its physical +interface. Configuring the pump through this driver is not implemented, as it +seems to require sending it a complete configuration. That includes addressable +RGB LEDs, for which there is no standard sysfs interface. Thus, that task is +better suited for userspace tools. + +Usage notes +----------- + +The pump communicates via HID reports. The driver is loaded automatically by +the kernel and supports hotswapping. + +Sysfs entries +------------- + +============ ============================================= +temp1_input Coolant temperature (in millidegrees Celsius) +fan1_input Pump speed (in RPM) +fan2_input Fan speed (in RPM) +power1_input Pump power (in micro Watts) +power2_input Fan power (in micro Watts) +in0_input Pump voltage (in milli Volts) +in1_input Fan voltage (in milli Volts) +in2_input +5V rail voltage (in milli Volts) +curr1_input Pump current (in milli Amperes) +curr2_input Fan current (in milli Amperes) +============ ============================================= + +Debugfs entries +--------------- + +================ =============================================== +serial_number Serial number of the pump +firmware_version Version of installed firmware +power_cycles Count of how many times the pump was powered on +================ =============================================== diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index bc01601ea81a..f790f1260c33 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -39,6 +39,7 @@ Hardware Monitoring Kernel Drivers adt7475 aht10 amc6821 + aquacomputer_d5next asb100 asc7621 aspeed-pwm-tacho @@ -160,6 +161,7 @@ Hardware Monitoring Kernel Drivers pwm-fan q54sj108a2 raspberrypi-hwmon + sbrmi sbtsi_temp sch5627 sch5636 diff --git a/Documentation/hwmon/sbrmi.rst b/Documentation/hwmon/sbrmi.rst new file mode 100644 index 000000000000..296049e13ac9 --- /dev/null +++ b/Documentation/hwmon/sbrmi.rst @@ -0,0 +1,79 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver sbrmi +=================== + +Supported hardware: + + * Sideband Remote Management Interface (SB-RMI) compliant AMD SoC + device connected to the BMC via the APML. + + Prefix: 'sbrmi' + + Addresses scanned: This driver doesn't support address scanning. + + To instantiate this driver on an AMD CPU with SB-RMI + support, the i2c bus number would be the bus connected from the board + management controller (BMC) to the CPU. + The SMBus address is really 7 bits. Some vendors and the SMBus + specification show the address as 8 bits, left justified with the R/W + bit as a write (0) making bit 0. Some vendors use only the 7 bits + to describe the address. + As mentioned in AMD's APML specification, The SB-RMI address is + normally 78h(0111 100W) or 3Ch(011 1100) for socket 0 and 70h(0111 000W) + or 38h(011 1000) for socket 1, but it could vary based on hardware + address select pins. + + Datasheet: The SB-RMI interface and protocol along with the Advanced + Platform Management Link (APML) Specification is available + as part of the open source SoC register reference at: + + https://www.amd.com/en/support/tech-docs?keyword=55898 + +Author: Akshay Gupta <akshay.gupta@amd.com> + +Description +----------- + +The APML provides a way to communicate with the SB Remote Management interface +(SB-RMI) module from the external SMBus master that can be used to report socket +power on AMD platforms using mailbox command and resembles a typical 8-pin remote +power sensor's I2C interface to BMC. + +This driver implements current power with power cap and power cap max. + +sysfs-Interface +--------------- +Power sensors can be queried and set via the standard ``hwmon`` interface +on ``sysfs``, under the directory ``/sys/class/hwmon/hwmonX`` for some value +of ``X`` (search for the ``X`` such that ``/sys/class/hwmon/hwmonX/name`` has +content ``sbrmi``) + +================ ===== ======================================================== +Name Perm Description +================ ===== ======================================================== +power1_input RO Current Power consumed +power1_cap RW Power limit can be set between 0 and power1_cap_max +power1_cap_max RO Maximum powerlimit calculated and reported by the SMU FW +================ ===== ======================================================== + +The following example show how the 'Power' attribute from the i2c-addresses +can be monitored using the userspace utilities like ``sensors`` binary:: + + # sensors + sbrmi-i2c-1-38 + Adapter: bcm2835 I2C adapter + power1: 61.00 W (cap = 225.00 W) + + sbrmi-i2c-1-3c + Adapter: bcm2835 I2C adapter + power1: 28.39 W (cap = 224.77 W) + # + +Also, Below shows how get and set the values from sysfs entries individually:: + # cat /sys/class/hwmon/hwmon1/power1_cap_max + 225000000 + + # echo 180000000 > /sys/class/hwmon/hwmon1/power1_cap + # cat /sys/class/hwmon/hwmon1/power1_cap + 180000000 diff --git a/Documentation/hwmon/scpi-hwmon.rst b/Documentation/hwmon/scpi-hwmon.rst index eee7022b44db..1e3f83ec0658 100644 --- a/Documentation/hwmon/scpi-hwmon.rst +++ b/Documentation/hwmon/scpi-hwmon.rst @@ -32,5 +32,5 @@ Usage Notes The driver relies on device tree node to indicate the presence of SCPI support in the kernel. See -Documentation/devicetree/bindings/arm/arm,scpi.txt for details of the +Documentation/devicetree/bindings/firmware/arm,scpi.yaml for details of the devicetree node. diff --git a/Documentation/hwmon/sht4x.rst b/Documentation/hwmon/sht4x.rst index 3b37abcd4a46..c318e5582ead 100644 --- a/Documentation/hwmon/sht4x.rst +++ b/Documentation/hwmon/sht4x.rst @@ -42,4 +42,4 @@ humidity1_input Measured humidity in %H update_interval The minimum interval for polling the sensor, in milliseconds. Writable. Must be at least 2000. -============== ============================================= +=============== ============================================ diff --git a/Documentation/i2c/index.rst b/Documentation/i2c/index.rst index 8b76217e370a..6270f1fd7d4e 100644 --- a/Documentation/i2c/index.rst +++ b/Documentation/i2c/index.rst @@ -17,6 +17,7 @@ Introduction busses/index i2c-topology muxes/i2c-mux-gpio + i2c-sysfs Writing device drivers ====================== diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index b18401d2ba82..d32616891dcf 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -38,7 +38,7 @@ Cross Compiling A single Clang compiler binary will typically contain all supported backends, which can help simplify cross compiling. :: - ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang + make ARCH=arm64 CC=clang CROSS_COMPILE=aarch64-linux-gnu- ``CROSS_COMPILE`` is not used to prefix the Clang compiler binary, instead ``CROSS_COMPILE`` is used to set a command line flag: ``--target=<triple>``. For @@ -60,8 +60,27 @@ They can be enabled individually. The full list of the parameters: :: OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \ HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld -Currently, the integrated assembler is disabled by default. You can pass -``LLVM_IAS=1`` to enable it. +The integrated assembler is enabled by default. You can pass ``LLVM_IAS=0`` to +disable it. + +Omitting CROSS_COMPILE +---------------------- + +As explained above, ``CROSS_COMPILE`` is used to set ``--target=<triple>``. + +If ``CROSS_COMPILE`` is not specified, the ``--target=<triple>`` is inferred +from ``ARCH``. + +That means if you use only LLVM tools, ``CROSS_COMPILE`` becomes unnecessary. + +For example, to cross-compile the arm64 kernel:: + + make ARCH=arm64 LLVM=1 + +If ``LLVM_IAS=0`` is specified, ``CROSS_COMPILE`` is also used to derive +``--prefix=<path>`` to search for the GNU assembler and linker. :: + + make ARCH=arm64 LLVM=1 LLVM_IAS=0 CROSS_COMPILE=aarch64-linux-gnu- Supported Architectures ----------------------- @@ -111,9 +130,10 @@ Getting Help ------------ - `Website <https://clangbuiltlinux.github.io/>`_ -- `Mailing List <https://groups.google.com/forum/#!forum/clang-built-linux>`_: <clang-built-linux@googlegroups.com> +- `Mailing List <https://lore.kernel.org/llvm/>`_: <llvm@lists.linux.dev> +- `Old Mailing List Archives <https://groups.google.com/g/clang-built-linux>`_ - `Issue Tracker <https://github.com/ClangBuiltLinux/linux/issues>`_ -- IRC: #clangbuiltlinux on chat.freenode.net +- IRC: #clangbuiltlinux on irc.libera.chat - `Telegram <https://t.me/ClangBuiltLinux>`_: @ClangBuiltLinux - `Wiki <https://github.com/ClangBuiltLinux/linux/wiki>`_ - `Beginner Bugs <https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22>`_ diff --git a/Documentation/leds/well-known-leds.txt b/Documentation/leds/well-known-leds.txt new file mode 100644 index 000000000000..4a8b9dc4bf52 --- /dev/null +++ b/Documentation/leds/well-known-leds.txt @@ -0,0 +1,58 @@ +-*- org -*- + +It is somehow important to provide consistent interface to the +userland. LED devices have one problem there, and that is naming of +directories in /sys/class/leds. It would be nice if userland would +just know right "name" for given LED function, but situation got more +complex. + +Anyway, if backwards compatibility is not an issue, new code should +use one of the "good" names from this list, and you should extend the +list where applicable. + +Legacy names are listed, too; in case you are writing application that +wants to use particular feature, you should probe for good name, first, +but then try the legacy ones, too. + +Notice there's a list of functions in include/dt-bindings/leds/common.h . + +* Keyboards + +Good: "input*:*:capslock" +Good: "input*:*:scrolllock" +Good: "input*:*:numlock" +Legacy: "shift-key-light" (Motorola Droid 4, capslock) + +Set of common keyboard LEDs, going back to PC AT or so. + +Legacy: "tpacpi::thinklight" (IBM/Lenovo Thinkpads) +Legacy: "lp5523:kb{1,2,3,4,5,6}" (Nokia N900) + +Frontlight/backlight of main keyboard. + +Legacy: "button-backlight" (Motorola Droid 4) + +Some phones have touch buttons below screen; it is different from main +keyboard. And this is their backlight. + +* Sound subsystem + +Good: "platform:*:mute" +Good: "platform:*:micmute" + +LEDs on notebook body, indicating that sound input / output is muted. + +* System notification + +Legacy: "status-led:{red,green,blue}" (Motorola Droid 4) +Legacy: "lp5523:{r,g,b}" (Nokia N900) + +Phones usually have multi-color status LED. + +* Power management + +Good: "platform:*:charging" (allwinner sun50i) + +* Screen + +Good: ":backlight" (Motorola Droid 4) diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst index 42576880aa4a..60b217b436be 100644 --- a/Documentation/networking/af_xdp.rst +++ b/Documentation/networking/af_xdp.rst @@ -243,8 +243,8 @@ Configuration Flags and Socket Options These are the various configuration flags that can be used to control and monitor the behavior of AF_XDP sockets. -XDP_COPY and XDP_ZERO_COPY bind flags -------------------------------------- +XDP_COPY and XDP_ZEROCOPY bind flags +------------------------------------ When you bind to a socket, the kernel will first try to use zero-copy copy. If zero-copy is not supported, it will fall back on using copy @@ -252,7 +252,7 @@ mode, i.e. copying all packets out to user space. But if you would like to force a certain mode, you can use the following flags. If you pass the XDP_COPY flag to the bind call, the kernel will force the socket into copy mode. If it cannot use copy mode, the bind call will -fail with an error. Conversely, the XDP_ZERO_COPY flag will force the +fail with an error. Conversely, the XDP_ZEROCOPY flag will force the socket into zero-copy mode or fail. XDP_SHARED_UMEM bind flag diff --git a/Documentation/networking/batman-adv.rst b/Documentation/networking/batman-adv.rst index 74821d29a22f..b85563ea3682 100644 --- a/Documentation/networking/batman-adv.rst +++ b/Documentation/networking/batman-adv.rst @@ -157,7 +157,7 @@ Contact Please send us comments, experiences, questions, anything :) IRC: - #batman on irc.freenode.org + #batadv on ircs://irc.hackint.org/ Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription at https://lists.open-mesh.org/mailman3/postorius/lists/b.a.t.m.a.n.lists.open-mesh.org/) diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index 62f2aab8eaec..31cfd7d674a6 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -501,6 +501,18 @@ fail_over_mac This option was added in bonding version 3.2.0. The "follow" policy was added in bonding version 3.3.0. +lacp_active + Option specifying whether to send LACPDU frames periodically. + + off or 0 + LACPDU frames acts as "speak when spoken to". + + on or 1 + LACPDU frames are sent along the configured links + periodically. See lacp_rate for more details. + + The default is on. + lacp_rate Option specifying the rate in which we'll ask our link partner diff --git a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst index ee40fcc5ddff..62f4a4aff6ec 100644 --- a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst @@ -9,3 +9,4 @@ DPAA2 Documentation dpio-driver ethernet-driver mac-phy-support + switch-driver diff --git a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst new file mode 100644 index 000000000000..8bf411b857d4 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst @@ -0,0 +1,217 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +=================== +DPAA2 Switch driver +=================== + +:Copyright: |copy| 2021 NXP + +The DPAA2 Switch driver probes on the Datapath Switch (DPSW) object which can +be instantiated on the following DPAA2 SoCs and their variants: LS2088A and +LX2160A. + +The driver uses the switch device driver model and exposes each switch port as +a network interface, which can be included in a bridge or used as a standalone +interface. Traffic switched between ports is offloaded into the hardware. + +The DPSW can have ports connected to DPNIs or to DPMACs for external access. +:: + + [ethA] [ethB] [ethC] [ethD] [ethE] [ethF] + : : : : : : + : : : : : : + [dpaa2-eth] [dpaa2-eth] [ dpaa2-switch ] + : : : : : : kernel + ============================================================================= + : : : : : : hardware + [DPNI] [DPNI] [============= DPSW =================] + | | | | | | + | ---------- | [DPMAC] [DPMAC] + ------------------------------- | | + | | + [PHY] [PHY] + +Creating an Ethernet Switch +=========================== + +The dpaa2-switch driver probes on DPSW devices found on the fsl-mc bus. These +devices can be either created statically through the boot time configuration +file - DataPath Layout (DPL) - or at runtime using the DPAA2 object APIs +(incorporated already into the restool userspace tool). + +At the moment, the dpaa2-switch driver imposes the following restrictions on +the DPSW object that it will probe: + + * The minimum number of FDBs should be at least equal to the number of switch + interfaces. This is necessary so that separation of switch ports can be + done, ie when not under a bridge, each switch port will have its own FDB. + :: + + fsl_dpaa2_switch dpsw.0: The number of FDBs is lower than the number of ports, cannot probe + + * Both the broadcast and flooding configuration should be per FDB. This + enables the driver to restrict the broadcast and flooding domains of each + FDB depending on the switch ports that are sharing it (aka are under the + same bridge). + :: + + fsl_dpaa2_switch dpsw.0: Flooding domain is not per FDB, cannot probe + fsl_dpaa2_switch dpsw.0: Broadcast domain is not per FDB, cannot probe + + * The control interface of the switch should not be disabled + (DPSW_OPT_CTRL_IF_DIS not passed as a create time option). Without the + control interface, the driver is not capable to provide proper Rx/Tx traffic + support on the switch port netdevices. + :: + + fsl_dpaa2_switch dpsw.0: Control Interface is disabled, cannot probe + +Besides the configuration of the actual DPSW object, the dpaa2-switch driver +will need the following DPAA2 objects: + + * 1 DPMCP - A Management Command Portal object is needed for any interraction + with the MC firmware. + + * 1 DPBP - A Buffer Pool is used for seeding buffers intended for the Rx path + on the control interface. + + * Access to at least one DPIO object (Software Portal) is needed for any + enqueue/dequeue operation to be performed on the control interface queues. + The DPIO object will be shared, no need for a private one. + +Switching features +================== + +The driver supports the configuration of L2 forwarding rules in hardware for +port bridging as well as standalone usage of the independent switch interfaces. + +The hardware is not configurable with respect to VLAN awareness, thus any DPAA2 +switch port should be used only in usecases with a VLAN aware bridge:: + + $ ip link add dev br0 type bridge vlan_filtering 1 + + $ ip link add dev br1 type bridge + $ ip link set dev ethX master br1 + Error: fsl_dpaa2_switch: Cannot join a VLAN-unaware bridge + +Topology and loop detection through STP is supported when ``stp_state 1`` is +used at bridge create :: + + $ ip link add dev br0 type bridge vlan_filtering 1 stp_state 1 + +L2 FDB manipulation (add/delete/dump) is supported. + +HW FDB learning can be configured on each switch port independently through +bridge commands. When the HW learning is disabled, a fast age procedure will be +run and any previously learnt addresses will be removed. +:: + + $ bridge link set dev ethX learning off + $ bridge link set dev ethX learning on + +Restricting the unknown unicast and multicast flooding domain is supported, but +not independently of each other:: + + $ ip link set dev ethX type bridge_slave flood off mcast_flood off + $ ip link set dev ethX type bridge_slave flood off mcast_flood on + Error: fsl_dpaa2_switch: Cannot configure multicast flooding independently of unicast. + +Broadcast flooding on a switch port can be disabled/enabled through the brport sysfs:: + + $ echo 0 > /sys/bus/fsl-mc/devices/dpsw.Y/net/ethX/brport/broadcast_flood + +Offloads +======== + +Routing actions (redirect, trap, drop) +-------------------------------------- + +The DPAA2 switch is able to offload flow-based redirection of packets making +use of ACL tables. Shared filter blocks are supported by sharing a single ACL +table between multiple ports. + +The following flow keys are supported: + + * Ethernet: dst_mac/src_mac + * IPv4: dst_ip/src_ip/ip_proto/tos + * VLAN: vlan_id/vlan_prio/vlan_tpid/vlan_dei + * L4: dst_port/src_port + +Also, the matchall filter can be used to redirect the entire traffic received +on a port. + +As per flow actions, the following are supported: + + * drop + * mirred egress redirect + * trap + +Each ACL entry (filter) can be setup with only one of the listed +actions. + +Example 1: send frames received on eth4 with a SA of 00:01:02:03:04:05 to the +CPU:: + + $ tc qdisc add dev eth4 clsact + $ tc filter add dev eth4 ingress flower src_mac 00:01:02:03:04:05 skip_sw action trap + +Example 2: drop frames received on eth4 with VID 100 and PCP of 3:: + + $ tc filter add dev eth4 ingress protocol 802.1q flower skip_sw vlan_id 100 vlan_prio 3 action drop + +Example 3: redirect all frames received on eth4 to eth1:: + + $ tc filter add dev eth4 ingress matchall action mirred egress redirect dev eth1 + +Example 4: Use a single shared filter block on both eth5 and eth6:: + + $ tc qdisc add dev eth5 ingress_block 1 clsact + $ tc qdisc add dev eth6 ingress_block 1 clsact + $ tc filter add block 1 ingress flower dst_mac 00:01:02:03:04:04 skip_sw \ + action trap + $ tc filter add block 1 ingress protocol ipv4 flower src_ip 192.168.1.1 skip_sw \ + action mirred egress redirect dev eth3 + +Mirroring +~~~~~~~~~ + +The DPAA2 switch supports only per port mirroring and per VLAN mirroring. +Adding mirroring filters in shared blocks is also supported. + +When using the tc-flower classifier with the 802.1q protocol, only the +''vlan_id'' key will be accepted. Mirroring based on any other fields from the +802.1q protocol will be rejected:: + + $ tc qdisc add dev eth8 ingress_block 1 clsact + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_prio 3 action mirred egress mirror dev eth6 + Error: fsl_dpaa2_switch: Only matching on VLAN ID supported. + We have an error talking to the kernel + +If a mirroring VLAN filter is requested on a port, the VLAN must to be +installed on the switch port in question either using ''bridge'' or by creating +a VLAN upper device if the switch port is used as a standalone interface:: + + $ tc qdisc add dev eth8 ingress_block 1 clsact + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + Error: VLAN must be installed on the switch port. + We have an error talking to the kernel + + $ bridge vlan add vid 200 dev eth8 + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + + $ ip link add link eth8 name eth8.200 type vlan id 200 + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + +Also, it should be noted that the mirrored traffic will be subject to the same +egress restrictions as any other traffic. This means that when a mirrored +packet will reach the mirror port, if the VLAN found in the packet is not +installed on the port it will get dropped. + +The DPAA2 switch supports only a single mirroring destination, thus multiple +mirror rules can be installed but their ''to'' port has to be the same:: + + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 100 action mirred egress mirror dev eth7 + Error: fsl_dpaa2_switch: Multiple mirror ports not supported. + We have an error talking to the kernel diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst index ef8cb62e82a1..4b59cf2c599f 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst @@ -656,3 +656,47 @@ Bridge offloads tracepoints: $ cat /sys/kernel/debug/tracing/trace ... ip-5387 [000] ...1 573713: mlx5_esw_bridge_vport_cleanup: vport_num=1 + +Eswitch QoS tracepoints: + +- mlx5_esw_vport_qos_create: trace creation of transmit scheduler arbiter for vport:: + + $ echo mlx5:mlx5_esw_vport_qos_create >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-23496 [018] .... 73136.838831: mlx5_esw_vport_qos_create: (0000:82:00.0) vport=2 tsar_ix=4 bw_share=0, max_rate=0 group=000000007b576bb3 + +- mlx5_esw_vport_qos_config: trace configuration of transmit scheduler arbiter for vport:: + + $ echo mlx5:mlx5_esw_vport_qos_config >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-26548 [023] .... 75754.223823: mlx5_esw_vport_qos_config: (0000:82:00.0) vport=1 tsar_ix=3 bw_share=34, max_rate=10000 group=000000007b576bb3 + +- mlx5_esw_vport_qos_destroy: trace deletion of transmit scheduler arbiter for vport:: + + $ echo mlx5:mlx5_esw_vport_qos_destroy >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-27418 [004] .... 76546.680901: mlx5_esw_vport_qos_destroy: (0000:82:00.0) vport=1 tsar_ix=3 + +- mlx5_esw_group_qos_create: trace creation of transmit scheduler arbiter for rate group:: + + $ echo mlx5:mlx5_esw_group_qos_create >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-26578 [008] .... 75776.022112: mlx5_esw_group_qos_create: (0000:82:00.0) group=000000008dac63ea tsar_ix=5 + +- mlx5_esw_group_qos_config: trace configuration of transmit scheduler arbiter for rate group:: + + $ echo mlx5:mlx5_esw_group_qos_config >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-27303 [020] .... 76461.455356: mlx5_esw_group_qos_config: (0000:82:00.0) group=000000008dac63ea tsar_ix=5 bw_share=100 max_rate=20000 + +- mlx5_esw_group_qos_destroy: trace deletion of transmit scheduler arbiter for group:: + + $ echo mlx5:mlx5_esw_group_qos_destroy >> /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace + ... + <...>-27418 [006] .... 76547.187258: mlx5_esw_group_qos_destroy: (0000:82:00.0) group=000000007b576bb3 tsar_ix=1 diff --git a/Documentation/networking/devlink/devlink-params.rst b/Documentation/networking/devlink/devlink-params.rst index 54c9f107c4b0..4878907e9232 100644 --- a/Documentation/networking/devlink/devlink-params.rst +++ b/Documentation/networking/devlink/devlink-params.rst @@ -97,6 +97,18 @@ own name. * - ``enable_roce`` - Boolean - Enable handling of RoCE traffic in the device. + * - ``enable_eth`` + - Boolean + - When enabled, the device driver will instantiate Ethernet specific + auxiliary device of the devlink device. + * - ``enable_rdma`` + - Boolean + - When enabled, the device driver will instantiate RDMA specific + auxiliary device of the devlink device. + * - ``enable_vnet`` + - Boolean + - When enabled, the device driver will instantiate VDPA networking + specific auxiliary device of the devlink device. * - ``internal_err_reset`` - Boolean - When enabled, the device driver will reset the device on internal diff --git a/Documentation/networking/devlink/hns3.rst b/Documentation/networking/devlink/hns3.rst new file mode 100644 index 000000000000..4562a6e4782f --- /dev/null +++ b/Documentation/networking/devlink/hns3.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +hns3 devlink support +==================== + +This document describes the devlink features implemented by the ``hns3`` +device driver. + +The ``hns3`` driver supports reloading via ``DEVLINK_CMD_RELOAD``. + +Info versions +============= + +The ``hns3`` driver reports the following versions + +.. list-table:: devlink info versions implemented + :widths: 10 10 80 + + * - Name + - Type + - Description + * - ``fw`` + - running + - Used to represent the firmware version. diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index b3b9e0692088..45b5f8b341df 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -34,6 +34,7 @@ parameters, info versions, and other features it supports. :maxdepth: 1 bnxt + hns3 ionic ice mlx4 @@ -42,7 +43,6 @@ parameters, info versions, and other features it supports. mv88e6xxx netdevsim nfp - sja1105 qed ti-cpsw-switch am65-nuss-cpsw-switch diff --git a/Documentation/networking/devlink/sja1105.rst b/Documentation/networking/devlink/sja1105.rst deleted file mode 100644 index e2679c274085..000000000000 --- a/Documentation/networking/devlink/sja1105.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -======================= -sja1105 devlink support -======================= - -This document describes the devlink features implemented -by the ``sja1105`` device driver. - -Parameters -========== - -.. list-table:: Driver-specific parameters implemented - :widths: 5 5 5 85 - - * - Name - - Type - - Mode - - Description - * - ``best_effort_vlan_filtering`` - - Boolean - - runtime - - Allow plain ETH_P_8021Q headers to be used as DSA tags. - - Benefits: - - - Can terminate untagged traffic over switch net - devices even when enslaved to a bridge with - vlan_filtering=1. - - Can terminate VLAN-tagged traffic over switch net - devices even when enslaved to a bridge with - vlan_filtering=1, with some constraints (no more than - 7 non-pvid VLANs per user port). - - Can do QoS based on VLAN PCP and VLAN membership - admission control for autonomously forwarded frames - (regardless of whether they can be terminated on the - CPU or not). - - Drawbacks: - - - User cannot use VLANs in range 1024-3071. If the - switch receives frames with such VIDs, it will - misinterpret them as DSA tags. - - Switch uses Shared VLAN Learning (FDB lookup uses - only DMAC as key). - - When VLANs span cross-chip topologies, the total - number of permitted VLANs may be less than 7 per - port, due to a maximum number of 32 VLAN retagging - rules per switch. diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 20baacf2bc5c..89bb4fa4c362 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -200,19 +200,6 @@ receive all frames regardless of the value of the MAC DA. This can be done by setting the ``promisc_on_master`` property of the ``struct dsa_device_ops``. Note that this assumes a DSA-unaware master driver, which is the norm. -Hardware manufacturers are strongly discouraged to do this, but some tagging -protocols might not provide source port information on RX for all packets, but -e.g. only for control traffic (link-local PDUs). In this case, by implementing -the ``filter`` method of ``struct dsa_device_ops``, the tagger might select -which packets are to be redirected on RX towards the virtual DSA user network -interfaces, and which are to be left in the DSA master's RX data path. - -It might also happen (although silicon vendors are strongly discouraged to -produce hardware like this) that a tagging protocol splits the switch-specific -information into a header portion and a tail portion, therefore not falling -cleanly into any of the above 3 categories. DSA does not support this -configuration. - Master network devices ---------------------- @@ -663,6 +650,22 @@ Bridge layer CPU port, and flooding towards the CPU port should also be enabled, due to a lack of an explicit address filtering mechanism in the DSA core. +- ``port_bridge_tx_fwd_offload``: bridge layer function invoked after + ``port_bridge_join`` when a driver sets ``ds->num_fwd_offloading_bridges`` to + a non-zero value. Returning success in this function activates the TX + forwarding offload bridge feature for this port, which enables the tagging + protocol driver to inject data plane packets towards the bridging domain that + the port is a part of. Data plane packets are subject to FDB lookup, hardware + learning on the CPU port, and do not override the port STP state. + Additionally, replication of data plane packets (multicast, flooding) is + handled in hardware and the bridge driver will transmit a single skb for each + packet that needs replication. The method is provided as a configuration + point for drivers that need to configure the hardware for enabling this + feature. + +- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoken when a driver + leaves a bridge port which had the TX forwarding offload feature enabled. + Bridge VLAN filtering --------------------- diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst index da4057ba37f1..564caeebe2b2 100644 --- a/Documentation/networking/dsa/sja1105.rst +++ b/Documentation/networking/dsa/sja1105.rst @@ -65,199 +65,6 @@ If that changed setting can be transmitted to the switch through the dynamic reconfiguration interface, it is; otherwise the switch is reset and reprogrammed with the updated static configuration. -Traffic support -=============== - -The switches do not have hardware support for DSA tags, except for "slow -protocols" for switch control as STP and PTP. For these, the switches have two -programmable filters for link-local destination MACs. -These are used to trap BPDUs and PTP traffic to the master netdevice, and are -further used to support STP and 1588 ordinary clock/boundary clock -functionality. For frames trapped to the CPU, source port and switch ID -information is encoded by the hardware into the frames. - -But by leveraging ``CONFIG_NET_DSA_TAG_8021Q`` (a software-defined DSA tagging -format based on VLANs), general-purpose traffic termination through the network -stack can be supported under certain circumstances. - -Depending on VLAN awareness state, the following operating modes are possible -with the switch: - -- Mode 1 (VLAN-unaware): a port is in this mode when it is used as a standalone - net device, or when it is enslaved to a bridge with ``vlan_filtering=0``. -- Mode 2 (fully VLAN-aware): a port is in this mode when it is enslaved to a - bridge with ``vlan_filtering=1``. Access to the entire VLAN range is given to - the user through ``bridge vlan`` commands, but general-purpose (anything - other than STP, PTP etc) traffic termination is not possible through the - switch net devices. The other packets can be still by user space processed - through the DSA master interface (similar to ``DSA_TAG_PROTO_NONE``). -- Mode 3 (best-effort VLAN-aware): a port is in this mode when enslaved to a - bridge with ``vlan_filtering=1``, and the devlink property of its parent - switch named ``best_effort_vlan_filtering`` is set to ``true``. When - configured like this, the range of usable VIDs is reduced (0 to 1023 and 3072 - to 4094), so is the number of usable VIDs (maximum of 7 non-pvid VLANs per - port*), and shared VLAN learning is performed (FDB lookup is done only by - DMAC, not also by VID). - -To summarize, in each mode, the following types of traffic are supported over -the switch net devices: - -+-------------+-----------+--------------+------------+ -| | Mode 1 | Mode 2 | Mode 3 | -+=============+===========+==============+============+ -| Regular | Yes | No | Yes | -| traffic | | (use master) | | -+-------------+-----------+--------------+------------+ -| Management | Yes | Yes | Yes | -| traffic | | | | -| (BPDU, PTP) | | | | -+-------------+-----------+--------------+------------+ - -To configure the switch to operate in Mode 3, the following steps can be -followed:: - - ip link add dev br0 type bridge - # swp2 operates in Mode 1 now - ip link set dev swp2 master br0 - # swp2 temporarily moves to Mode 2 - ip link set dev br0 type bridge vlan_filtering 1 - [ 61.204770] sja1105 spi0.1: Reset switch and programmed static config. Reason: VLAN filtering - [ 61.239944] sja1105 spi0.1: Disabled switch tagging - # swp3 now operates in Mode 3 - devlink dev param set spi/spi0.1 name best_effort_vlan_filtering value true cmode runtime - [ 64.682927] sja1105 spi0.1: Reset switch and programmed static config. Reason: VLAN filtering - [ 64.711925] sja1105 spi0.1: Enabled switch tagging - # Cannot use VLANs in range 1024-3071 while in Mode 3. - bridge vlan add dev swp2 vid 1025 untagged pvid - RTNETLINK answers: Operation not permitted - bridge vlan add dev swp2 vid 100 - bridge vlan add dev swp2 vid 101 untagged - bridge vlan - port vlan ids - swp5 1 PVID Egress Untagged - - swp2 1 PVID Egress Untagged - 100 - 101 Egress Untagged - - swp3 1 PVID Egress Untagged - - swp4 1 PVID Egress Untagged - - br0 1 PVID Egress Untagged - bridge vlan add dev swp2 vid 102 - bridge vlan add dev swp2 vid 103 - bridge vlan add dev swp2 vid 104 - bridge vlan add dev swp2 vid 105 - bridge vlan add dev swp2 vid 106 - bridge vlan add dev swp2 vid 107 - # Cannot use mode than 7 VLANs per port while in Mode 3. - [ 3885.216832] sja1105 spi0.1: No more free subvlans - -\* "maximum of 7 non-pvid VLANs per port": Decoding VLAN-tagged packets on the -CPU in mode 3 is possible through VLAN retagging of packets that go from the -switch to the CPU. In cross-chip topologies, the port that goes to the CPU -might also go to other switches. In that case, those other switches will see -only a retagged packet (which only has meaning for the CPU). So if they are -interested in this VLAN, they need to apply retagging in the reverse direction, -to recover the original value from it. This consumes extra hardware resources -for this switch. There is a maximum of 32 entries in the Retagging Table of -each switch device. - -As an example, consider this cross-chip topology:: - - +-------------------------------------------------+ - | Host SoC | - | +-------------------------+ | - | | DSA master for embedded | | - | | switch (non-sja1105) | | - | +--------+-------------------------+--------+ | - | | embedded L2 switch | | - | | | | - | | +--------------+ +--------------+ | | - | | |DSA master for| |DSA master for| | | - | | | SJA1105 1 | | SJA1105 2 | | | - +--+---+--------------+-----+--------------+---+--+ - - +-----------------------+ +-----------------------+ - | SJA1105 switch 1 | | SJA1105 switch 2 | - +-----+-----+-----+-----+ +-----+-----+-----+-----+ - |sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| - +-----+-----+-----+-----+ +-----+-----+-----+-----+ - -To reach the CPU, SJA1105 switch 1 (spi/spi2.1) uses the same port as is uses -to reach SJA1105 switch 2 (spi/spi2.2), which would be port 4 (not drawn). -Similarly for SJA1105 switch 2. - -Also consider the following commands, that add VLAN 100 to every sja1105 user -port:: - - devlink dev param set spi/spi2.1 name best_effort_vlan_filtering value true cmode runtime - devlink dev param set spi/spi2.2 name best_effort_vlan_filtering value true cmode runtime - ip link add dev br0 type bridge - for port in sw1p0 sw1p1 sw1p2 sw1p3 \ - sw2p0 sw2p1 sw2p2 sw2p3; do - ip link set dev $port master br0 - done - ip link set dev br0 type bridge vlan_filtering 1 - for port in sw1p0 sw1p1 sw1p2 sw1p3 \ - sw2p0 sw2p1 sw2p2; do - bridge vlan add dev $port vid 100 - done - ip link add link br0 name br0.100 type vlan id 100 && ip link set dev br0.100 up - ip addr add 192.168.100.3/24 dev br0.100 - bridge vlan add dev br0 vid 100 self - - bridge vlan - port vlan ids - sw1p0 1 PVID Egress Untagged - 100 - - sw1p1 1 PVID Egress Untagged - 100 - - sw1p2 1 PVID Egress Untagged - 100 - - sw1p3 1 PVID Egress Untagged - 100 - - sw2p0 1 PVID Egress Untagged - 100 - - sw2p1 1 PVID Egress Untagged - 100 - - sw2p2 1 PVID Egress Untagged - 100 - - sw2p3 1 PVID Egress Untagged - - br0 1 PVID Egress Untagged - 100 - -SJA1105 switch 1 consumes 1 retagging entry for each VLAN on each user port -towards the CPU. It also consumes 1 retagging entry for each non-pvid VLAN that -it is also interested in, which is configured on any port of any neighbor -switch. - -In this case, SJA1105 switch 1 consumes a total of 11 retagging entries, as -follows: - -- 8 retagging entries for VLANs 1 and 100 installed on its user ports - (``sw1p0`` - ``sw1p3``) -- 3 retagging entries for VLAN 100 installed on the user ports of SJA1105 - switch 2 (``sw2p0`` - ``sw2p2``), because it also has ports that are - interested in it. The VLAN 1 is a pvid on SJA1105 switch 2 and does not need - reverse retagging. - -SJA1105 switch 2 also consumes 11 retagging entries, but organized as follows: - -- 7 retagging entries for the bridge VLANs on its user ports (``sw2p0`` - - ``sw2p3``). -- 4 retagging entries for VLAN 100 installed on the user ports of SJA1105 - switch 1 (``sw1p0`` - ``sw1p3``). - Switching features ================== @@ -282,33 +89,10 @@ untagged), and therefore this mode is also supported. Segregating the switch ports in multiple bridges is supported (e.g. 2 + 2), but all bridges should have the same level of VLAN awareness (either both have -``vlan_filtering`` 0, or both 1). Also an inevitable limitation of the fact -that VLAN awareness is global at the switch level is that once a bridge with -``vlan_filtering`` enslaves at least one switch port, the other un-bridged -ports are no longer available for standalone traffic termination. +``vlan_filtering`` 0, or both 1). Topology and loop detection through STP is supported. -L2 FDB manipulation (add/delete/dump) is currently possible for the first -generation devices. Aging time of FDB entries, as well as enabling fully static -management (no address learning and no flooding of unknown traffic) is not yet -configurable in the driver. - -A special comment about bridging with other netdevices (illustrated with an -example): - -A board has eth0, eth1, swp0@eth1, swp1@eth1, swp2@eth1, swp3@eth1. -The switch ports (swp0-3) are under br0. -It is desired that eth0 is turned into another switched port that communicates -with swp0-3. - -If br0 has vlan_filtering 0, then eth0 can simply be added to br0 with the -intended results. -If br0 has vlan_filtering 1, then a new br1 interface needs to be created that -enslaves eth0 and eth1 (the DSA master of the switch ports). This is because in -this mode, the switch ports beneath br0 are not capable of regular traffic, and -are only used as a conduit for switchdev operations. - Offloads ======== diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 6ea91e41593f..d9b55b7a1a4d 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -212,6 +212,7 @@ Userspace to kernel: ``ETHTOOL_MSG_FEC_SET`` set FEC settings ``ETHTOOL_MSG_MODULE_EEPROM_GET`` read SFP module EEPROM ``ETHTOOL_MSG_STATS_GET`` get standard statistics + ``ETHTOOL_MSG_PHC_VCLOCKS_GET`` get PHC virtual clocks info ===================================== ================================ Kernel to userspace: @@ -250,6 +251,7 @@ Kernel to userspace: ``ETHTOOL_MSG_FEC_NTF`` FEC settings ``ETHTOOL_MSG_MODULE_EEPROM_GET_REPLY`` read SFP module EEPROM ``ETHTOOL_MSG_STATS_GET_REPLY`` standard statistics + ``ETHTOOL_MSG_PHC_VCLOCKS_GET_REPLY`` PHC virtual clocks info ======================================== ================================= ``GET`` requests are sent by userspace applications to retrieve device @@ -593,6 +595,14 @@ Link extended substates: that is not formally supported, which led to signal integrity issues + + ``ETHTOOL_LINK_EXT_SUBSTATE_BSI_SERDES_REFERENCE_CLOCK_LOST`` The external clock signal for + SerDes is too weak or + unavailable. + + ``ETHTOOL_LINK_EXT_SUBSTATE_BSI_SERDES_ALOS`` The received signal for + SerDes is too weak because + analog loss of signal. ================================================================= ============================= Cable issue substates: @@ -937,12 +947,25 @@ Kernel response contents: ``ETHTOOL_A_COALESCE_TX_USECS_HIGH`` u32 delay (us), high Tx ``ETHTOOL_A_COALESCE_TX_MAX_FRAMES_HIGH`` u32 max packets, high Tx ``ETHTOOL_A_COALESCE_RATE_SAMPLE_INTERVAL`` u32 rate sampling interval + ``ETHTOOL_A_COALESCE_USE_CQE_TX`` bool timer reset mode, Tx + ``ETHTOOL_A_COALESCE_USE_CQE_RX`` bool timer reset mode, Rx =========================================== ====== ======================= Attributes are only included in reply if their value is not zero or the corresponding bit in ``ethtool_ops::supported_coalesce_params`` is set (i.e. they are declared as supported by driver). +Timer reset mode (``ETHTOOL_A_COALESCE_USE_CQE_TX`` and +``ETHTOOL_A_COALESCE_USE_CQE_RX``) controls the interaction between packet +arrival and the various time based delay parameters. By default timers are +expected to limit the max delay between any packet arrival/departure and a +corresponding interrupt. In this mode timer should be started by packet +arrival (sometimes delivery of previous interrupt) and reset when interrupt +is delivered. +Setting the appropriate attribute to 1 will enable ``CQE`` mode, where +each packet event resets the timer. In this mode timer is used to force +the interrupt if queue goes idle, while busy queues depend on the packet +limit to trigger interrupts. COALESCE_SET ============ @@ -975,6 +998,8 @@ Request contents: ``ETHTOOL_A_COALESCE_TX_USECS_HIGH`` u32 delay (us), high Tx ``ETHTOOL_A_COALESCE_TX_MAX_FRAMES_HIGH`` u32 max packets, high Tx ``ETHTOOL_A_COALESCE_RATE_SAMPLE_INTERVAL`` u32 rate sampling interval + ``ETHTOOL_A_COALESCE_USE_CQE_TX`` bool timer reset mode, Tx + ``ETHTOOL_A_COALESCE_USE_CQE_RX`` bool timer reset mode, Rx =========================================== ====== ======================= Request is rejected if it attributes declared as unsupported by driver (i.e. @@ -1477,6 +1502,25 @@ Low and high bounds are inclusive, for example: etherStatsPkts512to1023Octets 512 1023 ============================= ==== ==== +PHC_VCLOCKS_GET +=============== + +Query device PHC virtual clocks information. + +Request contents: + + ==================================== ====== ========================== + ``ETHTOOL_A_PHC_VCLOCKS_HEADER`` nested request header + ==================================== ====== ========================== + +Kernel response contents: + + ==================================== ====== ========================== + ``ETHTOOL_A_PHC_VCLOCKS_HEADER`` nested reply header + ``ETHTOOL_A_PHC_VCLOCKS_NUM`` u32 PHC virtual clocks number + ``ETHTOOL_A_PHC_VCLOCKS_INDEX`` s32 PHC index array + ==================================== ====== ========================== + Request translation =================== @@ -1575,4 +1619,5 @@ are netlink only. n/a ``ETHTOOL_MSG_CABLE_TEST_ACT`` n/a ``ETHTOOL_MSG_CABLE_TEST_TDR_ACT`` n/a ``ETHTOOL_MSG_TUNNEL_INFO_GET`` + n/a ``ETHTOOL_MSG_PHC_VCLOCKS_GET`` =================================== ===================================== diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst index 3e2221f4abe4..ce2b8e8bb9ab 100644 --- a/Documentation/networking/filter.rst +++ b/Documentation/networking/filter.rst @@ -320,13 +320,6 @@ Examples for low-level BPF: ret #-1 drop: ret #0 -**(Accelerated) VLAN w/ id 10**:: - - ld vlan_tci - jneq #10, drop - ret #-1 - drop: ret #0 - **icmp random packet sampling, 1 in 4**:: ldh [12] @@ -358,6 +351,22 @@ Examples for low-level BPF: bad: ret #0 /* SECCOMP_RET_KILL_THREAD */ good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */ +Examples for low-level BPF extension: + +**Packet for interface index 13**:: + + ld ifidx + jneq #13, drop + ret #-1 + drop: ret #0 + +**(Accelerated) VLAN w/ id 10**:: + + ld vlan_tci + jneq #10, drop + ret #-1 + drop: ret #0 + The above example code can be placed into a file (here called "foo"), and then be passed to the bpf_asm tool for generating opcodes, output that xt_bpf and cls_bpf understands and can directly be loaded with. Example with above @@ -629,8 +638,8 @@ extension, PTP dissector/classifier, and much more. They are all internally converted by the kernel into the new instruction set representation and run in the eBPF interpreter. For in-kernel handlers, this all works transparently by using bpf_prog_create() for setting up the filter, resp. -bpf_prog_destroy() for destroying it. The macro -BPF_PROG_RUN(filter, ctx) transparently invokes eBPF interpreter or JITed +bpf_prog_destroy() for destroying it. The function +bpf_prog_run(filter, ctx) transparently invokes eBPF interpreter or JITed code to run the filter. 'filter' is a pointer to struct bpf_prog that we got from bpf_prog_create(), and 'ctx' the given context (e.g. skb pointer). All constraints and restrictions from bpf_check_classic() apply diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index e9ce55992aa9..58bc8cd367c6 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -57,6 +57,7 @@ Contents: gen_stats gtp ila + ioam6-sysctl ipddp ip_dynaddr ipsec @@ -68,6 +69,7 @@ Contents: l2tp lapb-module mac80211-injection + mctp mpls-sysctl mptcp-sysctl multiqueue diff --git a/Documentation/networking/ioam6-sysctl.rst b/Documentation/networking/ioam6-sysctl.rst new file mode 100644 index 000000000000..c18cab2c481a --- /dev/null +++ b/Documentation/networking/ioam6-sysctl.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +IOAM6 Sysfs variables +===================== + + +/proc/sys/net/conf/<iface>/ioam6_* variables: +============================================= + +ioam6_enabled - BOOL + Accept (= enabled) or ignore (= disabled) IPv6 IOAM options on ingress + for this interface. + + * 0 - disabled (default) + * 1 - enabled + +ioam6_id - SHORT INTEGER + Define the IOAM id of this interface. + + Default is ~0. + +ioam6_id_wide - INTEGER + Define the wide IOAM id of this interface. + + Default is ~0. diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index b3fa522e4cd9..d91ab28718d4 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -826,7 +826,7 @@ tcp_fastopen_blackhole_timeout_sec - INTEGER initial value when the blackhole issue goes away. 0 to disable the blackhole detection. - By default, it is set to 1hr. + By default, it is set to 0 (feature is disabled). tcp_fastopen_key - list of comma separated 32-digit hexadecimal INTEGERs The list consists of a primary key and an optional backup key. The @@ -1926,6 +1926,23 @@ fib_notify_on_flag_change - INTEGER - 1 - Emit notifications. - 2 - Emit notifications only for RTM_F_OFFLOAD_FAILED flag change. +ioam6_id - INTEGER + Define the IOAM id of this node. Uses only 24 bits out of 32 in total. + + Min: 0 + Max: 0xFFFFFF + + Default: 0xFFFFFF + +ioam6_id_wide - LONG INTEGER + Define the wide IOAM id of this node. Uses only 56 bits out of 64 in + total. Can be different from ioam6_id. + + Min: 0 + Max: 0xFFFFFFFFFFFFFF + + Default: 0xFFFFFFFFFFFFFF + IPv6 Fragmentation: ip6frag_high_thresh - INTEGER diff --git a/Documentation/networking/mctp.rst b/Documentation/networking/mctp.rst new file mode 100644 index 000000000000..6100cdc220f6 --- /dev/null +++ b/Documentation/networking/mctp.rst @@ -0,0 +1,213 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================== +Management Component Transport Protocol (MCTP) +============================================== + +net/mctp/ contains protocol support for MCTP, as defined by DMTF standard +DSP0236. Physical interface drivers ("bindings" in the specification) are +provided in drivers/net/mctp/. + +The core code provides a socket-based interface to send and receive MCTP +messages, through an AF_MCTP, SOCK_DGRAM socket. + +Structure: interfaces & networks +================================ + +The kernel models the local MCTP topology through two items: interfaces and +networks. + +An interface (or "link") is an instance of an MCTP physical transport binding +(as defined by DSP0236, section 3.2.47), likely connected to a specific hardware +device. This is represented as a ``struct netdevice``. + +A network defines a unique address space for MCTP endpoints by endpoint-ID +(described by DSP0236, section 3.2.31). A network has a user-visible identifier +to allow references from userspace. Route definitions are specific to one +network. + +Interfaces are associated with one network. A network may be associated with one +or more interfaces. + +If multiple networks are present, each may contain endpoint IDs (EIDs) that are +also present on other networks. + +Sockets API +=========== + +Protocol definitions +-------------------- + +MCTP uses ``AF_MCTP`` / ``PF_MCTP`` for the address- and protocol- families. +Since MCTP is message-based, only ``SOCK_DGRAM`` sockets are supported. + +.. code-block:: C + + int sd = socket(AF_MCTP, SOCK_DGRAM, 0); + +The only (current) value for the ``protocol`` argument is 0. + +As with all socket address families, source and destination addresses are +specified with a ``sockaddr`` type, with a single-byte endpoint address: + +.. code-block:: C + + typedef __u8 mctp_eid_t; + + struct mctp_addr { + mctp_eid_t s_addr; + }; + + struct sockaddr_mctp { + unsigned short int smctp_family; + int smctp_network; + struct mctp_addr smctp_addr; + __u8 smctp_type; + __u8 smctp_tag; + }; + + #define MCTP_NET_ANY 0x0 + #define MCTP_ADDR_ANY 0xff + + +Syscall behaviour +----------------- + +The following sections describe the MCTP-specific behaviours of the standard +socket system calls. These behaviours have been chosen to map closely to the +existing sockets APIs. + +``bind()`` : set local socket address +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Sockets that receive incoming request packets will bind to a local address, +using the ``bind()`` syscall. + +.. code-block:: C + + struct sockaddr_mctp addr; + + addr.smctp_family = AF_MCTP; + addr.smctp_network = MCTP_NET_ANY; + addr.smctp_addr.s_addr = MCTP_ADDR_ANY; + addr.smctp_type = MCTP_TYPE_PLDM; + addr.smctp_tag = MCTP_TAG_OWNER; + + int rc = bind(sd, (struct sockaddr *)&addr, sizeof(addr)); + +This establishes the local address of the socket. Incoming MCTP messages that +match the network, address, and message type will be received by this socket. +The reference to 'incoming' is important here; a bound socket will only receive +messages with the TO bit set, to indicate an incoming request message, rather +than a response. + +The ``smctp_tag`` value will configure the tags accepted from the remote side of +this socket. Given the above, the only valid value is ``MCTP_TAG_OWNER``, which +will result in remotely "owned" tags being routed to this socket. Since +``MCTP_TAG_OWNER`` is set, the 3 least-significant bits of ``smctp_tag`` are not +used; callers must set them to zero. + +A ``smctp_network`` value of ``MCTP_NET_ANY`` will configure the socket to +receive incoming packets from any locally-connected network. A specific network +value will cause the socket to only receive incoming messages from that network. + +The ``smctp_addr`` field specifies a local address to bind to. A value of +``MCTP_ADDR_ANY`` configures the socket to receive messages addressed to any +local destination EID. + +The ``smctp_type`` field specifies which message types to receive. Only the +lower 7 bits of the type is matched on incoming messages (ie., the +most-significant IC bit is not part of the match). This results in the socket +receiving packets with and without a message integrity check footer. + +``sendto()``, ``sendmsg()``, ``send()`` : transmit an MCTP message +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +An MCTP message is transmitted using one of the ``sendto()``, ``sendmsg()`` or +``send()`` syscalls. Using ``sendto()`` as the primary example: + +.. code-block:: C + + struct sockaddr_mctp addr; + char buf[14]; + ssize_t len; + + /* set message destination */ + addr.smctp_family = AF_MCTP; + addr.smctp_network = 0; + addr.smctp_addr.s_addr = 8; + addr.smctp_tag = MCTP_TAG_OWNER; + addr.smctp_type = MCTP_TYPE_ECHO; + + /* arbitrary message to send, with message-type header */ + buf[0] = MCTP_TYPE_ECHO; + memcpy(buf + 1, "hello, world!", sizeof(buf) - 1); + + len = sendto(sd, buf, sizeof(buf), 0, + (struct sockaddr_mctp *)&addr, sizeof(addr)); + +The network and address fields of ``addr`` define the remote address to send to. +If ``smctp_tag`` has the ``MCTP_TAG_OWNER``, the kernel will ignore any bits set +in ``MCTP_TAG_VALUE``, and generate a tag value suitable for the destination +EID. If ``MCTP_TAG_OWNER`` is not set, the message will be sent with the tag +value as specified. If a tag value cannot be allocated, the system call will +report an errno of ``EAGAIN``. + +The application must provide the message type byte as the first byte of the +message buffer passed to ``sendto()``. If a message integrity check is to be +included in the transmitted message, it must also be provided in the message +buffer, and the most-significant bit of the message type byte must be 1. + +The ``sendmsg()`` system call allows a more compact argument interface, and the +message buffer to be specified as a scatter-gather list. At present no ancillary +message types (used for the ``msg_control`` data passed to ``sendmsg()``) are +defined. + +Transmitting a message on an unconnected socket with ``MCTP_TAG_OWNER`` +specified will cause an allocation of a tag, if no valid tag is already +allocated for that destination. The (destination-eid,tag) tuple acts as an +implicit local socket address, to allow the socket to receive responses to this +outgoing message. If any previous allocation has been performed (to for a +different remote EID), that allocation is lost. + +Sockets will only receive responses to requests they have sent (with TO=1) and +may only respond (with TO=0) to requests they have received. + +``recvfrom()``, ``recvmsg()``, ``recv()`` : receive an MCTP message +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +An MCTP message can be received by an application using one of the +``recvfrom()``, ``recvmsg()``, or ``recv()`` system calls. Using ``recvfrom()`` +as the primary example: + +.. code-block:: C + + struct sockaddr_mctp addr; + socklen_t addrlen; + char buf[14]; + ssize_t len; + + addrlen = sizeof(addr); + + len = recvfrom(sd, buf, sizeof(buf), 0, + (struct sockaddr_mctp *)&addr, &addrlen); + + /* We can expect addr to describe an MCTP address */ + assert(addrlen >= sizeof(buf)); + assert(addr.smctp_family == AF_MCTP); + + printf("received %zd bytes from remote EID %d\n", rc, addr.smctp_addr); + +The address argument to ``recvfrom`` and ``recvmsg`` is populated with the +remote address of the incoming message, including tag value (this will be needed +in order to reply to the message). + +The first byte of the message buffer will contain the message type byte. If an +integrity check follows the message, it will be included in the received buffer. + +The ``recv()`` system call behaves in a similar way, but does not provide a +remote address to the application. Therefore, these are only useful if the +remote address is already known, or the message does not require a reply. + +Like the send calls, sockets will only receive responses to requests they have +sent (TO=1) and may only respond (TO=0) to requests they have received. diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index 76d939e688b8..b0d4da71e68e 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -45,3 +45,15 @@ allow_join_initial_addr_port - BOOLEAN This is a per-namespace sysctl. Default: 1 + +stale_loss_cnt - INTEGER + The number of MPTCP-level retransmission intervals with no traffic and + pending outstanding data on a given subflow required to declare it stale. + The packet scheduler ignores stale subflows. + A low stale_loss_cnt value allows for fast active-backup switch-over, + an high value maximize links utilization on edge scenarios e.g. lossy + link with high BER or peer pausing the data processing. + + This is a per-namespace sysctl. + + Default: 4 diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index 91b2cf712801..e26532f49760 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -228,6 +228,23 @@ before posting to the mailing list. The patchwork build bot instance gets overloaded very easily and netdev@vger really doesn't need more traffic if we can help it. +netdevsim is great, can I extend it for my out-of-tree tests? +------------------------------------------------------------- + +No, `netdevsim` is a test vehicle solely for upstream tests. +(Please add your tests under tools/testing/selftests/.) + +We also give no guarantees that `netdevsim` won't change in the future +in a way which would break what would normally be considered uAPI. + +Is netdevsim considered a "user" of an API? +------------------------------------------- + +Linux kernel has a long standing rule that no API should be added unless +it has a real, in-tree user. Mock-ups and tests based on `netdevsim` are +strongly encouraged when adding new APIs, but `netdevsim` in itself +is **not** considered a use case/user. + Any other tips to help ensure my net/net-next patch gets OK'd? -------------------------------------------------------------- Attention to detail. Re-read your own work as if you were the diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index 17bdcb746dcf..9e4cccb90b87 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -222,6 +222,35 @@ ndo_do_ioctl: Synchronization: rtnl_lock() semaphore. Context: process + This is only called by network subsystems internally, + not by user space calling ioctl as it was in before + linux-5.14. + +ndo_siocbond: + Synchronization: rtnl_lock() semaphore. + Context: process + + Used by the bonding driver for the SIOCBOND family of + ioctl commands. + +ndo_siocwandev: + Synchronization: rtnl_lock() semaphore. + Context: process + + Used by the drivers/net/wan framework to handle + the SIOCWANDEV ioctl with the if_settings structure. + +ndo_siocdevprivate: + Synchronization: rtnl_lock() semaphore. + Context: process + + This is used to implement SIOCDEVPRIVATE ioctl helpers. + These should not be added to new drivers, so don't use. + +ndo_eth_ioctl: + Synchronization: rtnl_lock() semaphore. + Context: process + ndo_get_stats: Synchronization: rtnl_lock() semaphore, dev_base_lock rwlock, or RCU. Context: atomic (can't sleep under rwlock or RCU) diff --git a/Documentation/networking/nf_conntrack-sysctl.rst b/Documentation/networking/nf_conntrack-sysctl.rst index 0467b30e4abe..311128abb768 100644 --- a/Documentation/networking/nf_conntrack-sysctl.rst +++ b/Documentation/networking/nf_conntrack-sysctl.rst @@ -17,9 +17,8 @@ nf_conntrack_acct - BOOLEAN nf_conntrack_buckets - INTEGER Size of hash table. If not specified as parameter during module loading, the default size is calculated by dividing total memory - by 16384 to determine the number of buckets but the hash table will - never have fewer than 32 and limited to 16384 buckets. For systems - with more than 4GB of memory it will be 65536 buckets. + by 16384 to determine the number of buckets. The hash table will + never have fewer than 1024 and never more than 262144 buckets. This sysctl is only writeable in the initial net namespace. nf_conntrack_checksum - BOOLEAN @@ -100,8 +99,12 @@ nf_conntrack_log_invalid - INTEGER Log invalid packets of a type specified by value. nf_conntrack_max - INTEGER - Size of connection tracking table. Default value is - nf_conntrack_buckets value * 4. + Maximum number of allowed connection tracking entries. This value is set + to nf_conntrack_buckets by default. + Note that connection tracking entries are added to the table twice -- once + for the original direction and once for the reply direction (i.e., with + the reversed address). This means that with default settings a maxed-out + table will have a average hash chain length of 2, not 1. nf_conntrack_tcp_be_liberal - BOOLEAN - 0 - disabled (default) @@ -110,6 +113,12 @@ nf_conntrack_tcp_be_liberal - BOOLEAN Be conservative in what you do, be liberal in what you accept from others. If it's non-zero, we mark only out of window RST segments as INVALID. +nf_conntrack_tcp_ignore_invalid_rst - BOOLEAN + - 0 - disabled (default) + - 1 - enabled + + If it's 1, we don't mark out of window RST segments as INVALID. + nf_conntrack_tcp_loose - BOOLEAN - 0 - disabled - not 0 - enabled (default) @@ -178,6 +187,13 @@ nf_conntrack_gre_timeout_stream - INTEGER (seconds) This extended timeout will be used in case there is an GRE stream detected. +nf_hooks_lwtunnel - BOOLEAN + - 0 - disabled (default) + - not 0 - enabled + + If this option is enabled, the lightweight tunnel netfilter hooks are + enabled. This option cannot be disabled once it is enabled. + nf_flowtable_tcp_timeout - INTEGER (seconds) default 30 @@ -185,19 +201,9 @@ nf_flowtable_tcp_timeout - INTEGER (seconds) TCP connections may be offloaded from nf conntrack to nf flow table. Once aged, the connection is returned to nf conntrack with tcp pickup timeout. -nf_flowtable_tcp_pickup - INTEGER (seconds) - default 120 - - TCP connection timeout after being aged from nf flow table offload. - nf_flowtable_udp_timeout - INTEGER (seconds) default 30 Control offload timeout for udp connections. UDP connections may be offloaded from nf conntrack to nf flow table. Once aged, the connection is returned to nf conntrack with udp pickup timeout. - -nf_flowtable_udp_pickup - INTEGER (seconds) - default 30 - - UDP connection timeout after being aged from nf flow table offload. diff --git a/Documentation/networking/operstates.rst b/Documentation/networking/operstates.rst index 9c918f7cb0e8..1ee2141e8ef1 100644 --- a/Documentation/networking/operstates.rst +++ b/Documentation/networking/operstates.rst @@ -73,7 +73,9 @@ IF_OPER_LOWERLAYERDOWN (3): state (f.e. VLAN). IF_OPER_TESTING (4): - Unused in current kernel. + Interface is in testing mode, for example executing driver self-tests + or media (cable) test. It can't be used for normal traffic until tests + complete. IF_OPER_DORMANT (5): Interface is L1 up, but waiting for an external event, f.e. for a @@ -111,7 +113,7 @@ it as lower layer. Note that for certain kind of soft-devices, which are not managing any real hardware, it is possible to set this bit from userspace. One -should use TVL IFLA_CARRIER to do so. +should use TLV IFLA_CARRIER to do so. netif_carrier_ok() can be used to query that bit. diff --git a/Documentation/networking/pktgen.rst b/Documentation/networking/pktgen.rst index 7afa1c9f1183..1225f0f63ff0 100644 --- a/Documentation/networking/pktgen.rst +++ b/Documentation/networking/pktgen.rst @@ -248,26 +248,24 @@ Usage::: -i : ($DEV) output interface/device (required) -s : ($PKT_SIZE) packet size - -d : ($DEST_IP) destination IP + -d : ($DEST_IP) destination IP. CIDR (e.g. 198.18.0.0/15) is also allowed -m : ($DST_MAC) destination MAC-addr + -p : ($DST_PORT) destination PORT range (e.g. 433-444) is also allowed -t : ($THREADS) threads to start + -f : ($F_THREAD) index of first thread (zero indexed CPU number) -c : ($SKB_CLONE) SKB clones send before alloc new SKB + -n : ($COUNT) num messages to send per thread, 0 means indefinitely -b : ($BURST) HW level bursting of SKBs -v : ($VERBOSE) verbose -x : ($DEBUG) debug + -6 : ($IP6) IPv6 + -w : ($DELAY) Tx Delay value (ns) + -a : ($APPEND) Script will not reset generator's state, but will append its config The global variables being set are also listed. E.g. the required interface/device parameter "-i" sets variable $DEV. Copy the pktgen_sampleXX scripts and modify them to fit your own needs. -The old scripts:: - - pktgen.conf-1-2 # 1 CPU 2 dev - pktgen.conf-1-1-rdos # 1 CPU 1 dev w. route DoS - pktgen.conf-1-1-ip6 # 1 CPU 1 dev ipv6 - pktgen.conf-1-1-ip6-rdos # 1 CPU 1 dev ipv6 w. route DoS - pktgen.conf-1-1-flows # 1 CPU 1 dev multiple flows. - Interrupt affinity =================== @@ -398,7 +396,7 @@ Current commands and configuration options References: - ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/ -- tp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/ +- ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/ Paper from Linux-Kongress in Erlangen 2004. - ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/pktgen_paper.pdf diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index 7db3985359bc..a722eb30e014 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -625,7 +625,7 @@ interfaces of a DSA switch to share the same PHC. By design, PTP timestamping with a DSA switch does not need any special handling in the driver for the host port it is attached to. However, when the host port also supports PTP timestamping, DSA will take care of intercepting -the ``.ndo_do_ioctl`` calls towards the host port, and block attempts to enable +the ``.ndo_eth_ioctl`` calls towards the host port, and block attempts to enable hardware timestamping on it. This is because the SO_TIMESTAMPING API does not allow the delivery of multiple hardware timestamps for the same packet, so anybody else except for the DSA switch port must be prevented from doing so. @@ -688,7 +688,7 @@ ethtool ioctl operations for them need to be mediated by their respective MAC driver. Therefore, as opposed to DSA switches, modifications need to be done to each individual MAC driver for PHY timestamping support. This entails: -- Checking, in ``.ndo_do_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)`` +- Checking, in ``.ndo_eth_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)`` is true or not. If it is, then the MAC driver should not process this request but instead pass it on to the PHY using ``phy_mii_ioctl()``. @@ -747,7 +747,7 @@ For example, a typical driver design for TX timestamping might be to split the transmission part into 2 portions: 1. "TX": checks whether PTP timestamping has been previously enabled through - the ``.ndo_do_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the + the ``.ndo_eth_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the current skb requires a TX timestamp ("``skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP``"). If this is true, it sets the "``skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS``" flag. Note: as diff --git a/Documentation/networking/tipc.rst b/Documentation/networking/tipc.rst index 76775f24cdc8..ab63d298cca2 100644 --- a/Documentation/networking/tipc.rst +++ b/Documentation/networking/tipc.rst @@ -4,10 +4,125 @@ Linux Kernel TIPC ================= -TIPC (Transparent Inter Process Communication) is a protocol that is -specially designed for intra-cluster communication. +Introduction +============ -For more information about TIPC, see http://tipc.sourceforge.net. +TIPC (Transparent Inter Process Communication) is a protocol that is specially +designed for intra-cluster communication. It can be configured to transmit +messages either on UDP or directly across Ethernet. Message delivery is +sequence guaranteed, loss free and flow controlled. Latency times are shorter +than with any other known protocol, while maximal throughput is comparable to +that of TCP. + +TIPC Features +------------- + +- Cluster wide IPC service + + Have you ever wished you had the convenience of Unix Domain Sockets even when + transmitting data between cluster nodes? Where you yourself determine the + addresses you want to bind to and use? Where you don't have to perform DNS + lookups and worry about IP addresses? Where you don't have to start timers + to monitor the continuous existence of peer sockets? And yet without the + downsides of that socket type, such as the risk of lingering inodes? + + Welcome to the Transparent Inter Process Communication service, TIPC in short, + which gives you all of this, and a lot more. + +- Service Addressing + + A fundamental concept in TIPC is that of Service Addressing which makes it + possible for a programmer to chose his own address, bind it to a server + socket and let client programs use only that address for sending messages. + +- Service Tracking + + A client wanting to wait for the availability of a server, uses the Service + Tracking mechanism to subscribe for binding and unbinding/close events for + sockets with the associated service address. + + The service tracking mechanism can also be used for Cluster Topology Tracking, + i.e., subscribing for availability/non-availability of cluster nodes. + + Likewise, the service tracking mechanism can be used for Cluster Connectivity + Tracking, i.e., subscribing for up/down events for individual links between + cluster nodes. + +- Transmission Modes + + Using a service address, a client can send datagram messages to a server socket. + + Using the same address type, it can establish a connection towards an accepting + server socket. + + It can also use a service address to create and join a Communication Group, + which is the TIPC manifestation of a brokerless message bus. + + Multicast with very good performance and scalability is available both in + datagram mode and in communication group mode. + +- Inter Node Links + + Communication between any two nodes in a cluster is maintained by one or two + Inter Node Links, which both guarantee data traffic integrity and monitor + the peer node's availability. + +- Cluster Scalability + + By applying the Overlapping Ring Monitoring algorithm on the inter node links + it is possible to scale TIPC clusters up to 1000 nodes with a maintained + neighbor failure discovery time of 1-2 seconds. For smaller clusters this + time can be made much shorter. + +- Neighbor Discovery + + Neighbor Node Discovery in the cluster is done by Ethernet broadcast or UDP + multicast, when any of those services are available. If not, configured peer + IP addresses can be used. + +- Configuration + + When running TIPC in single node mode no configuration whatsoever is needed. + When running in cluster mode TIPC must as a minimum be given a node address + (before Linux 4.17) and told which interface to attach to. The "tipc" + configuration tool makes is possible to add and maintain many more + configuration parameters. + +- Performance + + TIPC message transfer latency times are better than in any other known protocol. + Maximal byte throughput for inter-node connections is still somewhat lower than + for TCP, while they are superior for intra-node and inter-container throughput + on the same host. + +- Language Support + + The TIPC user API has support for C, Python, Perl, Ruby, D and Go. + +More Information +---------------- + +- How to set up TIPC: + + http://tipc.io/getting_started.html + +- How to program with TIPC: + + http://tipc.io/programming.html + +- How to contribute to TIPC: + +- http://tipc.io/contacts.html + +- More details about TIPC specification: + + http://tipc.io/protocol.html + + +Implementation +============== + +TIPC is implemented as a kernel module in net/tipc/ directory. TIPC Base Types --------------- diff --git a/Documentation/networking/vrf.rst b/Documentation/networking/vrf.rst index 0dde145043bc..0a9a6f968cb9 100644 --- a/Documentation/networking/vrf.rst +++ b/Documentation/networking/vrf.rst @@ -144,6 +144,19 @@ default VRF are only handled by a socket not bound to any VRF:: netfilter rules on the VRF device can be used to limit access to services running in the default VRF context as well. +Using VRF-aware applications (applications which simultaneously create sockets +outside and inside VRFs) in conjunction with ``net.ipv4.tcp_l3mdev_accept=1`` +is possible but may lead to problems in some situations. With that sysctl +value, it is unspecified which listening socket will be selected to handle +connections for VRF traffic; ie. either a socket bound to the VRF or an unbound +socket may be used to accept new connections from a VRF. This somewhat +unexpected behavior can lead to problems if sockets are configured with extra +options (ex. TCP MD5 keys) with the expectation that VRF traffic will +exclusively be handled by sockets bound to VRFs, as would be the case with +``net.ipv4.tcp_l3mdev_accept=0``. Finally and as a reminder, regardless of +which listening socket is selected, established sockets will be created in the +VRF based on the ingress interface, as documented earlier. + -------------------------------------------------------------------------------- Using iproute2 for VRFs diff --git a/Documentation/powerpc/associativity.rst b/Documentation/powerpc/associativity.rst new file mode 100644 index 000000000000..4d01c7368561 --- /dev/null +++ b/Documentation/powerpc/associativity.rst @@ -0,0 +1,105 @@ +============================ +NUMA resource associativity +============================ + +Associativity represents the groupings of the various platform resources into +domains of substantially similar mean performance relative to resources outside +of that domain. Resources subsets of a given domain that exhibit better +performance relative to each other than relative to other resources subsets +are represented as being members of a sub-grouping domain. This performance +characteristic is presented in terms of NUMA node distance within the Linux kernel. +From the platform view, these groups are also referred to as domains. + +PAPR interface currently supports different ways of communicating these resource +grouping details to the OS. These are referred to as Form 0, Form 1 and Form2 +associativity grouping. Form 0 is the oldest format and is now considered deprecated. + +Hypervisor indicates the type/form of associativity used via "ibm,architecture-vec-5 property". +Bit 0 of byte 5 in the "ibm,architecture-vec-5" property indicates usage of Form 0 or Form 1. +A value of 1 indicates the usage of Form 1 associativity. For Form 2 associativity +bit 2 of byte 5 in the "ibm,architecture-vec-5" property is used. + +Form 0 +------ +Form 0 associativity supports only two NUMA distances (LOCAL and REMOTE). + +Form 1 +------ +With Form 1 a combination of ibm,associativity-reference-points, and ibm,associativity +device tree properties are used to determine the NUMA distance between resource groups/domains. + +The “ibm,associativity” property contains a list of one or more numbers (domainID) +representing the resource’s platform grouping domains. + +The “ibm,associativity-reference-points” property contains a list of one or more numbers +(domainID index) that represents the 1 based ordinal in the associativity lists. +The list of domainID indexes represents an increasing hierarchy of resource grouping. + +ex: +{ primary domainID index, secondary domainID index, tertiary domainID index.. } + +Linux kernel uses the domainID at the primary domainID index as the NUMA node id. +Linux kernel computes NUMA distance between two domains by recursively comparing +if they belong to the same higher-level domains. For mismatch at every higher +level of the resource group, the kernel doubles the NUMA distance between the +comparing domains. + +Form 2 +------- +Form 2 associativity format adds separate device tree properties representing NUMA node distance +thereby making the node distance computation flexible. Form 2 also allows flexible primary +domain numbering. With numa distance computation now detached from the index value in +"ibm,associativity-reference-points" property, Form 2 allows a large number of primary domain +ids at the same domainID index representing resource groups of different performance/latency +characteristics. + +Hypervisor indicates the usage of FORM2 associativity using bit 2 of byte 5 in the +"ibm,architecture-vec-5" property. + +"ibm,numa-lookup-index-table" property contains a list of one or more numbers representing +the domainIDs present in the system. The offset of the domainID in this property is +used as an index while computing numa distance information via "ibm,numa-distance-table". + +prop-encoded-array: The number N of the domainIDs encoded as with encode-int, followed by +N domainID encoded as with encode-int + +For ex: +"ibm,numa-lookup-index-table" = {4, 0, 8, 250, 252}. The offset of domainID 8 (2) is used when +computing the distance of domain 8 from other domains present in the system. For the rest of +this document, this offset will be referred to as domain distance offset. + +"ibm,numa-distance-table" property contains a list of one or more numbers representing the NUMA +distance between resource groups/domains present in the system. + +prop-encoded-array: The number N of the distance values encoded as with encode-int, followed by +N distance values encoded as with encode-bytes. The max distance value we could encode is 255. +The number N must be equal to the square of m where m is the number of domainIDs in the +numa-lookup-index-table. + +For ex: +ibm,numa-lookup-index-table = <3 0 8 40>; +ibm,numa-distace-table = <9>, /bits/ 8 < 10 20 80 20 10 160 80 160 10>; + +:: + + | 0 8 40 + --|------------ + | + 0 | 10 20 80 + | + 8 | 20 10 160 + | + 40| 80 160 10 + +A possible "ibm,associativity" property for resources in node 0, 8 and 40 + +{ 3, 6, 7, 0 } +{ 3, 6, 9, 8 } +{ 3, 6, 7, 40} + +With "ibm,associativity-reference-points" { 0x3 } + +"ibm,lookup-index-table" helps in having a compact representation of distance matrix. +Since domainID can be sparse, the matrix of distances can also be effectively sparse. +With "ibm,lookup-index-table" we can achieve a compact representation of +distance information. diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst index bf5f1a2bdbdf..0f7d3c495693 100644 --- a/Documentation/powerpc/index.rst +++ b/Documentation/powerpc/index.rst @@ -7,6 +7,7 @@ powerpc .. toctree:: :maxdepth: 1 + associativity booting bootwrapper cpu_families diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index b36af65a08ed..65f61695f561 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -1059,6 +1059,12 @@ The model name ``generic`` is treated as a special case. When this model is given, the driver uses the generic codec parser without "codec-patch". It's sometimes good for testing and debugging. +The model option can be used also for aliasing to another PCI or codec +SSID. When it's passed in the form of ``model=XXXX:YYYY`` where XXXX +and YYYY are the sub-vendor and sub-device IDs in hex numbers, +respectively, the driver will refer to that SSID as a reference to the +quirk table. + If the default configuration doesn't work and one of the above matches with your device, report it together with alsa-info.sh output (with ``--no-upload`` option) to kernel bugzilla or alsa-devel @@ -2252,6 +2258,27 @@ delayed_register The driver prints a message like "Found post-registration device assignment: 1234abcd:04" for such a device, so that user can notice the need. +quirk_flags + Contains the bit flags for various device specific workarounds. + Applied to the corresponding card index. + + * bit 0: Skip reading sample rate for devices + * bit 1: Create Media Controller API entries + * bit 2: Allow alignment on audio sub-slot at transfer + * bit 3: Add length specifier to transfers + * bit 4: Start playback stream at first in implement feedback mode + * bit 5: Skip clock selector setup + * bit 6: Ignore errors from clock source search + * bit 7: Indicates ITF-USB DSD based DACs + * bit 8: Add a delay of 20ms at each control message handling + * bit 9: Add a delay of 1-2ms at each control message handling + * bit 10: Add a delay of 5-6ms at each control message handling + * bit 11: Add a delay of 50ms at each interface setup + * bit 12: Perform sample rate validations at probe + * bit 13: Disable runtime PM autosuspend + * bit 14: Ignore errors for mixer access + * bit 15: Support generic DSD raw U32_BE format + * bit 16: Set up the interface at first like UAC1 This module supports multiple devices, autoprobe and hotplugging. @@ -2261,11 +2288,14 @@ check. NB: ``ignore_ctl_error=1`` may help when you get an error at accessing the mixer element such as URB error -22. This happens on some -buggy USB device or the controller. +buggy USB device or the controller. This workaround corresponds to +the ``quirk_flags`` bit 14, too. -NB: quirk_alias option is provided only for testing / development. +NB: ``quirk_alias`` option is provided only for testing / development. If you want to have a proper support, contact to upstream for adding the matching quirk in the driver code statically. +Ditto for ``quirk_flags``. If a device is known to require specific +workarounds, please report to the upstream. Module snd-usb-caiaq -------------------- diff --git a/Documentation/sound/hd-audio/notes.rst b/Documentation/sound/hd-audio/notes.rst index cf4d7158af78..d118b6fe269b 100644 --- a/Documentation/sound/hd-audio/notes.rst +++ b/Documentation/sound/hd-audio/notes.rst @@ -215,6 +215,17 @@ There are a few special model option values: * when ``generic`` is passed, the codec-specific parser is skipped and only the generic parser is used. +A new style for the model option that was introduced since 5.15 kernel +is to pass the PCI or codec SSID in the form of ``model=XXXX:YYYY`` +where XXXX and YYYY are the sub-vendor and sub-device IDs in hex +numbers, respectively. This is a kind of aliasing to another device; +when this form is given, the driver will refer to that SSID as a +reference to the quirk table. It'd be useful especially when the +target quirk isn't listed in the model table. For example, passing +model=103c:8862 will apply the quirk for HP ProBook 445 G8 (which +isn't found in the model table as of writing) as long as the device is +handled equivalently by the same driver. + Speaker and Headphone Output ---------------------------- diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index 6da9c887a48b..176b73583b7a 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -4172,6 +4172,39 @@ module license as GPL, etc., otherwise the system is shown as “tainted”. MODULE_LICENSE("GPL"); +Device-Managed Resources +======================== + +In the examples above, all resources are allocated and released +manually. But human beings are lazy in nature, especially developers +are lazier. So there are some ways to automate the release part; it's +the (device-)managed resources aka devres or devm family. For +example, an object allocated via :c:func:`devm_kmalloc()` will be +freed automatically at unbinding the device. + +ALSA core provides also the device-managed helper, namely, +:c:func:`snd_devm_card_new()` for creating a card object. +Call this functions instead of the normal :c:func:`snd_card_new()`, +and you can forget the explicit :c:func:`snd_card_free()` call, as +it's called automagically at error and removal paths. + +One caveat is that the call of :c:func:`snd_card_free()` would be put +at the beginning of the call chain only after you call +:c:func:`snd_card_register()`. + +Also, the ``private_free`` callback is always called at the card free, +so be careful to put the hardware clean-up procedure in +``private_free`` callback. It might be called even before you +actually set up at an earlier error path. For avoiding such an +invalid initialization, you can set ``private_free`` callback after +:c:func:`snd_card_register()` call succeeds. + +Another thing to be remarked is that you should use device-managed +helpers for each component as much as possible once when you manage +the card in that way. Mixing up with the normal and the managed +resources may screw up the release order. + + How To Put Your Driver Into ALSA Tree ===================================== diff --git a/Documentation/trace/boottime-trace.rst b/Documentation/trace/boottime-trace.rst index 8053898cfeb4..6dcfbc64014d 100644 --- a/Documentation/trace/boottime-trace.rst +++ b/Documentation/trace/boottime-trace.rst @@ -125,6 +125,71 @@ Note that kprobe and synthetic event definitions can be written under instance node, but those are also visible from other instances. So please take care for event name conflict. +Ftrace Histogram Options +------------------------ + +Since it is too long to write a histogram action as a string for per-event +action option, there are tree-style options under per-event 'hist' subkey +for the histogram actions. For the detail of the each parameter, +please read the event histogram document [3]_. + +.. [3] See :ref:`Documentation/trace/histogram.rst <histogram>` + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]keys = KEY1[, KEY2[...]] + Set histogram key parameters. (Mandatory) + The 'N' is a digit string for the multiple histogram. You can omit it + if there is one histogram on the event. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]values = VAL1[, VAL2[...]] + Set histogram value parameters. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]sort = SORT1[, SORT2[...]] + Set histogram sort parameter options. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]size = NR_ENTRIES + Set histogram size (number of entries). + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]name = NAME + Set histogram name. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]var.VARIABLE = EXPR + Define a new VARIABLE by EXPR expression. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]<pause|continue|clear> + Set histogram control parameter. You can set one of them. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]onmatch.[M.]event = GROUP.EVENT + Set histogram 'onmatch' handler matching event parameter. + The 'M' is a digit string for the multiple 'onmatch' handler. You can omit it + if there is one 'onmatch' handler on this histogram. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]onmatch.[M.]trace = EVENT[, ARG1[...]] + Set histogram 'trace' action for 'onmatch'. + EVENT must be a synthetic event name, and ARG1... are parameters + for that event. Mandatory if 'onmatch.event' option is set. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]onmax.[M.]var = VAR + Set histogram 'onmax' handler variable parameter. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]onchange.[M.]var = VAR + Set histogram 'onchange' handler variable parameter. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]<onmax|onchange>.[M.]save = ARG1[, ARG2[...]] + Set histogram 'save' action parameters for 'onmax' or 'onchange' handler. + This option or below 'snapshot' option is mandatory if 'onmax.var' or + 'onchange.var' option is set. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]<onmax|onchange>.[M.]snapshot + Set histogram 'snapshot' action for 'onmax' or 'onchange' handler. + This option or above 'save' option is mandatory if 'onmax.var' or + 'onchange.var' option is set. + +ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.filter = FILTER_EXPR + Set histogram filter expression. You don't need 'if' in the FILTER_EXPR. + +Note that this 'hist' option can conflict with the per-event 'actions' +option if the 'actions' option has a histogram action. + When to Start ============= @@ -159,13 +224,23 @@ below:: } synthetic.initcall_latency { fields = "unsigned long func", "u64 lat" - actions = "hist:keys=func.sym,lat:vals=lat:sort=lat" + hist { + keys = func.sym, lat + values = lat + sort = lat + } } - initcall.initcall_start { - actions = "hist:keys=func:ts0=common_timestamp.usecs" + initcall.initcall_start.hist { + keys = func + var.ts0 = common_timestamp.usecs } - initcall.initcall_finish { - actions = "hist:keys=func:lat=common_timestamp.usecs-$ts0:onmatch(initcall.initcall_start).initcall_latency(func,$lat)" + initcall.initcall_finish.hist { + keys = func + var.lat = common_timestamp.usecs - $ts0 + onmatch { + event = initcall.initcall_start + trace = initcall_latency, func, $lat + } } } diff --git a/Documentation/trace/coresight/coresight-config.rst b/Documentation/trace/coresight/coresight-config.rst new file mode 100644 index 000000000000..a4e3ef295240 --- /dev/null +++ b/Documentation/trace/coresight/coresight-config.rst @@ -0,0 +1,244 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +CoreSight System Configuration Manager +====================================== + + :Author: Mike Leach <mike.leach@linaro.org> + :Date: October 2020 + +Introduction +============ + +The CoreSight System Configuration manager is an API that allows the +programming of the CoreSight system with pre-defined configurations that +can then be easily enabled from sysfs or perf. + +Many CoreSight components can be programmed in complex ways - especially ETMs. +In addition, components can interact across the CoreSight system, often via +the cross trigger components such as CTI and CTM. These system settings can +be defined and enabled as named configurations. + + +Basic Concepts +============== + +This section introduces the basic concepts of a CoreSight system configuration. + + +Features +-------- + +A feature is a named set of programming for a CoreSight device. The programming +is device dependent, and can be defined in terms of absolute register values, +resource usage and parameter values. + +The feature is defined using a descriptor. This descriptor is used to load onto +a matching device, either when the feature is loaded into the system, or when the +CoreSight device is registered with the configuration manager. + +The load process involves interpreting the descriptor into a set of register +accesses in the driver - the resource usage and parameter descriptions +translated into appropriate register accesses. This interpretation makes it easy +and efficient for the feature to be programmed onto the device when required. + +The feature will not be active on the device until the feature is enabled, and +the device itself is enabled. When the device is enabled then enabled features +will be programmed into the device hardware. + +A feature is enabled as part of a configuration being enabled on the system. + + +Parameter Value +~~~~~~~~~~~~~~~ + +A parameter value is a named value that may be set by the user prior to the +feature being enabled that can adjust the behaviour of the operation programmed +by the feature. + +For example, this could be a count value in a programmed operation that repeats +at a given rate. When the feature is enabled then the current value of the +parameter is used in programming the device. + +The feature descriptor defines a default value for a parameter, which is used +if the user does not supply a new value. + +Users can update parameter values using the configfs API for the CoreSight +system - which is described below. + +The current value of the parameter is loaded into the device when the feature +is enabled on that device. + + +Configurations +-------------- + +A configuration defines a set of features that are to be used in a trace +session where the configuration is selected. For any trace session only one +configuration may be selected. + +The features defined may be on any type of device that is registered +to support system configuration. A configuration may select features to be +enabled on a class of devices - i.e. any ETMv4, or specific devices, e.g. a +specific CTI on the system. + +As with the feature, a descriptor is used to define the configuration. +This will define the features that must be enabled as part of the configuration +as well as any preset values that can be used to override default parameter +values. + + +Preset Values +~~~~~~~~~~~~~ + +Preset values are easily selectable sets of parameter values for the features +that the configuration uses. The number of values in a single preset set, equals +the sum of parameter values in the features used by the configuration. + +e.g. a configuration consists of 3 features, one has 2 parameters, one has +a single parameter, and another has no parameters. A single preset set will +therefore have 3 values. + +Presets are optionally defined by the configuration, up to 15 can be defined. +If no preset is selected, then the parameter values defined in the feature +are used as normal. + + +Operation +~~~~~~~~~ + +The following steps take place in the operation of a configuration. + +1) In this example, the configuration is 'autofdo', which has an + associated feature 'strobing' that works on ETMv4 CoreSight Devices. + +2) The configuration is enabled. For example 'perf' may select the + configuration as part of its command line:: + + perf record -e cs_etm/autofdo/ myapp + + which will enable the 'autofdo' configuration. + +3) perf starts tracing on the system. As each ETMv4 that perf uses for + trace is enabled, the configuration manager will check if the ETMv4 + has a feature that relates to the currently active configuration. + In this case 'strobing' is enabled & programmed into the ETMv4. + +4) When the ETMv4 is disabled, any registers marked as needing to be + saved will be read back. + +5) At the end of the perf session, the configuration will be disabled. + + +Viewing Configurations and Features +=================================== + +The set of configurations and features that are currently loaded into the +system can be viewed using the configfs API. + +Mount configfs as normal and the 'cs-syscfg' subsystem will appear:: + + $ ls /config + cs-syscfg stp-policy + +This has two sub-directories:: + + $ cd cs-syscfg/ + $ ls + configurations features + +The system has the configuration 'autofdo' built in. It may be examined as +follows:: + + $ cd configurations/ + $ ls + autofdo + $ cd autofdo/ + $ ls + description preset1 preset3 preset5 preset7 preset9 + feature_refs preset2 preset4 preset6 preset8 + $ cat description + Setup ETMs with strobing for autofdo + $ cat feature_refs + strobing + +Each preset declared has a preset<n> subdirectory declared. The values for +the preset can be examined:: + + $ cat preset1/values + strobing.window = 0x1388 strobing.period = 0x2 + $ cat preset2/values + strobing.window = 0x1388 strobing.period = 0x4 + +The features referenced by the configuration can be examined in the features +directory:: + + $ cd ../../features/strobing/ + $ ls + description matches nr_params params + $ cat description + Generate periodic trace capture windows. + parameter 'window': a number of CPU cycles (W) + parameter 'period': trace enabled for W cycles every period x W cycles + $ cat matches + SRC_ETMV4 + $ cat nr_params + 2 + +Move to the params directory to examine and adjust parameters:: + + cd params + $ ls + period window + $ cd period + $ ls + value + $ cat value + 0x2710 + # echo 15000 > value + # cat value + 0x3a98 + +Parameters adjusted in this way are reflected in all device instances that have +loaded the feature. + + +Using Configurations in perf +============================ + +The configurations loaded into the CoreSight configuration management are +also declared in the perf 'cs_etm' event infrastructure so that they can +be selected when running trace under perf:: + + $ ls /sys/devices/cs_etm + configurations format perf_event_mux_interval_ms sinks type + events nr_addr_filters power + +Key directories here are 'configurations' - which lists the loaded +configurations, and 'events' - a generic perf directory which allows +selection on the perf command line.:: + + $ ls configurations/ + autofdo + $ cat configurations/autofdo + 0xa7c3dddd + +As with the sinks entries, this provides a hash of the configuration name. +The entry in the 'events' directory uses perfs built in syntax generator +to substitute the syntax for the name when evaluating the command:: + + $ ls events/ + autofdo + $ cat events/autofdo + configid=0xa7c3dddd + +The 'autofdo' configuration may be selected on the perf command line:: + + $ perf record -e cs_etm/autofdo/u --per-thread <application> + +A preset to override the current parameter values can also be selected:: + + $ perf record -e cs_etm/autofdo,preset=1/u --per-thread <application> + +When configurations are selected in this way, then the trace sink used is +automatically selected. diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst index 1ec8dc35b1d8..a15571d96cc8 100644 --- a/Documentation/trace/coresight/coresight.rst +++ b/Documentation/trace/coresight/coresight.rst @@ -620,6 +620,19 @@ channels on the CTM (Cross Trigger Matrix). A separate documentation file is provided to explain the use of these devices. (Documentation/trace/coresight/coresight-ect.rst) [#fourth]_. +CoreSight System Configuration +------------------------------ + +CoreSight components can be complex devices with many programming options. +Furthermore, components can be programmed to interact with each other across the +complete system. + +A CoreSight System Configuration manager is provided to allow these complex programming +configurations to be selected and used easily from perf and sysfs. + +See the separate document for further information. +(Documentation/trace/coresight/coresight-config.rst) [#fifth]_. + .. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm @@ -628,3 +641,5 @@ A separate documentation file is provided to explain the use of these devices. .. [#third] https://github.com/Linaro/perf-opencsd .. [#fourth] Documentation/trace/coresight/coresight-ect.rst + +.. [#fifth] Documentation/trace/coresight/coresight-config.rst diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index cfc81e98e0b8..4e5b26f03d5b 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -2762,7 +2762,7 @@ listed in: put_prev_task_idle kmem_cache_create pick_next_task_rt - get_online_cpus + cpus_read_lock pick_next_task_fair mutex_lock [...] diff --git a/Documentation/trace/histogram.rst b/Documentation/trace/histogram.rst index b71e09f745c3..533415644c54 100644 --- a/Documentation/trace/histogram.rst +++ b/Documentation/trace/histogram.rst @@ -70,15 +70,16 @@ Documentation written by Tom Zanussi modified by appending any of the following modifiers to the field name: - =========== ========================================== - .hex display a number as a hex value - .sym display an address as a symbol - .sym-offset display an address as a symbol and offset - .syscall display a syscall id as a system call name - .execname display a common_pid as a program name - .log2 display log2 value rather than raw number - .usecs display a common_timestamp in microseconds - =========== ========================================== + ============= ================================================= + .hex display a number as a hex value + .sym display an address as a symbol + .sym-offset display an address as a symbol and offset + .syscall display a syscall id as a system call name + .execname display a common_pid as a program name + .log2 display log2 value rather than raw number + .buckets=size display grouping of values rather than raw number + .usecs display a common_timestamp in microseconds + ============= ================================================= Note that in general the semantics of a given field aren't interpreted when applying a modifier to it, but there are some @@ -191,7 +192,7 @@ Documentation written by Tom Zanussi with the event, in nanoseconds. May be modified by .usecs to have timestamps interpreted as microseconds. - cpu int the cpu on which the event occurred. + common_cpu int the cpu on which the event occurred. ====================== ==== ======================================= Extended error information @@ -228,7 +229,7 @@ Extended error information that lists the total number of bytes requested for each function in the kernel that made one or more calls to kmalloc:: - # echo 'hist:key=call_site:val=bytes_req' > \ + # echo 'hist:key=call_site:val=bytes_req.buckets=32' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger This tells the tracing system to create a 'hist' trigger using the @@ -1823,20 +1824,99 @@ and variables defined on other events (see Section 2.2.3 below on how that is done using hist trigger 'onmatch' action). Once that is done, the 'wakeup_latency' synthetic event instance is created. -A histogram can now be defined for the new synthetic event:: - - # echo 'hist:keys=pid,prio,lat.log2:sort=pid,lat' >> \ - /sys/kernel/debug/tracing/events/synthetic/wakeup_latency/trigger - The new event is created under the tracing/events/synthetic/ directory and looks and behaves just like any other event:: # ls /sys/kernel/debug/tracing/events/synthetic/wakeup_latency enable filter format hist id trigger +A histogram can now be defined for the new synthetic event:: + + # echo 'hist:keys=pid,prio,lat.log2:sort=lat' >> \ + /sys/kernel/debug/tracing/events/synthetic/wakeup_latency/trigger + +The above shows the latency "lat" in a power of 2 grouping. + Like any other event, once a histogram is enabled for the event, the output can be displayed by reading the event's 'hist' file. + # cat /sys/kernel/debug/tracing/events/synthetic/wakeup_latency/hist + + # event histogram + # + # trigger info: hist:keys=pid,prio,lat.log2:vals=hitcount:sort=lat.log2:size=2048 [active] + # + + { pid: 2035, prio: 9, lat: ~ 2^2 } hitcount: 43 + { pid: 2034, prio: 9, lat: ~ 2^2 } hitcount: 60 + { pid: 2029, prio: 9, lat: ~ 2^2 } hitcount: 965 + { pid: 2034, prio: 120, lat: ~ 2^2 } hitcount: 9 + { pid: 2033, prio: 120, lat: ~ 2^2 } hitcount: 5 + { pid: 2030, prio: 9, lat: ~ 2^2 } hitcount: 335 + { pid: 2030, prio: 120, lat: ~ 2^2 } hitcount: 10 + { pid: 2032, prio: 120, lat: ~ 2^2 } hitcount: 1 + { pid: 2035, prio: 120, lat: ~ 2^2 } hitcount: 2 + { pid: 2031, prio: 9, lat: ~ 2^2 } hitcount: 176 + { pid: 2028, prio: 120, lat: ~ 2^2 } hitcount: 15 + { pid: 2033, prio: 9, lat: ~ 2^2 } hitcount: 91 + { pid: 2032, prio: 9, lat: ~ 2^2 } hitcount: 125 + { pid: 2029, prio: 120, lat: ~ 2^2 } hitcount: 4 + { pid: 2031, prio: 120, lat: ~ 2^2 } hitcount: 3 + { pid: 2029, prio: 120, lat: ~ 2^3 } hitcount: 2 + { pid: 2035, prio: 9, lat: ~ 2^3 } hitcount: 41 + { pid: 2030, prio: 120, lat: ~ 2^3 } hitcount: 1 + { pid: 2032, prio: 9, lat: ~ 2^3 } hitcount: 32 + { pid: 2031, prio: 9, lat: ~ 2^3 } hitcount: 44 + { pid: 2034, prio: 9, lat: ~ 2^3 } hitcount: 40 + { pid: 2030, prio: 9, lat: ~ 2^3 } hitcount: 29 + { pid: 2033, prio: 9, lat: ~ 2^3 } hitcount: 31 + { pid: 2029, prio: 9, lat: ~ 2^3 } hitcount: 31 + { pid: 2028, prio: 120, lat: ~ 2^3 } hitcount: 18 + { pid: 2031, prio: 120, lat: ~ 2^3 } hitcount: 2 + { pid: 2028, prio: 120, lat: ~ 2^4 } hitcount: 1 + { pid: 2029, prio: 9, lat: ~ 2^4 } hitcount: 4 + { pid: 2031, prio: 120, lat: ~ 2^7 } hitcount: 1 + { pid: 2032, prio: 120, lat: ~ 2^7 } hitcount: 1 + + Totals: + Hits: 2122 + Entries: 30 + Dropped: 0 + + +The latency values can also be grouped linearly by a given size with +the ".buckets" modifier and specify a size (in this case groups of 10). + + # echo 'hist:keys=pid,prio,lat.buckets=10:sort=lat' >> \ + /sys/kernel/debug/tracing/events/synthetic/wakeup_latency/trigger + + # event histogram + # + # trigger info: hist:keys=pid,prio,lat.buckets=10:vals=hitcount:sort=lat.buckets=10:size=2048 [active] + # + + { pid: 2067, prio: 9, lat: ~ 0-9 } hitcount: 220 + { pid: 2068, prio: 9, lat: ~ 0-9 } hitcount: 157 + { pid: 2070, prio: 9, lat: ~ 0-9 } hitcount: 100 + { pid: 2067, prio: 120, lat: ~ 0-9 } hitcount: 6 + { pid: 2065, prio: 120, lat: ~ 0-9 } hitcount: 2 + { pid: 2066, prio: 120, lat: ~ 0-9 } hitcount: 2 + { pid: 2069, prio: 9, lat: ~ 0-9 } hitcount: 122 + { pid: 2069, prio: 120, lat: ~ 0-9 } hitcount: 8 + { pid: 2070, prio: 120, lat: ~ 0-9 } hitcount: 1 + { pid: 2068, prio: 120, lat: ~ 0-9 } hitcount: 7 + { pid: 2066, prio: 9, lat: ~ 0-9 } hitcount: 365 + { pid: 2064, prio: 120, lat: ~ 0-9 } hitcount: 35 + { pid: 2065, prio: 9, lat: ~ 0-9 } hitcount: 998 + { pid: 2071, prio: 9, lat: ~ 0-9 } hitcount: 85 + { pid: 2065, prio: 9, lat: ~ 10-19 } hitcount: 2 + { pid: 2064, prio: 120, lat: ~ 10-19 } hitcount: 2 + + Totals: + Hits: 2112 + Entries: 16 + Dropped: 0 + 2.2.3 Hist trigger 'handlers' and 'actions' ------------------------------------------- diff --git a/Documentation/translations/zh_CN/core-api/cachetlb.rst b/Documentation/translations/zh_CN/core-api/cachetlb.rst index b5bb13a707cd..6fee45fe5e80 100644 --- a/Documentation/translations/zh_CN/core-api/cachetlb.rst +++ b/Documentation/translations/zh_CN/core-api/cachetlb.rst @@ -298,15 +298,6 @@ HyperSparc cpu就是这样一个具有这种属性的cpu。 用。默认的实现是nop（对于所有相干的架构应该保持这样）。对于不一致性 的架构，它应该刷新vmaddr处的页面缓存。 - ``void flush_kernel_dcache_page(struct page *page)`` - - 当内核需要修改一个用kmap获得的用户页时，它会在所有修改完成后（但在 - kunmapping之前）调用这个函数，以使底层页面达到最新状态。这里假定用 - 户没有不一致性的缓存副本（即原始页面是从类似get_user_pages()的机制 - 中获得的）。默认的实现是一个nop，在所有相干的架构上都应该如此。在不 - 一致性的架构上，这应该刷新内核缓存中的页面（使用page_address(page)）。 - - ``void flush_icache_range(unsigned long start, unsigned long end)`` 当内核存储到它将执行的地址中时（例如在加载模块时），这个函数被调用。 diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 9d6276f82774..c18113077889 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -724,18 +724,28 @@ Function-specific configfs interface The function name to use when creating the function directory is "uac2". The uac2 function provides these attributes in its function directory: - =============== ==================================================== - c_chmask capture channel mask - c_srate capture sampling rate - c_ssize capture sample size (bytes) - c_sync capture synchronization type (async/adaptive) - fb_max maximum extra bandwidth in async mode - p_chmask playback channel mask - p_srate playback sampling rate - p_ssize playback sample size (bytes) - req_number the number of pre-allocated request for both capture - and playback - =============== ==================================================== + ================ ==================================================== + c_chmask capture channel mask + c_srate capture sampling rate + c_ssize capture sample size (bytes) + c_sync capture synchronization type (async/adaptive) + c_mute_present capture mute control enable + c_volume_present capture volume control enable + c_volume_min capture volume control min value (in 1/256 dB) + c_volume_max capture volume control max value (in 1/256 dB) + c_volume_res capture volume control resolution (in 1/256 dB) + fb_max maximum extra bandwidth in async mode + p_chmask playback channel mask + p_srate playback sampling rate + p_ssize playback sample size (bytes) + p_mute_present playback mute control enable + p_volume_present playback volume control enable + p_volume_min playback volume control min value (in 1/256 dB) + p_volume_max playback volume control max value (in 1/256 dB) + p_volume_res playback volume control resolution (in 1/256 dB) + req_number the number of pre-allocated request for both capture + and playback + ================ ==================================================== The attributes have sane default values. @@ -904,16 +914,26 @@ Function-specific configfs interface The function name to use when creating the function directory is "uac1". The uac1 function provides these attributes in its function directory: - ========== ==================================================== - c_chmask capture channel mask - c_srate capture sampling rate - c_ssize capture sample size (bytes) - p_chmask playback channel mask - p_srate playback sampling rate - p_ssize playback sample size (bytes) - req_number the number of pre-allocated request for both capture - and playback - ========== ==================================================== + ================ ==================================================== + c_chmask capture channel mask + c_srate capture sampling rate + c_ssize capture sample size (bytes) + c_mute_present capture mute control enable + c_volume_present capture volume control enable + c_volume_min capture volume control min value (in 1/256 dB) + c_volume_max capture volume control max value (in 1/256 dB) + c_volume_res capture volume control resolution (in 1/256 dB) + p_chmask playback channel mask + p_srate playback sampling rate + p_ssize playback sample size (bytes) + p_mute_present playback mute control enable + p_volume_present playback volume control enable + p_volume_min playback volume control min value (in 1/256 dB) + p_volume_max playback volume control max value (in 1/256 dB) + p_volume_res playback volume control resolution (in 1/256 dB) + req_number the number of pre-allocated request for both capture + and playback + ================ ==================================================== The attributes have sane default values. diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 1409e40e6345..b7070d76f076 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -160,7 +160,6 @@ Code Seq# Include File Comments 'K' all linux/kd.h 'L' 00-1F linux/loop.h conflict! 'L' 10-1F drivers/scsi/mpt3sas/mpt3sas_ctl.h conflict! -'L' 20-2F linux/lightnvm.h 'L' E0-FF linux/ppdd.h encrypted disk device driver <http://linux01.gwdg.de/~alatham/ppdd.html> 'M' all linux/soundcard.h conflict! diff --git a/Documentation/userspace-api/media/cec.h.rst.exceptions b/Documentation/userspace-api/media/cec.h.rst.exceptions index d83790ccac8e..13de01d9555e 100644 --- a/Documentation/userspace-api/media/cec.h.rst.exceptions +++ b/Documentation/userspace-api/media/cec.h.rst.exceptions @@ -140,7 +140,7 @@ ignore define CEC_OP_REC_SEQ_TUESDAY ignore define CEC_OP_REC_SEQ_WEDNESDAY ignore define CEC_OP_REC_SEQ_THURSDAY ignore define CEC_OP_REC_SEQ_FRIDAY -ignore define CEC_OP_REC_SEQ_SATERDAY +ignore define CEC_OP_REC_SEQ_SATURDAY ignore define CEC_OP_REC_SEQ_ONCE_ONLY ignore define CEC_MSG_CLEAR_DIGITAL_TIMER diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index 8c6e2a11ed95..976d34445a24 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1174,7 +1174,24 @@ enum v4l2_mpeg_video_h264_entropy_mode - Cyclic intra macroblock refresh. This is the number of continuous macroblocks refreshed every frame. Each frame a successive set of macroblocks is refreshed until the cycle completes and starts from - the top of the frame. Applicable to H264, H263 and MPEG4 encoder. + the top of the frame. Setting this control to zero means that + macroblocks will not be refreshed. Note that this control will not + take effect when ``V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD`` control + is set to non zero value. + Applicable to H264, H263 and MPEG4 encoder. + +``V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD (integer)`` + Intra macroblock refresh period. This sets the period to refresh + the whole frame. In other words, this defines the number of frames + for which the whole frame will be intra-refreshed. An example: + setting period to 1 means that the whole frame will be refreshed, + setting period to 2 means that the half of macroblocks will be + intra-refreshed on frameX and the other half of macroblocks + will be refreshed in frameX + 1 and so on. Setting the period to + zero means no period is specified. + Note that if the client sets this control to non zero value the + ``V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB`` control shall be + ignored. Applicable to H264 and HEVC encoders. ``V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE (boolean)`` Frame level rate control enable. If this control is disabled then @@ -3000,6 +3017,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - __u8 - ``pic_struct`` - + * - __u32 + - ``slice_segment_addr`` + - * - __u8 - ``ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - The list of L0 reference elements as indices in the DPB. diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst index 87698c15c027..b1c2ab2854af 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst @@ -20,25 +20,26 @@ Image Process Control IDs ``V4L2_CID_IMAGE_PROC_CLASS (class)`` The IMAGE_PROC class descriptor. +.. _v4l2-cid-link-freq: + ``V4L2_CID_LINK_FREQ (integer menu)`` - Data bus frequency. Together with the media bus pixel code, bus type - (clock cycles per sample), the data bus frequency defines the pixel - rate (``V4L2_CID_PIXEL_RATE``) in the pixel array (or possibly - elsewhere, if the device is not an image sensor). The frame rate can - be calculated from the pixel clock, image width and height and - horizontal and vertical blanking. While the pixel rate control may - be defined elsewhere than in the subdev containing the pixel array, - the frame rate cannot be obtained from that information. This is - because only on the pixel array it can be assumed that the vertical - and horizontal blanking information is exact: no other blanking is - allowed in the pixel array. The selection of frame rate is performed - by selecting the desired horizontal and vertical blanking. The unit - of this control is Hz. + The frequency of the data bus (e.g. parallel or CSI-2). + +.. _v4l2-cid-pixel-rate: ``V4L2_CID_PIXEL_RATE (64-bit integer)`` - Pixel rate in the source pads of the subdev. This control is + Pixel sampling rate in the device's pixel array. This control is read-only and its unit is pixels / second. + Some devices use horizontal and vertical balanking to configure the frame + rate. The frame rate can be calculated from the pixel rate, analogue crop + rectangle as well as horizontal and vertical blanking. The pixel rate + control may be present in a different sub-device than the blanking controls + and the analogue crop rectangle configuration. + + The configuration of the frame rate is performed by selecting the desired + horizontal and vertical blanking. The unit of this control is Hz. + ``V4L2_CID_TEST_PATTERN (menu)`` Some capture/display/sensor devices have the capability to generate test pattern images. These hardware specific test patterns can be diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst index d61219889e49..539e9d4a4860 100644 --- a/Documentation/userspace-api/seccomp_filter.rst +++ b/Documentation/userspace-api/seccomp_filter.rst @@ -263,7 +263,7 @@ Userspace can also add file descriptors to the notifying process via ``ioctl(SECCOMP_IOCTL_NOTIF_ADDFD)``. The ``id`` member of ``struct seccomp_notif_addfd`` should be the same ``id`` as in ``struct seccomp_notif``. The ``newfd_flags`` flag may be used to set flags -like O_EXEC on the file descriptor in the notifying process. If the supervisor +like O_CLOEXEC on the file descriptor in the notifying process. If the supervisor wants to inject the file descriptor with a specific number, the ``SECCOMP_ADDFD_FLAG_SETFD`` flag can be used, and set the ``newfd`` member to the specific number to use. If that file descriptor is already open in the diff --git a/Documentation/userspace-api/spec_ctrl.rst b/Documentation/userspace-api/spec_ctrl.rst index 7ddd8f667459..5e8ed9eef9aa 100644 --- a/Documentation/userspace-api/spec_ctrl.rst +++ b/Documentation/userspace-api/spec_ctrl.rst @@ -106,3 +106,11 @@ Speculation misfeature controls * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0); * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0); * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0); + +- PR_SPEC_L1D_FLUSH: Flush L1D Cache on context switch out of the task + (works only when tasks run on non SMT cores) + + Invocations: + * prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, 0, 0, 0); + * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_ENABLE, 0, 0); + * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_DISABLE, 0, 0); diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 7152268c580d..a6729c8cf063 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -3357,6 +3357,7 @@ flags which can include the following: - KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86] - KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86] - KVM_GUESTDBG_EXIT_PENDING: trigger an immediate guest exit [s390] + - KVM_GUESTDBG_BLOCKIRQ: avoid injecting interrupts/NMI/SMI [x86] For example KVM_GUESTDBG_USE_SW_BP indicates that software breakpoints are enabled in memory so we need to ensure breakpoint exceptions are @@ -5208,6 +5209,9 @@ by a string of size ``name_size``. #define KVM_STATS_TYPE_CUMULATIVE (0x0 << KVM_STATS_TYPE_SHIFT) #define KVM_STATS_TYPE_INSTANT (0x1 << KVM_STATS_TYPE_SHIFT) #define KVM_STATS_TYPE_PEAK (0x2 << KVM_STATS_TYPE_SHIFT) + #define KVM_STATS_TYPE_LINEAR_HIST (0x3 << KVM_STATS_TYPE_SHIFT) + #define KVM_STATS_TYPE_LOG_HIST (0x4 << KVM_STATS_TYPE_SHIFT) + #define KVM_STATS_TYPE_MAX KVM_STATS_TYPE_LOG_HIST #define KVM_STATS_UNIT_SHIFT 4 #define KVM_STATS_UNIT_MASK (0xF << KVM_STATS_UNIT_SHIFT) @@ -5215,18 +5219,20 @@ by a string of size ``name_size``. #define KVM_STATS_UNIT_BYTES (0x1 << KVM_STATS_UNIT_SHIFT) #define KVM_STATS_UNIT_SECONDS (0x2 << KVM_STATS_UNIT_SHIFT) #define KVM_STATS_UNIT_CYCLES (0x3 << KVM_STATS_UNIT_SHIFT) + #define KVM_STATS_UNIT_MAX KVM_STATS_UNIT_CYCLES #define KVM_STATS_BASE_SHIFT 8 #define KVM_STATS_BASE_MASK (0xF << KVM_STATS_BASE_SHIFT) #define KVM_STATS_BASE_POW10 (0x0 << KVM_STATS_BASE_SHIFT) #define KVM_STATS_BASE_POW2 (0x1 << KVM_STATS_BASE_SHIFT) + #define KVM_STATS_BASE_MAX KVM_STATS_BASE_POW2 struct kvm_stats_desc { __u32 flags; __s16 exponent; __u16 size; __u32 offset; - __u32 unused; + __u32 bucket_size; char name[]; }; @@ -5237,21 +5243,35 @@ The following flags are supported: Bits 0-3 of ``flags`` encode the type: * ``KVM_STATS_TYPE_CUMULATIVE`` - The statistics data is cumulative. The value of data can only be increased. + The statistics reports a cumulative count. The value of data can only be increased. Most of the counters used in KVM are of this type. The corresponding ``size`` field for this type is always 1. All cumulative statistics data are read/write. * ``KVM_STATS_TYPE_INSTANT`` - The statistics data is instantaneous. Its value can be increased or + The statistics reports an instantaneous value. Its value can be increased or decreased. This type is usually used as a measurement of some resources, like the number of dirty pages, the number of large pages, etc. All instant statistics are read only. The corresponding ``size`` field for this type is always 1. * ``KVM_STATS_TYPE_PEAK`` - The statistics data is peak. The value of data can only be increased, and - represents a peak value for a measurement, for example the maximum number + The statistics data reports a peak value, for example the maximum number of items in a hash table bucket, the longest time waited and so on. + The value of data can only be increased. The corresponding ``size`` field for this type is always 1. + * ``KVM_STATS_TYPE_LINEAR_HIST`` + The statistic is reported as a linear histogram. The number of + buckets is specified by the ``size`` field. The size of buckets is specified + by the ``hist_param`` field. The range of the Nth bucket (1 <= N < ``size``) + is [``hist_param``*(N-1), ``hist_param``*N), while the range of the last + bucket is [``hist_param``*(``size``-1), +INF). (+INF means positive infinity + value.) The bucket value indicates how many samples fell in the bucket's range. + * ``KVM_STATS_TYPE_LOG_HIST`` + The statistic is reported as a logarithmic histogram. The number of + buckets is specified by the ``size`` field. The range of the first bucket is + [0, 1), while the range of the last bucket is [pow(2, ``size``-2), +INF). + Otherwise, The Nth bucket (1 < N < ``size``) covers + [pow(2, N-2), pow(2, N-1)). The bucket value indicates how many samples fell + in the bucket's range. Bits 4-7 of ``flags`` encode the unit: @@ -5286,9 +5306,9 @@ unsigned 64bit data. The ``offset`` field is the offset from the start of Data Block to the start of the corresponding statistics data. -The ``unused`` field is reserved for future support for other types of -statistics data, like log/linear histogram. Its value is always 0 for the types -defined above. +The ``bucket_size`` field is used as a parameter for histogram statistics data. +It is only used by linear histogram statistics data, specifying the size of a +bucket. The ``name`` field is the name string of the statistics data. The name string starts at the end of ``struct kvm_stats_desc``. The maximum length including @@ -7053,7 +7073,7 @@ In combination with KVM_CAP_X86_USER_SPACE_MSR, this allows user space to trap and emulate MSRs that are outside of the scope of KVM as well as limit the attack surface on KVM's MSR emulation code. -8.28 KVM_CAP_ENFORCE_PV_CPUID +8.28 KVM_CAP_ENFORCE_PV_FEATURE_CPUID ----------------------------- Architectures: x86 diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 35eca377543d..5d27da356836 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -21,14 +21,20 @@ The acquisition orders for mutexes are as follows: can be taken inside a kvm->srcu read-side critical section, while kvm->slots_lock cannot. +- 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 + must not take either kvm->slots_lock or kvm->slots_arch_lock. + On x86: - vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock -- kvm->arch.mmu_lock is an rwlock. kvm->arch.tdp_mmu_pages_lock is - taken inside kvm->arch.mmu_lock, and cannot be taken without already - holding kvm->arch.mmu_lock (typically with ``read_lock``, otherwise - there's no need to take kvm->arch.tdp_mmu_pages_lock at all). +- kvm->arch.mmu_lock is an rwlock. kvm->arch.tdp_mmu_pages_lock and + kvm->arch.mmu_unsync_pages_lock are taken inside kvm->arch.mmu_lock, and + cannot be taken without already holding kvm->arch.mmu_lock (typically with + ``read_lock`` for the TDP MMU, thus the need for additional spinlocks). Everything else is a leaf: no other lock is taken inside the critical sections. diff --git a/Documentation/vm/damon/api.rst b/Documentation/vm/damon/api.rst new file mode 100644 index 000000000000..08f34df45523 --- /dev/null +++ b/Documentation/vm/damon/api.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +API Reference +============= + +Kernel space programs can use every feature of DAMON using below APIs. All you +need to do is including ``damon.h``, which is located in ``include/linux/`` of +the source tree. + +Structures +========== + +.. kernel-doc:: include/linux/damon.h + + +Functions +========= + +.. kernel-doc:: mm/damon/core.c diff --git a/Documentation/vm/damon/design.rst b/Documentation/vm/damon/design.rst new file mode 100644 index 000000000000..b05159c295f4 --- /dev/null +++ b/Documentation/vm/damon/design.rst @@ -0,0 +1,166 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====== +Design +====== + +Configurable Layers +=================== + +DAMON provides data access monitoring functionality while making the accuracy +and the overhead controllable. The fundamental access monitorings require +primitives that dependent on and optimized for the target address space. On +the other hand, the accuracy and overhead tradeoff mechanism, which is the core +of DAMON, is in the pure logic space. DAMON separates the two parts in +different layers and defines its interface to allow various low level +primitives implementations configurable with the core logic. + +Due to this separated design and the configurable interface, users can extend +DAMON for any address space by configuring the core logics with appropriate low +level primitive implementations. If appropriate one is not provided, users can +implement the primitives on their own. + +For example, physical memory, virtual memory, swap space, those for specific +processes, NUMA nodes, files, and backing memory devices would be supportable. +Also, if some architectures or devices support special optimized access check +primitives, those will be easily configurable. + + +Reference Implementations of Address Space Specific Primitives +============================================================== + +The low level primitives for the fundamental access monitoring are defined in +two parts: + +1. Identification of the monitoring target address range for the address space. +2. Access check of specific address range in the target space. + +DAMON currently provides the implementation of the primitives for only the +virtual address spaces. Below two subsections describe how it works. + + +VMA-based Target Address Range Construction +------------------------------------------- + +Only small parts in the super-huge virtual address space of the processes are +mapped to the physical memory and accessed. Thus, tracking the unmapped +address regions is just wasteful. However, because DAMON can deal with some +level of noise using the adaptive regions adjustment mechanism, tracking every +mapping is not strictly required but could even incur a high overhead in some +cases. That said, too huge unmapped areas inside the monitoring target should +be removed to not take the time for the adaptive mechanism. + +For the reason, this implementation converts the complex mappings to three +distinct regions that cover every mapped area of the address space. The two +gaps between the three regions are the two biggest unmapped areas in the given +address space. The two biggest unmapped areas would be the gap between the +heap and the uppermost mmap()-ed region, and the gap between the lowermost +mmap()-ed region and the stack in most of the cases. Because these gaps are +exceptionally huge in usual address spaces, excluding these will be sufficient +to make a reasonable trade-off. Below shows this in detail:: + + <heap> + <BIG UNMAPPED REGION 1> + <uppermost mmap()-ed region> + (small mmap()-ed regions and munmap()-ed regions) + <lowermost mmap()-ed region> + <BIG UNMAPPED REGION 2> + <stack> + + +PTE Accessed-bit Based Access Check +----------------------------------- + +The implementation for the virtual address space uses PTE Accessed-bit for +basic access checks. It finds the relevant PTE Accessed bit from the address +by walking the page table for the target task of the address. In this way, the +implementation finds and clears the bit for next sampling target address and +checks whether the bit set again after one sampling period. This could disturb +other kernel subsystems using the Accessed bits, namely Idle page tracking and +the reclaim logic. To avoid such disturbances, DAMON makes it mutually +exclusive with Idle page tracking and uses ``PG_idle`` and ``PG_young`` page +flags to solve the conflict with the reclaim logic, as Idle page tracking does. + + +Address Space Independent Core Mechanisms +========================================= + +Below four sections describe each of the DAMON core mechanisms and the five +monitoring attributes, ``sampling interval``, ``aggregation interval``, +``regions update interval``, ``minimum number of regions``, and ``maximum +number of regions``. + + +Access Frequency Monitoring +--------------------------- + +The output of DAMON says what pages are how frequently accessed for a given +duration. The resolution of the access frequency is controlled by setting +``sampling interval`` and ``aggregation interval``. In detail, DAMON checks +access to each page per ``sampling interval`` and aggregates the results. In +other words, counts the number of the accesses to each page. After each +``aggregation interval`` passes, DAMON calls callback functions that previously +registered by users so that users can read the aggregated results and then +clears the results. This can be described in below simple pseudo-code:: + + while monitoring_on: + for page in monitoring_target: + if accessed(page): + nr_accesses[page] += 1 + if time() % aggregation_interval == 0: + for callback in user_registered_callbacks: + callback(monitoring_target, nr_accesses) + for page in monitoring_target: + nr_accesses[page] = 0 + sleep(sampling interval) + +The monitoring overhead of this mechanism will arbitrarily increase as the +size of the target workload grows. + + +Region Based Sampling +--------------------- + +To avoid the unbounded increase of the overhead, DAMON groups adjacent pages +that assumed to have the same access frequencies into a region. As long as the +assumption (pages in a region have the same access frequencies) is kept, only +one page in the region is required to be checked. Thus, for each ``sampling +interval``, DAMON randomly picks one page in each region, waits for one +``sampling interval``, checks whether the page is accessed meanwhile, and +increases the access frequency of the region if so. Therefore, the monitoring +overhead is controllable by setting the number of regions. DAMON allows users +to set the minimum and the maximum number of regions for the trade-off. + +This scheme, however, cannot preserve the quality of the output if the +assumption is not guaranteed. + + +Adaptive Regions Adjustment +--------------------------- + +Even somehow the initial monitoring target regions are well constructed to +fulfill the assumption (pages in same region have similar access frequencies), +the data access pattern can be dynamically changed. This will result in low +monitoring quality. To keep the assumption as much as possible, DAMON +adaptively merges and splits each region based on their access frequency. + +For each ``aggregation interval``, it compares the access frequencies of +adjacent regions and merges those if the frequency difference is small. Then, +after it reports and clears the aggregated access frequency of each region, it +splits each region into two or three regions if the total number of regions +will not exceed the user-specified maximum number of regions after the split. + +In this way, DAMON provides its best-effort quality and minimal overhead while +keeping the bounds users set for their trade-off. + + +Dynamic Target Space Updates Handling +------------------------------------- + +The monitoring target address range could dynamically changed. For example, +virtual memory could be dynamically mapped and unmapped. Physical memory could +be hot-plugged. + +As the changes could be quite frequent in some cases, DAMON checks the dynamic +memory mapping changes and applies it to the abstracted target area only for +each of a user-specified time interval (``regions update interval``). diff --git a/Documentation/vm/damon/faq.rst b/Documentation/vm/damon/faq.rst new file mode 100644 index 000000000000..cb3d8b585a8b --- /dev/null +++ b/Documentation/vm/damon/faq.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +Frequently Asked Questions +========================== + +Why a new subsystem, instead of extending perf or other user space tools? +========================================================================= + +First, because it needs to be lightweight as much as possible so that it can be +used online, any unnecessary overhead such as kernel - user space context +switching cost should be avoided. Second, DAMON aims to be used by other +programs including the kernel. Therefore, having a dependency on specific +tools like perf is not desirable. These are the two biggest reasons why DAMON +is implemented in the kernel space. + + +Can 'idle pages tracking' or 'perf mem' substitute DAMON? +========================================================= + +Idle page tracking is a low level primitive for access check of the physical +address space. 'perf mem' is similar, though it can use sampling to minimize +the overhead. On the other hand, DAMON is a higher-level framework for the +monitoring of various address spaces. It is focused on memory management +optimization and provides sophisticated accuracy/overhead handling mechanisms. +Therefore, 'idle pages tracking' and 'perf mem' could provide a subset of +DAMON's output, but cannot substitute DAMON. + + +Does DAMON support virtual memory only? +======================================= + +No. The core of the DAMON is address space independent. The address space +specific low level primitive parts including monitoring target regions +constructions and actual access checks can be implemented and configured on the +DAMON core by the users. In this way, DAMON users can monitor any address +space with any access check technique. + +Nonetheless, DAMON provides vma tracking and PTE Accessed bit check based +implementations of the address space dependent functions for the virtual memory +by default, for a reference and convenient use. In near future, we will +provide those for physical memory address space. + + +Can I simply monitor page granularity? +====================================== + +Yes. You can do so by setting the ``min_nr_regions`` attribute higher than the +working set size divided by the page size. Because the monitoring target +regions size is forced to be ``>=page size``, the region split will make no +effect. diff --git a/Documentation/vm/damon/index.rst b/Documentation/vm/damon/index.rst new file mode 100644 index 000000000000..a2858baf3bf1 --- /dev/null +++ b/Documentation/vm/damon/index.rst @@ -0,0 +1,30 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +DAMON: Data Access MONitor +========================== + +DAMON is a data access monitoring framework subsystem for the Linux kernel. +The core mechanisms of DAMON (refer to :doc:`design` for the detail) make it + + - *accurate* (the monitoring output is useful enough for DRAM level memory + management; It might not appropriate for CPU Cache levels, though), + - *light-weight* (the monitoring overhead is low enough to be applied online), + and + - *scalable* (the upper-bound of the overhead is in constant range regardless + of the size of target workloads). + +Using this framework, therefore, the kernel's memory management mechanisms can +make advanced decisions. Experimental memory management optimization works +that incurring high data accesses monitoring overhead could implemented again. +In user space, meanwhile, users who have some special workloads can write +personalized applications for better understanding and optimizations of their +workloads and systems. + +.. toctree:: + :maxdepth: 2 + + faq + design + api + plans diff --git a/Documentation/vm/hwpoison.rst b/Documentation/vm/hwpoison.rst index a5c884293dac..89b5f7a52077 100644 --- a/Documentation/vm/hwpoison.rst +++ b/Documentation/vm/hwpoison.rst @@ -180,7 +180,6 @@ Limitations =========== - Not all page types are supported and never will. Most kernel internal objects cannot be recovered, only LRU pages for now. -- Right now hugepage support is missing. --- Andi Kleen, Oct 2009 diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst index eff5fbd492d0..b51f0d8992f8 100644 --- a/Documentation/vm/index.rst +++ b/Documentation/vm/index.rst @@ -32,6 +32,7 @@ descriptions of data structures and algorithms. arch_pgtable_helpers balance cleancache + damon/index free_page_reporting frontswap highmem diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index 5f62b3b86357..ccb7e86bf8d9 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -126,7 +126,7 @@ Idle loop Rebooting ========= - reboot=b[ios] | t[riple] | k[bd] | a[cpi] | e[fi] [, [w]arm | [c]old] + reboot=b[ios] | t[riple] | k[bd] | a[cpi] | e[fi] | p[ci] [, [w]arm | [c]old] bios Use the CPU reboot vector for warm reset warm @@ -145,6 +145,8 @@ Rebooting Use efi reset_system runtime service. If EFI is not configured or the EFI reset does not work, the reboot path attempts the reset using the keyboard controller. + pci + Use a write to the PCI config space register 0xcf9 to trigger reboot. Using warm reset will be much faster especially on big memory systems because the BIOS will not go through the memory check. @@ -155,6 +157,13 @@ Rebooting Don't stop other CPUs on reboot. This can make reboot more reliable in some cases. + reboot=default + There are some built-in platform specific "quirks" - you may see: + "reboot: <name> series board detected. Selecting <type> for reboots." + In the case where you think the quirk is in error (e.g. you have + newer BIOS, or newer board) using this option will ignore the built-in + quirk table, and use the generic default reboot actions. + Non Executable Mappings ======================= |