diff options
Diffstat (limited to 'Documentation')
751 files changed, 26220 insertions, 6293 deletions
diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block index 09a9d4aca0fd..900b3fc4c72d 100644 --- a/Documentation/ABI/stable/sysfs-block +++ b/Documentation/ABI/stable/sysfs-block @@ -886,6 +886,21 @@ Description: zone commands, they will be treated as regular block devices and zoned will report "none". +What: /sys/block/<disk>/queue/zoned_qd1_writes +Date: January 2026 +Contact: Damien Le Moal <dlemoal@kernel.org> +Description: + [RW] zoned_qd1_writes indicates if write operations to a zoned + block device are being handled using a single issuer context (a + kernel thread) operating at a maximum queue depth of 1. This + attribute is visible only for zoned block devices. The default + value for zoned block devices that are not rotational devices + (e.g. ZNS SSDs or zoned UFS devices) is 0. For rotational zoned + block devices (e.g. SMR HDDs) the default value is 1. Since + this default may not be appropriate for some devices, e.g. + remotely connected devices over high latency networks, the user + can disable this feature by setting this attribute to 0. + What: /sys/block/<disk>/hidden Date: March 2023 diff --git a/Documentation/ABI/testing/debugfs-hisi-hpre b/Documentation/ABI/testing/debugfs-hisi-hpre index 29fb7d5ffc69..5a137f701eea 100644 --- a/Documentation/ABI/testing/debugfs-hisi-hpre +++ b/Documentation/ABI/testing/debugfs-hisi-hpre @@ -50,6 +50,13 @@ Description: Dump debug registers from the QM. Available for PF and VF in host. VF in guest currently only has one debug register. +What: /sys/kernel/debug/hisi_hpre/<bdf>/dev_usage +Date: Mar 2026 +Contact: linux-crypto@vger.kernel.org +Description: Query the real-time bandwidth usage of device. + Returns the bandwidth usage of each channel on the device. + The returned number is in percentage. + What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/current_q Date: Sep 2019 Contact: linux-crypto@vger.kernel.org diff --git a/Documentation/ABI/testing/debugfs-hisi-sec b/Documentation/ABI/testing/debugfs-hisi-sec index 82bf4a0dc7f7..676e2dc2de8d 100644 --- a/Documentation/ABI/testing/debugfs-hisi-sec +++ b/Documentation/ABI/testing/debugfs-hisi-sec @@ -24,6 +24,13 @@ Description: The <bdf> is related the function for PF and VF. 1/1000~1000/1000 of total QoS. The driver reading alg_qos to get related QoS in the host and VM, Such as "cat alg_qos". +What: /sys/kernel/debug/hisi_sec2/<bdf>/dev_usage +Date: Mar 2026 +Contact: linux-crypto@vger.kernel.org +Description: Query the real-time bandwidth usage of device. + Returns the bandwidth usage of each channel on the device. + The returned number is in percentage. + What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/qm_regs Date: Oct 2019 Contact: linux-crypto@vger.kernel.org diff --git a/Documentation/ABI/testing/debugfs-hisi-zip b/Documentation/ABI/testing/debugfs-hisi-zip index 0abd65d27e9b..46bf47bf6b42 100644 --- a/Documentation/ABI/testing/debugfs-hisi-zip +++ b/Documentation/ABI/testing/debugfs-hisi-zip @@ -36,6 +36,13 @@ Description: The <bdf> is related the function for PF and VF. 1/1000~1000/1000 of total QoS. The driver reading alg_qos to get related QoS in the host and VM, Such as "cat alg_qos". +What: /sys/kernel/debug/hisi_zip/<bdf>/dev_usage +Date: Mar 2026 +Contact: linux-crypto@vger.kernel.org +Description: Query the real-time bandwidth usage of device. + Returns the bandwidth usage of each channel on the device. + The returned number is in percentage. + What: /sys/kernel/debug/hisi_zip/<bdf>/qm/regs Date: Nov 2018 Contact: linux-crypto@vger.kernel.org diff --git a/Documentation/ABI/testing/evm b/Documentation/ABI/testing/evm index 44750a933db4..db3007babb58 100644 --- a/Documentation/ABI/testing/evm +++ b/Documentation/ABI/testing/evm @@ -26,6 +26,7 @@ Description: 2 Permit modification of EVM-protected metadata at runtime. Not supported if HMAC validation and creation is enabled (deprecated). + 3 Require asymmetric signatures to be version 3 31 Disable further runtime modification of EVM policy === ================================================== diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index d4b3696a9efb..19258471b7b2 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -53,10 +53,7 @@ Description: where 'imasig' is the original or the signature format v2. where 'modsig' is an appended signature, - where 'sigv3' is the signature format v3. (Currently - limited to fsverity digest based signatures - stored in security.ima xattr. Requires - specifying "digest_type=verity" first.) + where 'sigv3' is the signature format v3. appraise_flag:= [check_blacklist] (deprecated) Setting the check_blacklist flag is no longer necessary. @@ -186,6 +183,11 @@ Description: appraise func=BPRM_CHECK digest_type=verity \ appraise_type=sigv3 + Example of a regular IMA file hash 'appraise' rule requiring + signature version 3 format stored in security.ima xattr. + + appraise func=BPRM_CHECK appraise_type=sigv3 + All of these policy rules could, for example, be constrained either based on a filesystem's UUID (fsuuid) or based on LSM labels. diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index c80a1b5a03db..16a9b3d2e2c0 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -508,6 +508,19 @@ Description: (RO) The size of extended linear cache, if there is an extended linear cache. Otherwise the attribute will not be visible. + +What: /sys/bus/cxl/devices/regionZ/locked +Date: Mar, 2026 +KernelVersion: v7.1 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) The CXL driver has the capability to lock a region based on + a BIOS or platform dependent configuration. Regions created as + locked are never permitted to be destroyed. Resets to participating + decoders will not result in a region destroy and will not free the + decoder resources. + + What: /sys/bus/cxl/devices/regionZ/mode Date: January, 2023 KernelVersion: v6.3 diff --git a/Documentation/ABI/testing/sysfs-bus-i3c b/Documentation/ABI/testing/sysfs-bus-i3c index c1e048957a01..19f5cf8b1b11 100644 --- a/Documentation/ABI/testing/sysfs-bus-i3c +++ b/Documentation/ABI/testing/sysfs-bus-i3c @@ -172,3 +172,23 @@ Description: the automatic retries. Exist only when I3C constroller supports this retry on nack feature. +What: /sys/bus/i3c/devices/i3c-<bus-id>/do_daa +KernelVersion: 7.0 +Contact: linux-i3c@vger.kernel.org +Description: + Write-only attribute that triggers a Dynamic Address Assignment + (DAA) procedure which discovers new I3C devices on the bus. + Writing a boolean true value (1, y, yes, true, on) to this + attribute causes the master controller to perform DAA, which + includes broadcasting an ENTDAA (Enter Dynamic Address Assignment) + Common Command Code (CCC) on the bus. Writing a false value + returns -EINVAL. + + This is useful for discovering I3C devices that were not present + during initial bus initialization and are unable to issue + Hot-Join. Only devices without a currently assigned dynamic address + will respond to the ENTDAA broadcast and be assigned addresses. + + Note that this mechanism is distinct from Hot-Join, since this is + controller-initiated discovery, while Hot-Join is device-initiated + method to provoke controller discovery procedure. diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index 4b21d5d23251..32697b926cc8 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -675,7 +675,8 @@ Description: Valid values: "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD", - "PD_DRP", "PD_PPS", "BrickID" + "PD_DRP", "PD_PPS", "BrickID", "PD_SPR_AVS", + "PD_PPS_SPR_AVS" **Device Specific Properties** diff --git a/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes new file mode 100644 index 000000000000..a16c54ab841b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes @@ -0,0 +1,36 @@ +What: /sys/class/reboot-mode/<driver>/reboot_modes +Date: March 2026(TBD) +KernelVersion: TBD +Contact: linux-pm@vger.kernel.org + Description: + This interface exposes the reboot-mode arguments + registered with the reboot-mode framework. It is + a read-only interface and provides a space + separated list of reboot-mode arguments supported + on the current platform. + Example: + recovery fastboot bootloader + + The exact sysfs path may vary depending on the + name of the driver that registers the arguments. + Example: + /sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes + /sys/class/reboot-mode/syscon-reboot-mode/reboot_modes + /sys/class/reboot-mode/qcom-pon/reboot_modes + + The supported arguments can be used by userspace to + invoke device reset using the standard reboot() system + call interface, with the "argument" as string to "*arg" + parameter along with LINUX_REBOOT_CMD_RESTART2. + + A driver can expose the supported arguments by + registering them with the reboot-mode framework + using the property names that follow the + mode-<argument> format. + Example: + mode-bootloader, mode-recovery. + + This attribute is useful for scripts or initramfs + logic that need to programmatically determine + which reboot-mode arguments are valid before + triggering a reboot. diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 3a05604c21bf..82d10d556cc8 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -327,6 +327,24 @@ Description: Energy performance preference This file is only present if the cppc-cpufreq driver is in use. +What: /sys/devices/system/cpu/cpuX/cpufreq/perf_limited +Date: February 2026 +Contact: linux-pm@vger.kernel.org +Description: Performance Limited + + Read to check if platform throttling (thermal/power/current + limits) caused delivered performance to fall below the + requested level. A non-zero value indicates throttling occurred. + + Write the bitmask of bits to clear: + + - 0x1 = clear bit 0 (desired performance excursion) + - 0x2 = clear bit 1 (minimum performance excursion) + - 0x3 = clear both bits + + The platform sets these bits; OSPM can only clear them. + + This file is only present if the cppc-cpufreq driver is in use. What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1} Date: August 2008 diff --git a/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go b/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go new file mode 100644 index 000000000000..c8221373ef76 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go @@ -0,0 +1,724 @@ +What: /sys/class/leds/go:rgb:joystick_rings/effect +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the display effect of the RGB interface. + + Values are monocolor, breathe, chroma, or rainbow. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/class/leds/go:rgb:joystick_rings/effect_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the effect attribute. + + Values are monocolor, breathe, chroma, or rainbow. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/class/leds/go:rgb:joystick_rings/enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling or disabling the RGB interface. + + Values are true or false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/class/leds/go:rgb:joystick_rings/enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the enabled attribute. + + Values are true or false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/class/leds/go:rgb:joystick_rings/mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the operating mode of the RGB interface. + + Values are dynamic or custom. Custom allows setting the RGB effect and color. + Dynamic is a Windows mode for syncing Lenovo RGB interfaces not currently + supported under Linux. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/class/leds/go:rgb:joystick_rings/mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the mode attribute. + + Values are dynamic or custom. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/class/leds/go:rgb:joystick_rings/profile +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls selecting the configured RGB profile. + + Values are 1-3. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/class/leds/go:rgb:joystick_rings/profile_range +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the profile attribute. + + Values are 1-3. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/class/leds/go:rgb:joystick_rings/speed +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the change rate for the breathe, chroma, and rainbow effects. + + Values are 0-100. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/class/leds/go:rgb:joystick_rings/speed_range +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the speed attribute. + + Values are 0-100. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/firmware_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the firmware version of the internal MCU. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/fps_mode_dpi +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the DPI of the right handle when the FPS mode switch is on. + + Values are 500, 800, 1200, and 1800. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/fps_mode_dpi_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the fps_mode_dpi attribute. + + Values are 500, 800, 1200, and 1800. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/hardware_generation +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the hardware generation of the internal MCU. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/hardware_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the hardware version of the internal MCU. + + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/auto_sleep_time +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the sleep timer due to inactivity for the left removable controller. + + Values are 0-255. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/auto_sleep_time_range +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the left_handle/auto_sleep_time attribute. + + Values are 0-255. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_gyro +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This initiates or halts calibration of the left removable controller's IMU. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_gyro_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the left_handle/calibrate_gyro attribute. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_gyro_status +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the result of the last attempted calibration of the left removable controller's IMU. + + Values are unknown, success, failure. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_joystick +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This initiates or halts calibration of the left removable controller's joystick. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_joystick_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the left_handle/calibrate_jotstick attribute. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_joystick_status +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the result of the last attempted calibration of the left removable controller's joystick. + + Values are unknown, success, failure. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_tirgger +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This initiates or halts calibration of the left removable controller's trigger. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_gyro_trigger +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the left_handle/calibrate_trigger attribute. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/calibrate_trigger_status +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the result of the last attempted calibration of the left removable controller's trigger. + + Values are unknown, success, failure. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/firmware_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the left removable controller's firmware version. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/hardware_generation +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the hardware generation of the left removable controller. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/hardware_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the hardware version of the left removable controller. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/imu_bypass_enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling or disabling the IMU bypass function of the left removable controller. + + Values are true or false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/imu_bypass_enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the left_handle/imu_bypass_enabled attribute. + + Values are true or false. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/imu_enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling or disabling the IMU of the left removable controller. + + Values are true or false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/imu_enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the left_handle/imu_enabled attribute. + + Values are true or false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/product_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the product version of the left removable controller. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/protocol_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the protocol version of the left removable controller. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/reset +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: Resets the left removable controller to factory defaults. + + Writing 1 to this path initiates. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/rumble_mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls setting the response behavior for rumble events for the left removable controller. + + Values are fps, racing, standarg, spg, rpg. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/rumble_mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the left_handle/rumble_mode attribute. + + Values are fps, racing, standarg, spg, rpg. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/rumble_notification +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling haptic rumble events for the left removable controller. + + Values are true, false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/rumble_notification_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the left_handle/rumble_notification attribute. + + Values are true, false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the operating mode of the built-in controller. + + Values are xinput or dinput. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/left_handle/mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the mode attribute. + + Values are xinput or dinput. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the behavior of built in chord combinations. + + Values are windows or linux. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the os_mode attribute. + + Values are windows or linux. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/product_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the product version of the internal MCU. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/protocol_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the protocol version of the internal MCU. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/reset_mcu +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: Resets the internal MCU to factory defaults. + + Writing 1 to this path initiates. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/auto_sleep_time +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the sleep timer due to inactivity for the right removable controller. + + Values are 0-255. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/auto_sleep_time_range +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the right_handle/auto_sleep_time attribute. + + Values are 0-255. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_gyro +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This initiates or halts calibration of the right removable controller's IMU. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_gyro_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the right_handle/calibrate_gyro attribute. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_gyro_status +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the result of the last attempted calibration of the right removable controller's IMU. + + Values are unknown, success, failure. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_joystick +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This initiates or halts calibration of the right removable controller's joystick. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_joystick_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the right_handle/calibrate_jotstick attribute. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_joystick_status +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the result of the last attempted calibration of the right removable controller's joystick. + + Values are unknown, success, failure. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_tirgger +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This initiates or halts calibration of the right removable controller's trigger. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_gyro_trigger +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the right_handle/calibrate_trigger attribute. + + Values are start, stop. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/calibrate_trigger_status +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the result of the last attempted calibration of the right removable controller's trigger. + + Values are unknown, success, failure. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/firmware_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the right removable controller's firmware version. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/hardware_generation +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the hardware generation of the right removable controller. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/hardware_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the hardware version of the right removable controller. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/imu_bypass_enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling or disabling the IMU bypass function of the right removable controller. + + Values are true or false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/imu_bypass_enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the right_handle/imu_bypass_enabled attribute. + + Values are true or false. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/imu_enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling or disabling the IMU of the right removable controller. + + Values are true or false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/imu_enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the right_handle/imu_enabled attribute. + + Values are true or false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/product_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the product version of the right removable controller. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/protocol_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the protocol version of the right removable controller. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/reset +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: Resets the right removable controller to factory defaults. + + Writing 1 to this path initiates. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/rumble_mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls setting the response behavior for rumble events for the right removable controller. + + Values are fps, racing, standarg, spg, rpg. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/rumble_mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the right_handle/rumble_mode attribute. + + Values are fps, racing, standarg, spg, rpg. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/rumble_notification +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling haptic rumble events for the right removable controller. + + Values are true, false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/right_handle/rumble_notification_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the right_handle/rumble_notification attribute. + + Values are true, false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/rumble_intensity +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls setting the rumble intensity for both removable controllers. + + Values are off, low, medium, high. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/rumble_intensity_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the rumble_intensity attribute. + + Values are off, low, medium, high. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling or disabling the touchpad. + + Values are true, false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the touchpad/enabled attribute. + + Values are true, false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/vibration_enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling haptic rumble events for the touchpad. + + Values are true, false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/vibration_enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the touchpad/vibration_enabled attribute. + + Values are true, false. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/vibration_intensity +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls setting the intensity of the touchpad haptics. + + Values are off, low, medium, high. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/vibration_intensity_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the touchpad/vibration_intensity attribute. + + Values are off, low, medium, high. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/tx_dongle/firmware_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the firmware version of the internal wireless transmission dongle. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/tx_dongle/hardware_generation +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the hardware generation of the internal wireless transmission dongle. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/tx_dongle/hardware_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the hardware version of the internal wireless transmission dongle. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/tx_dongle/product_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the product version of the internal wireless transmission dongle. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/tx_dongle/protocol_version +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the protocol version of the internal wireless transmission dongle. + + Applies to Lenovo Legion Go and Go 2 line of handheld devices. + diff --git a/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s b/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s new file mode 100644 index 000000000000..4d317074bb7e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s @@ -0,0 +1,304 @@ +What: /sys/class/leds/go_s:rgb:joystick_rings/effect +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the display effect of the RGB interface. + + Values are monocolor, breathe, chroma, or rainbow. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/class/leds/go_s:rgb:joystick_rings/effect_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the effect attribute. + + Values are monocolor, breathe, chroma, or rainbow. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/class/leds/go_s:rgb:joystick_rings/enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling or disabling the RGB interface. + + Values are true or false. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/class/leds/go_s:rgb:joystick_rings/enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the enabled attribute. + + Values are true or false. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/class/leds/go_s:rgb:joystick_rings/mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the operating mode of the RGB interface. + + Values are dynamic or custom. Custom allows setting the RGB effect and color. + Dynamic is a Windows mode for syncing Lenovo RGB interfaces not currently + supported under Linux. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/class/leds/go_s:rgb:joystick_rings/mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the mode attribute. + + Values are dynamic or custom. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/class/leds/go_s:rgb:joystick_rings/profile +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls selecting the configured RGB profile. + + Values are 1-3. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/class/leds/go_s:rgb:joystick_rings/profile_range +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the profile attribute. + + Values are 1-3. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/class/leds/go_s:rgb:joystick_rings/speed +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the change rate for the breathe, chroma, and rainbow effects. + + Values are 0-100. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/class/leds/go_s:rgb:joystick_rings/speed_range +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the speed attribute. + + Values are 0-100. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/auto_sleep_time +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the sleep timer due to inactivity for the built-in controller. + + Values are 0-255. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/auto_sleep_time_range +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the gamepad/auto_sleep_time attribute. + + Values are 0-255. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/dpad_mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the operating mode of the built-in controllers D-pad. + + Values are 4-way or 8-way. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/dpad_mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the gamepad/dpad_mode attribute. + + Values are 4-way or 8-way. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the operating mode of the built-in controller. + + Values are xinput or dinput. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the gamepad/mode attribute. + + Values are xinput or dinput. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/poll_rate +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls the poll rate in Hz of the built-in controller. + + Values are 125, 250, 500, or 1000. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/gamepad/poll_rate_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the gamepad/poll_rate attribute. + + Values are 125, 250, 500, or 1000. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/imu/bypass_enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling or disabling the IMU bypass function. When enabled the IMU data is directly reported to the OS through +an HIDRAW interface. + + Values are true or false. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/imu/bypass_enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the imu/bypass_enabled attribute. + + Values are true or false. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/imu/manufacturer +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the manufacturer of the intertial measurment unit. + + Values are Bosch or ST. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/imu/sensor_enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling or disabling the IMU. + + Values are true, false, or wake-2s. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/imu/sensor_enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the imu/sensor_enabled attribute. + + Values are true, false, or wake-2s. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/mcu_id +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the MCU Identification Number + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/mouse/step +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls which value is used for the mouse sensitivity. + + Values are 1-127. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/mouse/step_range +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the mouse/step attribute. + + Values are 1-127. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls which value is used for the touchpads operating mode. + + Values are windows or linux. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the os_mode attribute. + + Values are windows or linux. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls enabling or disabling the built-in touchpad. + + Values are true or false. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the touchpad/enabled attribute. + + Values are true or false. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/linux_mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls behavior of the touchpad events when os_mode is set to linux. + + Values are absolute or relative. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/linux_mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the touchpad/linux_mode attribute. + + Values are absolute or relative. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/windows_mode +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This controls behavior of the touchpad events when os_mode is set to windows. + + Values are absolute or relative. + + Applies to Lenovo Legion Go S line of handheld devices. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/windows_mode_index +Date: April 2026 +Contact: linux-input@vger.kernel.org +Description: This displays the available options for the touchpad/windows_mode attribute. + + Values are absolute or relative. + + Applies to Lenovo Legion Go S line of handheld devices. diff --git a/Documentation/ABI/testing/sysfs-driver-intel-xe-sriov b/Documentation/ABI/testing/sysfs-driver-intel-xe-sriov index 7f5ef9eada53..1d6eaff6882f 100644 --- a/Documentation/ABI/testing/sysfs-driver-intel-xe-sriov +++ b/Documentation/ABI/testing/sysfs-driver-intel-xe-sriov @@ -129,6 +129,37 @@ Description: -EIO if FW refuses to change the provisioning. +What: /sys/bus/pci/drivers/xe/.../sriov_admin/.bulk_profile/vram_quota +What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/profile/vram_quota +Date: February 2026 +KernelVersion: 7.0 +Contact: intel-xe@lists.freedesktop.org +Description: + These files allow to perform initial VFs VRAM provisioning prior to VFs + enabling or to change VFs VRAM provisioning once the VFs are enabled. + Any non-zero initial VRAM provisioning will block VFs auto-provisioning. + Without initial VRAM provisioning those files will show result of the + VRAM auto-provisioning performed by the PF once the VFs are enabled. + Once the VFs are disabled, all VRAM provisioning will be released. + These files are visible only on discrete Intel Xe platforms with VRAM + and are writeable only if dynamic VFs VRAM provisioning is supported. + + .bulk_profile/vram_quota: (WO) unsigned integer + The amount of the provisioned VRAM in [bytes] for each VF. + Actual quota value might be aligned per HW/FW requirements. + + profile/vram_quota: (RW) unsigned integer + The amount of the provisioned VRAM in [bytes] for this VF. + Actual quota value might be aligned per HW/FW requirements. + + Default is 0 (unprovisioned). + + Writes to these attributes may fail with errors like: + -EINVAL if provided input is malformed or not recognized, + -EPERM if change is not applicable on given HW/FW, + -EIO if FW refuses to change the provisioning. + + What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/stop Date: October 2025 KernelVersion: 6.19 diff --git a/Documentation/ABI/testing/sysfs-driver-qat_svn b/Documentation/ABI/testing/sysfs-driver-qat_svn new file mode 100644 index 000000000000..3832b523dcb0 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-qat_svn @@ -0,0 +1,114 @@ +What: /sys/bus/pci/devices/<BDF>/qat_svn/ +Date: June 2026 +KernelVersion: 7.1 +Contact: qat-linux@intel.com +Description: Directory containing Security Version Number (SVN) attributes for + the Anti-Rollback (ARB) feature. The ARB feature prevents downloading + older firmware versions to the acceleration device. + +What: /sys/bus/pci/devices/<BDF>/qat_svn/enforced_min +Date: June 2026 +KernelVersion: 7.1 +Contact: qat-linux@intel.com +Description: + (RO) Reports the minimum allowed firmware SVN. + + Returns an integer greater than zero. Firmware with SVN lower than + this value is rejected. + + A write to qat_svn/commit will update this value. The update is not + persistent across reboot; on reboot, this value is reset from + qat_svn/permanent_min. + + Example usage:: + + # cat /sys/bus/pci/devices/<BDF>/qat_svn/enforced_min + 2 + + This attribute is available only on devices that support + Anti-Rollback. + +What: /sys/bus/pci/devices/<BDF>/qat_svn/permanent_min +Date: June 2026 +KernelVersion: 7.1 +Contact: qat-linux@intel.com +Description: + (RO) Reports the persistent minimum SVN used to initialize + qat_svn/enforced_min on each reboot. + + Returns an integer greater than zero. A write to qat_svn/commit + may update this value, depending on platform/BIOS settings. + + Example usage:: + + # cat /sys/bus/pci/devices/<BDF>/qat_svn/permanent_min + 3 + + This attribute is available only on devices that support + Anti-Rollback. + +What: /sys/bus/pci/devices/<BDF>/qat_svn/active +Date: June 2026 +KernelVersion: 7.1 +Contact: qat-linux@intel.com +Description: + (RO) Reports the SVN of the currently active firmware image. + + Returns an integer greater than zero. + + Example usage:: + + # cat /sys/bus/pci/devices/<BDF>/qat_svn/active + 2 + + This attribute is available only on devices that support + Anti-Rollback. + +What: /sys/bus/pci/devices/<BDF>/qat_svn/commit +Date: June 2026 +KernelVersion: 7.1 +Contact: qat-linux@intel.com +Description: + (WO) Commits the currently active SVN as the minimum allowed SVN. + + Writing 1 sets qat_svn/enforced_min to the value of qat_svn/active, + preventing future firmware loads with lower SVN. + + Depending on platform/BIOS settings, a commit may also update + qat_svn/permanent_min. + + Note that on reboot, qat_svn/enforced_min reverts to + qat_svn/permanent_min. + + It is advisable to use this attribute with caution, only when + it is necessary to set a new minimum SVN for the firmware. + + Before committing the SVN update, it is crucial to check the + current values of qat_svn/active, qat_svn/enforced_min and + qat_svn/permanent_min. This verification helps ensure that the + commit operation aligns with the intended outcome. + + While writing to the file, any value other than '1' will result + in an error and have no effect. + + Example usage:: + + ## Read current values + # cat /sys/bus/pci/devices/<BDF>/qat_svn/enforced_min + 2 + # cat /sys/bus/pci/devices/<BDF>/qat_svn/permanent_min + 2 + # cat /sys/bus/pci/devices/<BDF>/qat_svn/active + 3 + + ## Commit active SVN + # echo 1 > /sys/bus/pci/devices/<BDF>/qat_svn/commit + + ## Read updated values + # cat /sys/bus/pci/devices/<BDF>/qat_svn/enforced_min + 3 + # cat /sys/bus/pci/devices/<BDF>/qat_svn/permanent_min + 3 + + This attribute is available only on devices that support + Anti-Rollback. diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index a90612ab5780..3c422aac778b 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -1768,3 +1768,26 @@ Description: ==================== =========================== The attribute is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/dme_qos_notification +What: /sys/bus/platform/devices/*.ufs/dme_qos_notification +Date: March 2026 +Contact: Can Guo <can.guo@oss.qualcomm.com> +Description: + This attribute reports and clears pending DME (Device Management + Entity) Quality of Service (QoS) notifications. This attribute + is a bitfield with the following bit assignments: + + Bit Description + === ====================================== + 0 DME QoS Monitor has been reset by host + 1 QoS from TX is detected + 2 QoS from RX is detected + 3 QoS from PA_INIT is detected + + Reading this attribute returns the pending DME QoS notification + bits. Writing '0' to this attribute clears pending DME QoS + notification bits. Writing any non-zero value is invalid and + will be rejected. + + The attribute is read/write. diff --git a/Documentation/ABI/testing/sysfs-driver-uniwill-laptop b/Documentation/ABI/testing/sysfs-driver-uniwill-laptop index 2df70792968f..2397c65c969a 100644 --- a/Documentation/ABI/testing/sysfs-driver-uniwill-laptop +++ b/Documentation/ABI/testing/sysfs-driver-uniwill-laptop @@ -51,3 +51,30 @@ Description: Reading this file returns the current status of the breathing animation functionality. + +What: /sys/bus/platform/devices/INOU0000:XX/ctgp_offset +Date: January 2026 +KernelVersion: 7.0 +Contact: Werner Sembach <wse@tuxedocomputers.com> +Description: + Allows userspace applications to set the configurable TGP offset on top of the base + TGP. Base TGP and max TGP and therefore the max cTGP offset are device specific. + Note that setting the maximum cTGP leaves no window open for Dynamic Boost as + Dynamic Boost also can not go over max TGP. Setting the cTGP to maximum is + effectively disabling Dynamic Boost and telling the device to always prioritize the + GPU over the CPU. + + Reading this file returns the current configurable TGP offset. + +What: /sys/bus/platform/devices/INOU0000:XX/usb_c_power_priority +Date: February 2026 +KernelVersion: 7.1 +Contact: Werner Sembach <wse@tuxedocomputers.com> +Description: + Allows userspace applications to choose the USB-C power distribution profile between + one that offers a bigger share of the power to the battery and one that offers more + of it to the CPU. Writing "charging"/"performance" into this file selects the + respective profile. + + Reading this file returns the profile names with the currently active one in + brackets. diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi index 72e7c9161ce7..fa33dda331f2 100644 --- a/Documentation/ABI/testing/sysfs-firmware-acpi +++ b/Documentation/ABI/testing/sysfs-firmware-acpi @@ -41,6 +41,12 @@ Description: platform runtime firmware S3 resume, just prior to handoff to the OS waking vector. In nanoseconds. + FBPT: The raw binary contents of the Firmware Basic Boot + Performance Table (FBPT) subtable. + + S3PT: The raw binary contents of the S3 Performance Table + (S3PT) subtable. + What: /sys/firmware/acpi/bgrt/ Date: January 2012 Contact: Matthew Garrett <mjg@redhat.com> diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index c1d2b3fd9c65..423ec40e2e4e 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -407,6 +407,12 @@ Contact: "Hridya Valsaraju" <hridya@google.com> Description: Average number of valid blocks. Available when CONFIG_F2FS_STAT_FS=y. +What: /sys/fs/f2fs/<disk>/defrag_blocks +Date: February 2026 +Contact: "Jinbao Liu" <liujinbao1@xiaomi.com> +Description: Number of blocks moved by defragment. + Available when CONFIG_F2FS_STAT_FS=y. + What: /sys/fs/f2fs/<disk>/mounted_time_sec Date: February 2020 Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon index f2af2ddedd32..2424237ebb10 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-damon +++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon @@ -316,6 +316,12 @@ Contact: SeongJae Park <sj@kernel.org> Description: Writing to and reading from this file sets and gets the path parameter of the goal. +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goal_tuner +Date: Mar 2026 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the + goal-based effective quota auto-tuning algorithm to use. + What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/weights/sz_permil Date: Mar 2022 Contact: SeongJae Park <sj@kernel.org> diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module index 6bc9af6229f0..d5b7d19bd310 100644 --- a/Documentation/ABI/testing/sysfs-module +++ b/Documentation/ABI/testing/sysfs-module @@ -48,6 +48,15 @@ Contact: Kay Sievers <kay.sievers@vrfy.org> Description: Show the initialization state(live, coming, going) of the module. +What: /sys/module/*/import_ns +Date: January 2026 +KernelVersion: 7.1 +Contact: linux-modules@vger.kernel.org +Description: List of symbol namespaces imported by this module via + MODULE_IMPORT_NS(). Each namespace appears on a separate line. + This file only exists for modules that import at least one + namespace. + What: /sys/module/*/taint Date: Jan 2012 KernelVersion: 3.3 diff --git a/Documentation/ABI/testing/sysfs-nvme b/Documentation/ABI/testing/sysfs-nvme new file mode 100644 index 000000000000..499d5f843cd4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-nvme @@ -0,0 +1,13 @@ +What: /sys/devices/virtual/nvme-fabrics/ctl/.../tls_configured_key +Date: November 2025 +KernelVersion: 6.19 +Contact: Linux NVMe mailing list <linux-nvme@lists.infradead.org> +Description: + The file is avaliable when using a secure concatanation + connection to a NVMe target. Reading the file will return + the serial of the currently negotiated key. + + Writing 0 to the file will trigger a PSK reauthentication + (REPLACETLSPSK) with the target. After a reauthentication + the value returned by tls_configured_key will be the new + serial. diff --git a/Documentation/PCI/msi-howto.rst b/Documentation/PCI/msi-howto.rst index 667ebe2156b4..844c1d3c395d 100644 --- a/Documentation/PCI/msi-howto.rst +++ b/Documentation/PCI/msi-howto.rst @@ -113,8 +113,11 @@ vectors, use the following function:: int pci_irq_vector(struct pci_dev *dev, unsigned int nr); -Any allocated resources should be freed before removing the device using -the following function:: +If the driver enables the device using pcim_enable_device(), the driver +shouldn't call pci_free_irq_vectors() because pcim_enable_device() +activates automatic management for IRQ vectors. Otherwise, the driver should +free any allocated IRQ vectors before removing the device using the following +function:: void pci_free_irq_vectors(struct pci_dev *dev); diff --git a/Documentation/PCI/tph.rst b/Documentation/PCI/tph.rst index e8993be64fd6..b6cf22b9bd90 100644 --- a/Documentation/PCI/tph.rst +++ b/Documentation/PCI/tph.rst @@ -79,10 +79,10 @@ To retrieve a Steering Tag for a target memory associated with a specific CPU, use the following function:: int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type type, - unsigned int cpu_uid, u16 *tag); + unsigned int cpu, u16 *tag); The `type` argument is used to specify the memory type, either volatile -or persistent, of the target memory. The `cpu_uid` argument specifies the +or persistent, of the target memory. The `cpu` argument specifies the CPU where the memory is associated to. After the ST value is retrieved, the device driver can use the following diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index b5cdbba3ec2e..4d886e7c7a95 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -2787,6 +2787,13 @@ which avoids the read-side memory barriers, at least for architectures that apply noinstr to kernel entry/exit code (or that build with ``CONFIG_TASKS_TRACE_RCU_NO_MB=y``. +Now that the implementation is based on SRCU-fast, a call +to synchronize_rcu_tasks_trace() implies at least one call to +synchronize_rcu(), that is, every Tasks Trace RCU grace period contains +at least one plain vanilla RCU grace period. Should there ever +be a synchronize_rcu_tasks_trace_expedited(), this guarantee would +*not* necessarily apply to this hypothetical API member. + The tasks-trace-RCU API is also reasonably compact, consisting of rcu_read_lock_trace(), rcu_read_unlock_trace(), rcu_read_lock_trace_held(), call_rcu_tasks_trace(), diff --git a/Documentation/admin-guide/bcache.rst b/Documentation/admin-guide/bcache.rst index f71f349553e4..325816edbdab 100644 --- a/Documentation/admin-guide/bcache.rst +++ b/Documentation/admin-guide/bcache.rst @@ -618,7 +618,7 @@ cache_replacement_policy One of either lru, fifo or random. freelist_percent - Size of the freelist as a percentage of nbuckets. Can be written to to + Size of the freelist as a percentage of nbuckets. Can be written to increase the number of buckets kept on the freelist, which lets you artificially reduce the size of the cache at runtime. Mostly for testing purposes (i.e. testing how different size caches affect your hit rate). diff --git a/Documentation/admin-guide/blockdev/zoned_loop.rst b/Documentation/admin-guide/blockdev/zoned_loop.rst index 6aa865424ac3..f4f1f3121bf9 100644 --- a/Documentation/admin-guide/blockdev/zoned_loop.rst +++ b/Documentation/admin-guide/blockdev/zoned_loop.rst @@ -62,7 +62,7 @@ The options available for the add command can be listed by reading the /dev/zloop-control device:: $ cat /dev/zloop-control - add id=%d,capacity_mb=%u,zone_size_mb=%u,zone_capacity_mb=%u,conv_zones=%u,base_dir=%s,nr_queues=%u,queue_depth=%u,buffered_io + add id=%d,capacity_mb=%u,zone_size_mb=%u,zone_capacity_mb=%u,conv_zones=%u,max_open_zones=%u,base_dir=%s,nr_queues=%u,queue_depth=%u,buffered_io,zone_append=%u,ordered_zone_append,discard_write_cache remove id=%d In more details, the options that can be used with the "add" command are as @@ -80,6 +80,9 @@ zone_capacity_mb Device zone capacity (must always be equal to or lower conv_zones Total number of conventioanl zones starting from sector 0 Default: 8 +max_open_zones Maximum number of open sequential write required zones + (0 for no limit). + Default: 0 base_dir Path to the base directory where to create the directory containing the zone files of the device. Default=/var/local/zloop. @@ -104,6 +107,11 @@ ordered_zone_append Enable zloop mitigation of zone append reordering. (extents), as when enabled, this can significantly reduce the number of data extents needed to for a file data mapping. +discard_write_cache Discard all data that was not explicitly persisted using a + flush operation when the device is removed by truncating + each zone file to the size recorded during the last flush + operation. This simulates power fail events where + uncommitted data is lost. =================== ========================================================= 3) Deleting a Zoned Device diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst index 451fa00d3004..60b07a7e30cd 100644 --- a/Documentation/admin-guide/blockdev/zram.rst +++ b/Documentation/admin-guide/blockdev/zram.rst @@ -462,7 +462,7 @@ know it via /sys/block/zram0/bd_stat's 3rd column. recompression ------------- -With CONFIG_ZRAM_MULTI_COMP, zram can recompress pages using alternative +With `CONFIG_ZRAM_MULTI_COMP`, zram can recompress pages using alternative (secondary) compression algorithms. The basic idea is that alternative compression algorithm can provide better compression ratio at a price of (potentially) slower compression/decompression speeds. Alternative compression @@ -471,7 +471,7 @@ that default algorithm failed to compress). Another application is idle pages recompression - pages that are cold and sit in the memory can be recompressed using more effective algorithm and, hence, reduce zsmalloc memory usage. -With CONFIG_ZRAM_MULTI_COMP, zram supports up to 4 compression algorithms: +With `CONFIG_ZRAM_MULTI_COMP`, zram supports up to 4 compression algorithms: one primary and up to 3 secondary ones. Primary zram compressor is explained in "3) Select compression algorithm", secondary algorithms are configured using recomp_algorithm device attribute. @@ -495,56 +495,43 @@ configuration::: #select deflate recompression algorithm, priority 2 echo "algo=deflate priority=2" > /sys/block/zramX/recomp_algorithm -Another device attribute that CONFIG_ZRAM_MULTI_COMP enables is recompress, +Another device attribute that `CONFIG_ZRAM_MULTI_COMP` enables is `recompress`, which controls recompression. Examples::: #IDLE pages recompression is activated by `idle` mode - echo "type=idle" > /sys/block/zramX/recompress + echo "type=idle priority=1" > /sys/block/zramX/recompress #HUGE pages recompression is activated by `huge` mode - echo "type=huge" > /sys/block/zram0/recompress + echo "type=huge priority=2" > /sys/block/zram0/recompress #HUGE_IDLE pages recompression is activated by `huge_idle` mode - echo "type=huge_idle" > /sys/block/zramX/recompress + echo "type=huge_idle priority=1" > /sys/block/zramX/recompress The number of idle pages can be significant, so user-space can pass a size threshold (in bytes) to the recompress knob: zram will recompress only pages of equal or greater size::: #recompress all pages larger than 3000 bytes - echo "threshold=3000" > /sys/block/zramX/recompress + echo "threshold=3000 priority=1" > /sys/block/zramX/recompress #recompress idle pages larger than 2000 bytes - echo "type=idle threshold=2000" > /sys/block/zramX/recompress + echo "type=idle threshold=2000 priority=1" > \ + /sys/block/zramX/recompress It is also possible to limit the number of pages zram re-compression will attempt to recompress::: - echo "type=huge_idle max_pages=42" > /sys/block/zramX/recompress - -During re-compression for every page, that matches re-compression criteria, -ZRAM iterates the list of registered alternative compression algorithms in -order of their priorities. ZRAM stops either when re-compression was -successful (re-compressed object is smaller in size than the original one) -and matches re-compression criteria (e.g. size threshold) or when there are -no secondary algorithms left to try. If none of the secondary algorithms can -successfully re-compressed the page such a page is marked as incompressible, -so ZRAM will not attempt to re-compress it in the future. - -This re-compression behaviour, when it iterates through the list of -registered compression algorithms, increases our chances of finding the -algorithm that successfully compresses a particular page. Sometimes, however, -it is convenient (and sometimes even necessary) to limit recompression to -only one particular algorithm so that it will not try any other algorithms. -This can be achieved by providing a `algo` or `priority` parameter::: - - #use zstd algorithm only (if registered) - echo "type=huge algo=zstd" > /sys/block/zramX/recompress - - #use zstd algorithm only (if zstd was registered under priority 1) - echo "type=huge priority=1" > /sys/block/zramX/recompress + echo "type=huge_idle priority=1 max_pages=42" > \ + /sys/block/zramX/recompress + +It is advised to always specify `priority` parameter. While it is also +possible to specify `algo` parameter, so that `zram` will use algorithm's +name to determine the priority, it is not recommended, since it can lead to +unexpected results when the same algorithm is configured with different +priorities (e.g. different parameters). `priority` is the only way to +guarantee that the expected algorithm will be used. memory tracking =============== diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 91beaa6798ce..8ad0b2781317 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1734,6 +1734,11 @@ The following nested keys are defined. zswpwb Number of pages written from zswap to swap. + zswap_incomp + Number of incompressible pages currently stored in zswap + without compression. These pages could not be compressed to + a size smaller than PAGE_SIZE, so they are stored as-is. + thp_fault_alloc (npn) Number of transparent hugepages which were allocated to satisfy a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE diff --git a/Documentation/admin-guide/cpu-isolation.rst b/Documentation/admin-guide/cpu-isolation.rst new file mode 100644 index 000000000000..8c65d03fd28c --- /dev/null +++ b/Documentation/admin-guide/cpu-isolation.rst @@ -0,0 +1,357 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +CPU Isolation +============= + +Introduction +============ + +"CPU Isolation" means leaving a CPU exclusive to a given workload +without any undesired code interference from the kernel. + +Those interferences, commonly pointed out as "noise", can be triggered +by asynchronous events (interrupts, timers, scheduler preemption by +workqueues and kthreads, ...) or synchronous events (syscalls and page +faults). + +Such noise usually goes unnoticed. After all, synchronous events are a +component of the requested kernel service. And asynchronous events are +either sufficiently well-distributed by the scheduler when executed +as tasks or reasonably fast when executed as interrupt. The timer +interrupt can even execute 1024 times per seconds without a significant +and measurable impact most of the time. + +However some rare and extreme workloads can be quite sensitive to +those kinds of noise. This is the case, for example, with high +bandwidth network processing that can't afford losing a single packet +or very low latency network processing. Typically those use cases +involve DPDK, bypassing the kernel networking stack and performing +direct access to the networking device from userspace. + +In order to run a CPU without or with limited kernel noise, the +related housekeeping work needs to be either shut down, migrated or +offloaded. + +Housekeeping +============ + +In the CPU isolation terminology, housekeeping is the work, often +asynchronous, that the kernel needs to process in order to maintain +all its services. It matches the noises and disturbances enumerated +above except when at least one CPU is isolated. Then housekeeping may +make use of further coping mechanisms if CPU-tied work must be +offloaded. + +Housekeeping CPUs are the non-isolated CPUs where the kernel noise +is moved away from isolated CPUs. + +The isolation can be implemented in several ways depending on the +nature of the noise: + +- Unbound work, where "unbound" means not tied to any CPU, can be + simply migrated away from isolated CPUs to housekeeping CPUs. + This is the case of unbound workqueues, kthreads and timers. + +- Bound work, where "bound" means tied to a specific CPU, usually + can't be moved away as-is by nature. Either: + + - The work must switch to a locked implementation. E.g.: + This is the case of RCU with CONFIG_RCU_NOCB_CPU. + + - The related feature must be shut down and considered + incompatible with isolated CPUs. E.g.: Lockup watchdog, + unreliable clocksources, etc... + + - An elaborate and heavyweight coping mechanism stands as a + replacement. E.g.: the timer tick is shut down on nohz_full + CPUs but with the constraint of running a single task on + them. A significant cost penalty is added on kernel entry/exit + and a residual 1Hz scheduler tick is offloaded to housekeeping + CPUs. + +In any case, housekeeping work has to be handled, which is why there +must be at least one housekeeping CPU in the system, preferably more +if the machine runs a lot of CPUs. For example one per node on NUMA +systems. + +Also CPU isolation often means a tradeoff between noise-free isolated +CPUs and added overhead on housekeeping CPUs, sometimes even on +isolated CPUs entering the kernel. + +Isolation features +================== + +Different levels of isolation can be configured in the kernel, each of +which has its own drawbacks and tradeoffs. + +Scheduler domain isolation +-------------------------- + +This feature isolates a CPU from the scheduler topology. As a result, +the target isn't part of the load balancing. Tasks won't migrate +either from or to it unless affined explicitly. + +As a side effect the CPU is also isolated from unbound workqueues and +unbound kthreads. + +Requirements +~~~~~~~~~~~~ + +- CONFIG_CPUSETS=y for the cpusets-based interface + +Tradeoffs +~~~~~~~~~ + +By nature, the system load is overall less distributed since some CPUs +are extracted from the global load balancing. + +Interfaces +~~~~~~~~~~ + +- Documentation/admin-guide/cgroup-v2.rst cpuset isolated partitions are recommended + because they are tunable at runtime. + +- The 'isolcpus=' kernel boot parameter with the 'domain' flag is a + less flexible alternative that doesn't allow for runtime + reconfiguration. + +IRQs isolation +-------------- + +Isolate the IRQs whenever possible, so that they don't fire on the +target CPUs. + +Interfaces +~~~~~~~~~~ + +- The file /proc/irq/\*/smp_affinity as explained in detail in + Documentation/core-api/irq/irq-affinity.rst page. + +- The "irqaffinity=" kernel boot parameter for a default setting. + +- The "managed_irq" flag in the "isolcpus=" kernel boot parameter + tries a best effort affinity override for managed IRQs. + +Full Dynticks (aka nohz_full) +----------------------------- + +Full dynticks extends the dynticks idle mode, which stops the tick when +the CPU is idle, to CPUs running a single task in userspace. That is, +the timer tick is stopped if the environment allows it. + +Global timer callbacks are also isolated from the nohz_full CPUs. + +Requirements +~~~~~~~~~~~~ + +- CONFIG_NO_HZ_FULL=y + +Constraints +~~~~~~~~~~~ + +- The isolated CPUs must run a single task only. Multitask requires + the tick to maintain preemption. This is usually fine since the + workload usually can't stand the latency of random context switches. + +- No call to the kernel from isolated CPUs, at the risk of triggering + random noise. + +- No use of POSIX CPU timers on isolated CPUs. + +- Architecture must have a stable and reliable clocksource (no + unreliable TSC that requires the watchdog). + + +Tradeoffs +~~~~~~~~~ + +In terms of cost, this is the most invasive isolation feature. It is +assumed to be used when the workload spends most of its time in +userspace and doesn't rely on the kernel except for preparatory +work because: + +- RCU adds more overhead due to the locked, offloaded and threaded + callbacks processing (the same that would be obtained with "rcu_nocbs" + boot parameter). + +- Kernel entry/exit through syscalls, exceptions and IRQs are more + costly due to fully ordered RmW operations that maintain userspace + as RCU extended quiescent state. Also the CPU time is accounted on + kernel boundaries instead of periodically from the tick. + +- Housekeeping CPUs must run a 1Hz residual remote scheduler tick + on behalf of the isolated CPUs. + +Checklist +========= + +You have set up each of the above isolation features but you still +observe jitters that trash your workload? Make sure to check a few +elements before proceeding. + +Some of these checklist items are similar to those of real-time +workloads: + +- Use mlock() to prevent your pages from being swapped away. Page + faults are usually not compatible with jitter sensitive workloads. + +- Avoid SMT to prevent your hardware thread from being "preempted" + by another one. + +- CPU frequency changes may induce subtle sorts of jitter in a + workload. Cpufreq should be used and tuned with caution. + +- Deep C-states may result in latency issues upon wake-up. If this + happens to be a problem, C-states can be limited via kernel boot + parameters such as processor.max_cstate or intel_idle.max_cstate. + More finegrained tunings are described in + Documentation/admin-guide/pm/cpuidle.rst page + +- Your system may be subject to firmware-originating interrupts - x86 has + System Management Interrupts (SMIs) for example. Check your system BIOS + to disable such interference, and with some luck your vendor will have + a BIOS tuning guidance for low-latency operations. + + +Full isolation example +====================== + +In this example, the system has 8 CPUs and the 8th is to be fully +isolated. Since CPUs start from 0, the 8th CPU is CPU 7. + +Kernel parameters +----------------- + +Set the following kernel boot parameters to disable SMT and setup tick +and IRQ isolation: + +- Full dynticks: nohz_full=7 + +- IRQs isolation: irqaffinity=0-6 + +- Managed IRQs isolation: isolcpus=managed_irq,7 + +- Prevent SMT: nosmt + +The full command line is then: + + nohz_full=7 irqaffinity=0-6 isolcpus=managed_irq,7 nosmt + +CPUSET configuration (cgroup v2) +-------------------------------- + +Assuming cgroup v2 is mounted to /sys/fs/cgroup, the following script +isolates CPU 7 from scheduler domains. + +:: + + cd /sys/fs/cgroup + # Activate the cpuset subsystem + echo +cpuset > cgroup.subtree_control + # Create partition to be isolated + mkdir test + cd test + echo +cpuset > cgroup.subtree_control + # Isolate CPU 7 + echo 7 > cpuset.cpus + echo "isolated" > cpuset.cpus.partition + +The userspace workload +---------------------- + +Fake a pure userspace workload, the program below runs a dummy +userspace loop on the isolated CPU 7. + +:: + + #include <stdio.h> + #include <fcntl.h> + #include <unistd.h> + #include <errno.h> + int main(void) + { + // Move the current task to the isolated cpuset (bind to CPU 7) + int fd = open("/sys/fs/cgroup/test/cgroup.procs", O_WRONLY); + if (fd < 0) { + perror("Can't open cpuset file...\n"); + return 0; + } + + write(fd, "0\n", 2); + close(fd); + + // Run an endless dummy loop until the launcher kills us + while (1) + ; + + return 0; + } + +Build it and save for later step: + +:: + + # gcc user_loop.c -o user_loop + +The launcher +------------ + +The below launcher runs the above program for 10 seconds and traces +the noise resulting from preempting tasks and IRQs. + +:: + + TRACING=/sys/kernel/tracing/ + # Make sure tracing is off for now + echo 0 > $TRACING/tracing_on + # Flush previous traces + echo > $TRACING/trace + # Record disturbance from other tasks + echo 1 > $TRACING/events/sched/sched_switch/enable + # Record disturbance from interrupts + echo 1 > $TRACING/events/irq_vectors/enable + # Now we can start tracing + echo 1 > $TRACING/tracing_on + # Run the dummy user_loop for 10 seconds on CPU 7 + ./user_loop & + USER_LOOP_PID=$! + sleep 10 + kill $USER_LOOP_PID + # Disable tracing and save traces from CPU 7 in a file + echo 0 > $TRACING/tracing_on + cat $TRACING/per_cpu/cpu7/trace > trace.7 + +If no specific problem arose, the output of trace.7 should look like +the following: + +:: + + <idle>-0 [007] d..2. 1980.976624: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=user_loop next_pid=1553 next_prio=120 + user_loop-1553 [007] d.h.. 1990.946593: reschedule_entry: vector=253 + user_loop-1553 [007] d.h.. 1990.946593: reschedule_exit: vector=253 + +That is, no specific noise triggered between the first trace and the +second during 10 seconds when user_loop was running. + +Debugging +========= + +Of course things are never so easy, especially on this matter. +Chances are that actual noise will be observed in the aforementioned +trace.7 file. + +The best way to investigate further is to enable finer grained +tracepoints such as those of subsystems producing asynchronous +events: workqueue, timer, irq_vector, etc... It also can be +interesting to enable the tick_stop event to diagnose why the tick is +retained when that happens. + +Some tools may also be useful for higher level analysis: + +- Documentation/tools/rtla/rtla.rst provides a suite of tools to analyze + latency and noise in the system. For example Documentation/tools/rtla/rtla-osnoise.rst + runs a kernel tracer that analyzes and output a summary of the noises. + +- dynticks-testing does something similar to rtla-osnoise but in userspace. It is available + at git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst index 3ecab1cff9c6..eb9475d7e196 100644 --- a/Documentation/admin-guide/device-mapper/verity.rst +++ b/Documentation/admin-guide/device-mapper/verity.rst @@ -102,29 +102,42 @@ ignore_zero_blocks that are not guaranteed to contain zeroes. use_fec_from_device <fec_dev> - Use forward error correction (FEC) to recover from corruption if hash - verification fails. Use encoding data from the specified device. This - may be the same device where data and hash blocks reside, in which case - fec_start must be outside data and hash areas. + Use forward error correction (FEC) parity data from the specified device to + try to automatically recover from corruption and I/O errors. - If the encoding data covers additional metadata, it must be accessible - on the hash device after the hash blocks. + If this option is given, then <fec_roots> and <fec_blocks> must also be + given. <hash_block_size> must also be equal to <data_block_size>. - Note: block sizes for data and hash devices must match. Also, if the - verity <dev> is encrypted the <fec_dev> should be too. + <fec_dev> can be the same as <dev>, in which case <fec_start> must be + outside the data area. It can also be the same as <hash_dev>, in which case + <fec_start> must be outside the hash and optional additional metadata areas. + + If the data <dev> is encrypted, the <fec_dev> should be too. + + For more information, see `Forward error correction`_. fec_roots <num> - Number of generator roots. This equals to the number of parity bytes in - the encoding data. For example, in RS(M, N) encoding, the number of roots - is M-N. + The number of parity bytes in each 255-byte Reed-Solomon codeword. The + Reed-Solomon code used will be an RS(255, k) code where k = 255 - fec_roots. + + The supported values are 2 through 24 inclusive. Higher values provide + stronger error correction. However, the minimum value of 2 already provides + strong error correction due to the use of interleaving, so 2 is the + recommended value for most users. fec_roots=2 corresponds to an + RS(255, 253) code, which has a space overhead of about 0.8%. fec_blocks <num> - The number of encoding data blocks on the FEC device. The block size for - the FEC device is <data_block_size>. + The total number of <data_block_size> blocks that are error-checked using + FEC. This must be at least the sum of <num_data_blocks> and the number of + blocks needed by the hash tree. It can include additional metadata blocks, + which are assumed to be accessible on <hash_dev> following the hash blocks. + + Note that this is *not* the number of parity blocks. The number of parity + blocks is inferred from <fec_blocks>, <fec_roots>, and <data_block_size>. fec_start <offset> - This is the offset, in <data_block_size> blocks, from the start of the - FEC device to the beginning of the encoding data. + This is the offset, in <data_block_size> blocks, from the start of <fec_dev> + to the beginning of the parity data. check_at_most_once Verify data blocks only the first time they are read from the data device, @@ -180,11 +193,6 @@ per-block basis. This allows for a lightweight hash computation on first read into the page cache. Block hashes are stored linearly, aligned to the nearest block size. -If forward error correction (FEC) support is enabled any recovery of -corrupted data will be verified using the cryptographic hash of the -corresponding data. This is why combining error correction with -integrity checking is essential. - Hash Tree --------- @@ -212,6 +220,80 @@ The tree looks something like: / ... \ / . . . \ / \ blk_0 ... blk_127 blk_16256 blk_16383 blk_32640 . . . blk_32767 +Forward error correction +------------------------ + +dm-verity's optional forward error correction (FEC) support adds strong error +correction capabilities to dm-verity. It allows systems that would be rendered +inoperable by errors to continue operating, albeit with reduced performance. + +FEC uses Reed-Solomon (RS) codes that are interleaved across the entire +device(s), allowing long bursts of corrupt or unreadable blocks to be recovered. + +dm-verity validates any FEC-corrected block against the wanted hash before using +it. Therefore, FEC doesn't affect the security properties of dm-verity. + +The integration of FEC with dm-verity provides significant benefits over a +separate error correction layer: + +- dm-verity invokes FEC only when a block's hash doesn't match the wanted hash + or the block cannot be read at all. As a result, FEC doesn't add overhead to + the common case where no error occurs. + +- dm-verity hashes are also used to identify erasure locations for RS decoding. + This allows correcting twice as many errors. + +FEC uses an RS(255, k) code where k = 255 - fec_roots. fec_roots is usually 2. +This means that each k (usually 253) message bytes have fec_roots (usually 2) +bytes of parity data added to get a 255-byte codeword. (Many external sources +call RS codewords "blocks". Since dm-verity already uses the term "block" to +mean something else, we'll use the clearer term "RS codeword".) + +FEC checks fec_blocks blocks of message data in total, consisting of: + +1. The data blocks from the data device +2. The hash blocks from the hash device +3. Optional additional metadata that follows the hash blocks on the hash device + +dm-verity assumes that the FEC parity data was computed as if the following +procedure were followed: + +1. Concatenate the message data from the above sources. +2. Zero-pad to the next multiple of k blocks. Let msg be the resulting byte + array, and msglen its length in bytes. +3. For 0 <= i < msglen / k (for each RS codeword): + a. Select msg[i + j * msglen / k] for 0 <= j < k. + Consider these to be the 'k' message bytes of an RS codeword. + b. Compute the corresponding 'fec_roots' parity bytes of the RS codeword, + and concatenate them to the FEC parity data. + +Step 3a interleaves the RS codewords across the entire device using an +interleaving degree of data_block_size * ceil(fec_blocks / k). This is the +maximal interleaving, such that the message data consists of a region containing +byte 0 of all the RS codewords, then a region containing byte 1 of all the RS +codewords, and so on up to the region for byte 'k - 1'. Note that the number of +codewords is set to a multiple of data_block_size; thus, the regions are +block-aligned, and there is an implicit zero padding of up to 'k - 1' blocks. + +This interleaving allows long bursts of errors to be corrected. It provides +much stronger error correction than storage devices typically provide, while +keeping the space overhead low. + +The cost is slow decoding: correcting a single block usually requires reading +254 extra blocks spread evenly across the device(s). However, that is +acceptable because dm-verity uses FEC only when there is actually an error. + +The list below contains additional details about the RS codes used by +dm-verity's FEC. Userspace programs that generate the parity data need to use +these parameters for the parity data to match exactly: + +- Field used is GF(256) +- Bytes are mapped to/from GF(256) elements in the natural way, where bits 0 + through 7 (low-order to high-order) map to the coefficients of x^0 through x^7 +- Field generator polynomial is x^8 + x^4 + x^3 + x^2 + 1 +- The codes used are systematic, BCH-view codes +- Primitive element alpha is 'x' +- First consecutive root of code generator polynomial is 'x^0' On-disk format ============== diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index b734f8a2a2c4..cd28dfe91b06 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -94,6 +94,7 @@ likely to be of interest on almost any system. cgroup-v2 cgroup-v1/index + cpu-isolation cpu-load mm/index module-signing diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 404a15f6782c..7663c610fe90 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -141,7 +141,7 @@ nodemask_t The size of a nodemask_t type. Used to compute the number of online nodes. -(page, flags|_refcount|mapping|lru|_mapcount|private|compound_order|compound_head) +(page, flags|_refcount|mapping|lru|_mapcount|private|compound_order|compound_info) ---------------------------------------------------------------------------------- User-space tools compute their values based on the offset of these diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 03a550630644..cf3807641d89 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -190,6 +190,14 @@ Kernel parameters unusable. The "log_buf_len" parameter may be useful if you need to capture more output. + acpi.poweroff_on_fatal= [ACPI] + {0 | 1} + Causes the system to poweroff when the ACPI bytecode signals + a fatal error. The default value of this setting is 1. + Overriding this value should only be done for diagnosing + ACPI firmware problems, as the system might behave erratically + after having encountered a fatal ACPI error. + acpi_enforce_resources= [ACPI] { strict | lax | no } Check for resource conflicts between native drivers @@ -493,6 +501,13 @@ Kernel parameters disable Disable amd-pstate preferred core. + amd_dynamic_epp= + [X86] + disable + Disable amd-pstate dynamic EPP. + enable + Enable amd-pstate dynamic EPP. + amijoy.map= [HW,JOY] Amiga joystick support Map of devices attached to JOY0DAT and JOY1DAT Format: <a>,<b> @@ -1750,8 +1765,8 @@ Kernel parameters fred= [X86-64] Enable/disable Flexible Return and Event Delivery. Format: { on | off } - on: enable FRED when it's present. - off: disable FRED, the default setting. + on: enable FRED when it's present, the default setting. + off: disable FRED. ftrace=[tracer] [FTRACE] will set and start the specified tracer @@ -2395,23 +2410,6 @@ Kernel parameters [IMA] Define a custom template format. Format: { "field1|...|fieldN" } - ima.ahash_minsize= [IMA] Minimum file size for asynchronous hash usage - Format: <min_file_size> - Set the minimal file size for using asynchronous hash. - If left unspecified, ahash usage is disabled. - - ahash performance varies for different data sizes on - different crypto accelerators. This option can be used - to achieve the best performance for a particular HW. - - ima.ahash_bufsize= [IMA] Asynchronous hash buffer size - Format: <bufsize> - Set hashing buffer size. Default: 4k. - - ahash performance varies for different chunk sizes on - different crypto accelerators. This option can be used - to achieve best performance for particular HW. - ima= [IMA] Enable or disable IMA Format: { "off" | "on" } Default: "on" @@ -2615,15 +2613,11 @@ Kernel parameters Intel machines). This can be used to prevent the usage of an available hardware IOMMU. - [X86] pt - [X86] nopt - [PPC/POWERNV] - nobypass + nobypass [PPC/POWERNV] Disable IOMMU bypass, using IOMMU for PCI devices. - [X86] AMD Gart HW IOMMU-specific options: <size> @@ -2959,6 +2953,12 @@ Kernel parameters Format: <bool> Default: CONFIG_KFENCE_DEFERRABLE + kfence.fault= [MM,KFENCE] Controls the behavior when a KFENCE + error is detected. + report - print the error report and continue (default). + oops - print the error report and oops. + panic - print the error report and panic. + kfence.sample_interval= [MM,KFENCE] KFENCE's sample interval in milliseconds. Format: <unsigned integer> @@ -3247,8 +3247,8 @@ Kernel parameters for the host. To force nVHE on VHE hardware, add "arm64_sw.hvhe=0 id_aa64mmfr1.vh=0" to the command-line. - "nested" is experimental and should be used with - extreme caution. + "nested" and "protected" are experimental and should be + used with extreme caution. kvm-arm.vgic_v3_group0_trap= [KVM,ARM,EARLY] Trap guest accesses to GICv3 group-0 @@ -6746,7 +6746,7 @@ Kernel parameters Default is 'on'. initramfs_options= [KNL] - Specify mount options for for the initramfs mount. + Specify mount options for the initramfs mount. rootfstype= [KNL] Set root filesystem type @@ -7963,12 +7963,7 @@ Kernel parameters (HPET or PM timer) on systems whose TSC frequency was obtained from HW or FW using either an MSR or CPUID(0x15). Warn if the difference is more than 500 ppm. - [x86] watchdog: Use TSC as the watchdog clocksource with - which to check other HW timers (HPET or PM timer), but - only on systems where TSC has been deemed trustworthy. - This will be suppressed by an earlier tsc=nowatchdog and - can be overridden by a later tsc=nowatchdog. A console - message will flag any such suppression or overriding. + [x86] watchdog: Enforce the clocksource watchdog on TSC tsc_early_khz= [X86,EARLY] Skip early TSC calibration and use the given value instead. Useful when the early TSC frequency discovery @@ -8392,7 +8387,9 @@ Kernel parameters emulate Vsyscalls turn into traps and are emulated reasonably safely. The vsyscall page is - readable. + readable. This disables the Linear + Address Space Separation (LASS) security + feature and makes the system less secure. xonly [default] Vsyscalls turn into traps and are emulated reasonably safely. The vsyscall @@ -8535,7 +8532,8 @@ Kernel parameters workqueue.default_affinity_scope= Select the default affinity scope to use for unbound workqueues. Can be one of "cpu", "smt", "cache", - "numa" and "system". Default is "cache". For more + "cache_shard", "numa" and "system". Default is + "cache_shard". For more information, see the Affinity Scopes section in Documentation/core-api/workqueue.rst. diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst index 03951ed6b628..f874db31801d 100644 --- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst +++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst @@ -1522,6 +1522,27 @@ Currently 2 antenna types are supported as mentioned below: The property is read-only. If the platform doesn't have support the sysfs class is not created. +doubletap_enable +---------------- + +sysfs: doubletap_enable + +Controls whether TrackPoint doubletap events are filtered out. Doubletap is a +feature where quickly tapping the TrackPoint twice triggers a special function key event. + +The available commands are:: + + cat /sys/devices/platform/thinkpad_acpi/doubletap_enable + echo 1 | sudo tee /sys/devices/platform/thinkpad_acpi/doubletap_enable + echo 0 | sudo tee /sys/devices/platform/thinkpad_acpi/doubletap_enable + +Values: + + * 1 - doubletap events are processed (default) + * 0 - doubletap events are filtered out (ignored) + + This setting can also be toggled via the Fn+doubletap hotkey. + Auxmac ------ diff --git a/Documentation/admin-guide/laptops/uniwill-laptop.rst b/Documentation/admin-guide/laptops/uniwill-laptop.rst index aff5f57a6bd4..561334865feb 100644 --- a/Documentation/admin-guide/laptops/uniwill-laptop.rst +++ b/Documentation/admin-guide/laptops/uniwill-laptop.rst @@ -50,6 +50,10 @@ between 1 and 100 percent are supported. Additionally the driver signals the presence of battery charging issues through the standard ``health`` power supply sysfs attribute. +It also lets you set whether a USB-C power source should prioritise charging the battery or +delivering immediate power to the cpu. See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for +details. + Lightbar -------- @@ -58,3 +62,11 @@ LED class device. The default name of this LED class device is ``uniwill:multico See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details on how to control the various animation modes of the lightbar. + +Configurable TGP +---------------- + +The ``uniwill-laptop`` driver allows to set the configurable TGP for devices with NVIDIA GPUs that +allow it. + +See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details. diff --git a/Documentation/admin-guide/lockup-watchdogs.rst b/Documentation/admin-guide/lockup-watchdogs.rst index 3e09284a8b9b..8f245f4a95b7 100644 --- a/Documentation/admin-guide/lockup-watchdogs.rst +++ b/Documentation/admin-guide/lockup-watchdogs.rst @@ -16,7 +16,7 @@ details), and a compile option, "BOOTPARAM_SOFTLOCKUP_PANIC", are provided for this. A 'hardlockup' is defined as a bug that causes the CPU to loop in -kernel mode for more than 10 seconds (see "Implementation" below for +kernel mode for several seconds (see "Implementation" below for details), without letting other interrupts have a chance to run. Similarly to the softlockup case, the current stack trace is displayed upon detection and the system will stay locked up unless the default @@ -30,39 +30,135 @@ timeout is set through the confusingly named "kernel.panic" sysctl), to cause the system to reboot automatically after a specified amount of time. +Configuration +============= + +A kernel knob is provided that allows administrators to configure +this period. The "watchdog_thresh" parameter (default 10 seconds) +controls the threshold. The right value for a particular environment +is a trade-off between fast response to lockups and detection overhead. + Implementation ============== -The soft and hard lockup detectors are built on top of the hrtimer and -perf subsystems, respectively. A direct consequence of this is that, -in principle, they should work in any architecture where these -subsystems are present. - -A periodic hrtimer runs to generate interrupts and kick the watchdog -job. An NMI perf event is generated every "watchdog_thresh" -(compile-time initialized to 10 and configurable through sysctl of the -same name) seconds to check for hardlockups. If any CPU in the system -does not receive any hrtimer interrupt during that time the -'hardlockup detector' (the handler for the NMI perf event) will -generate a kernel warning or call panic, depending on the -configuration. - -The watchdog job runs in a stop scheduling thread that updates a -timestamp every time it is scheduled. If that timestamp is not updated -for 2*watchdog_thresh seconds (the softlockup threshold) the +The soft and hard lockup detectors are built around an hrtimer. +In addition, the softlockup detector regularly schedules a job, and +the hard lockup detector might use Perf/NMI events on architectures +that support it. + +Frequency and Heartbeats +------------------------ + +The core of the detectors is an hrtimer. It serves multiple purposes: + +- schedules watchdog job for the softlockup detector +- bumps the interrupt counter for hardlockup detectors (heartbeat) +- detects softlockups +- detects hardlockups in Buddy mode + +The period of this hrtimer is 2*watchdog_thresh/5, which is 4 seconds +by default. The hrtimer has two or three chances to generate an interrupt +(heartbeat) before the hardlockup detector kicks in. + +Softlockup Detector +------------------- + +The watchdog job is scheduled by the hrtimer and runs in a stop scheduling +thread. It updates a timestamp every time it is scheduled. If that timestamp +is not updated for 2*watchdog_thresh seconds (the softlockup threshold) the 'softlockup detector' (coded inside the hrtimer callback function) will dump useful debug information to the system log, after which it will call panic if it was instructed to do so or resume execution of other kernel code. -The period of the hrtimer is 2*watchdog_thresh/5, which means it has -two or three chances to generate an interrupt before the hardlockup -detector kicks in. +Hardlockup Detector (NMI/Perf) +------------------------------ + +On architectures that support NMI (Non-Maskable Interrupt) perf events, +a periodic NMI is generated every "watchdog_thresh" seconds. + +If any CPU in the system does not receive any hrtimer interrupt +(heartbeat) during the "watchdog_thresh" window, the 'hardlockup +detector' (the handler for the NMI perf event) will generate a kernel +warning or call panic. + +**Detection Overhead (NMI):** + +The time to detect a lockup can vary depending on when the lockup +occurs relative to the NMI check window. Examples below assume a watchdog_thresh of 10. + +* **Best Case:** The lockup occurs just before the first heartbeat is + due. The detector will notice the missing hrtimer interrupt almost + immediately during the next check. + + :: + + Time 100.0: cpu 1 heartbeat + Time 100.1: hardlockup_check, cpu1 stores its state + Time 103.9: Hard Lockup on cpu1 + Time 104.0: cpu 1 heartbeat never comes + Time 110.1: hardlockup_check, cpu1 checks the state again, should be the same, declares lockup + + Time to detection: ~6 seconds + +* **Worst Case:** The lockup occurs shortly after a valid interrupt + (heartbeat) which itself happened just after the NMI check. The next + NMI check sees that the interrupt count has changed (due to that one + heartbeat), assumes the CPU is healthy, and resets the baseline. The + lockup is only detected at the subsequent check. + + :: + + Time 100.0: hardlockup_check, cpu1 stores its state + Time 100.1: cpu 1 heartbeat + Time 100.2: Hard Lockup on cpu1 + Time 110.0: hardlockup_check, cpu1 stores its state (misses lockup as state changed) + Time 120.0: hardlockup_check, cpu1 checks the state again, should be the same, declares lockup + + Time to detection: ~20 seconds + +Hardlockup Detector (Buddy) +--------------------------- + +On architectures or configurations where NMI perf events are not +available (or disabled), the kernel may use the "buddy" hardlockup +detector. This mechanism requires SMP (Symmetric Multi-Processing). + +In this mode, each CPU is assigned a "buddy" CPU to monitor. The +monitoring CPU runs its own hrtimer (the same one used for softlockup +detection) and checks if the buddy CPU's hrtimer interrupt count has +increased. + +To ensure timeliness and avoid false positives, the buddy system performs +checks at every hrtimer interval (2*watchdog_thresh/5, which is 4 seconds +by default). It uses a missed-interrupt threshold of 3. If the buddy's +interrupt count has not changed for 3 consecutive checks, it is assumed +that the buddy CPU is hardlocked (interrupts disabled). The monitoring +CPU will then trigger the hardlockup response (warning or panic). + +**Detection Overhead (Buddy):** + +With a default check interval of 4 seconds (watchdog_thresh = 10): + +* **Best case:** Lockup occurs just before a check. + Detected in ~8s (0s till 1st check + 4s till 2nd + 4s till 3rd). +* **Worst case:** Lockup occurs just after a check. + Detected in ~12s (4s till 1st check + 4s till 2nd + 4s till 3rd). + +**Limitations of the Buddy Detector:** + +1. **All-CPU Lockup:** If all CPUs lock up simultaneously, the buddy + detector cannot detect the condition because the monitoring CPUs + are also frozen. +2. **Stack Traces:** Unlike the NMI detector, the buddy detector + cannot directly interrupt the locked CPU to grab a stack trace. + It relies on architecture-specific mechanisms (like NMI backtrace + support) to try and retrieve the status of the locked CPU. If + such support is missing, the log may only show that a lockup + occurred without providing the locked CPU's stack. -As explained above, a kernel knob is provided that allows -administrators to configure the period of the hrtimer and the perf -event. The right value for a particular environment is a trade-off -between fast response to lockups and detection overhead. +Watchdog Core Exclusion +======================= By default, the watchdog runs on all online cores. However, on a kernel configured with NO_HZ_FULL, by default the watchdog runs only diff --git a/Documentation/admin-guide/media/mgb4.rst b/Documentation/admin-guide/media/mgb4.rst index 0a8a56e837f7..8e429fd77712 100644 --- a/Documentation/admin-guide/media/mgb4.rst +++ b/Documentation/admin-guide/media/mgb4.rst @@ -74,6 +74,7 @@ Common FPDL3/GMSL input parameters | 0 - OLDI/JEIDA | 1 - SPWG/VESA (default) + | 2 - ZDML **link_status** (R): Video link status. If the link is locked, chips are properly connected and @@ -240,6 +241,13 @@ Common FPDL3/GMSL output parameters *Note: This parameter can not be changed while the output v4l2 device is open.* +**color_mapping** (RW): + Mapping of the outgoing bits in the signal to the colour bits of the pixels. + + | 0 - OLDI/JEIDA + | 1 - SPWG/VESA (default) + | 2 - ZDML + **frame_rate** (RW): Output video signal frame rate limit in frames per second. Due to the limited output pixel clock steps, the card can not always generate diff --git a/Documentation/admin-guide/media/starfive_camss.rst b/Documentation/admin-guide/media/starfive_camss.rst deleted file mode 100644 index ca42e9447c47..000000000000 --- a/Documentation/admin-guide/media/starfive_camss.rst +++ /dev/null @@ -1,72 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -.. include:: <isonum.txt> - -================================ -Starfive Camera Subsystem driver -================================ - -Introduction ------------- - -This file documents the driver for the Starfive Camera Subsystem found on -Starfive JH7110 SoC. The driver is located under drivers/staging/media/starfive/ -camss. - -The driver implements V4L2, Media controller and v4l2_subdev interfaces. Camera -sensor using V4L2 subdev interface in the kernel is supported. - -The driver has been successfully used on the Gstreamer 1.18.5 with v4l2src -plugin. - - -Starfive Camera Subsystem hardware ----------------------------------- - -The Starfive Camera Subsystem hardware consists of:: - - |\ +---------------+ +-----------+ - +----------+ | \ | | | | - | | | | | | | | - | MIPI |----->| |----->| ISP |----->| | - | | | | | | | | - +----------+ | | | | | Memory | - |MUX| +---------------+ | Interface | - +----------+ | | | | - | | | |---------------------------->| | - | Parallel |----->| | | | - | | | | | | - +----------+ | / | | - |/ +-----------+ - -- MIPI: The MIPI interface, receiving data from a MIPI CSI-2 camera sensor. - -- Parallel: The parallel interface, receiving data from a parallel sensor. - -- ISP: The ISP, processing raw Bayer data from an image sensor and producing - YUV frames. - - -Topology --------- - -The media controller pipeline graph is as follows: - -.. _starfive_camss_graph: - -.. kernel-figure:: starfive_camss_graph.dot - :alt: starfive_camss_graph.dot - :align: center - -The driver has 2 video devices: - -- capture_raw: The capture device, capturing image data directly from a sensor. -- capture_yuv: The capture device, capturing YUV frame data processed by the - ISP module - -The driver has 3 subdevices: - -- stf_isp: is responsible for all the isp operations, outputs YUV frames. -- cdns_csi2rx: a CSI-2 bridge supporting up to 4 CSI lanes in input, and 4 - different pixel streams in output. -- imx219: an image sensor, image data is sent through MIPI CSI-2. diff --git a/Documentation/admin-guide/media/starfive_camss_graph.dot b/Documentation/admin-guide/media/starfive_camss_graph.dot deleted file mode 100644 index 8eff1f161ac7..000000000000 --- a/Documentation/admin-guide/media/starfive_camss_graph.dot +++ /dev/null @@ -1,12 +0,0 @@ -digraph board { - rankdir=TB - n00000001 [label="{{<port0> 0} | stf_isp\n/dev/v4l-subdev0 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green] - n00000001:port1 -> n00000008 [style=dashed] - n00000004 [label="capture_raw\n/dev/video0", shape=box, style=filled, fillcolor=yellow] - n00000008 [label="capture_yuv\n/dev/video1", shape=box, style=filled, fillcolor=yellow] - n0000000e [label="{{<port0> 0} | cdns_csi2rx.19800000.csi-bridge\n | {<port1> 1 | <port2> 2 | <port3> 3 | <port4> 4}}", shape=Mrecord, style=filled, fillcolor=green] - n0000000e:port1 -> n00000001:port0 [style=dashed] - n0000000e:port1 -> n00000004 [style=dashed] - n00000018 [label="{{} | imx219 6-0010\n/dev/v4l-subdev1 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green] - n00000018:port0 -> n0000000e:port0 [style=bold] -} diff --git a/Documentation/admin-guide/media/v4l-drivers.rst b/Documentation/admin-guide/media/v4l-drivers.rst index 393f83e8dc4d..d31da8e0a54f 100644 --- a/Documentation/admin-guide/media/v4l-drivers.rst +++ b/Documentation/admin-guide/media/v4l-drivers.rst @@ -33,7 +33,6 @@ Video4Linux (V4L) driver-specific documentation si470x si4713 si476x - starfive_camss vimc visl vivid diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst index 20a8378d5a94..14cc6b2db897 100644 --- a/Documentation/admin-guide/mm/damon/lru_sort.rst +++ b/Documentation/admin-guide/mm/damon/lru_sort.rst @@ -79,6 +79,10 @@ of parametrs except ``enabled`` again. Once the re-reading is done, this parameter is set as ``N``. If invalid parameters are found while the re-reading, DAMON_LRU_SORT will be disabled. +Once ``Y`` is written to this parameter, the user must not write to any +parameters until reading ``commit_inputs`` again returns ``N``. If users +violate this rule, the kernel may exhibit undefined behavior. + active_mem_bp ------------- @@ -91,8 +95,8 @@ increases and decreases the effective level of the quota aiming the LRU Disabled by default. -Auto-tune monitoring intervals ------------------------------- +autotune_monitoring_intervals +----------------------------- If this parameter is set as ``Y``, DAMON_LRU_SORT automatically tunes DAMON's sampling and aggregation intervals. The auto-tuning aims to capture meaningful @@ -221,6 +225,10 @@ But, setting this too high could result in increased monitoring overhead. Please refer to the DAMON documentation (:doc:`usage`) for more detail. 10 by default. +Note that this must be 3 or higher. Please refer to the :ref:`Monitoring +<damon_design_monitoring>` section of the design document for the rationale +behind this lower bound. + max_nr_regions -------------- @@ -351,3 +359,8 @@ the LRU-list based page granularity reclamation. :: # echo 400 > wmarks_mid # echo 200 > wmarks_low # echo Y > enabled + +Note that this module (damon_lru_sort) cannot run simultaneously with other +DAMON-based special-purpose modules. Refer to :ref:`DAMON design special +purpose modules exclusivity <damon_design_special_purpose_modules_exclusivity>` +for more details. diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst index 8eba3da8dcee..d7a0225b4950 100644 --- a/Documentation/admin-guide/mm/damon/reclaim.rst +++ b/Documentation/admin-guide/mm/damon/reclaim.rst @@ -71,6 +71,10 @@ of parametrs except ``enabled`` again. Once the re-reading is done, this parameter is set as ``N``. If invalid parameters are found while the re-reading, DAMON_RECLAIM will be disabled. +Once ``Y`` is written to this parameter, the user must not write to any +parameters until reading ``commit_inputs`` again returns ``N``. If users +violate this rule, the kernel may exhibit undefined behavior. + min_age ------- @@ -204,6 +208,10 @@ monitoring. This can be used to set lower-bound of the monitoring quality. But, setting this too high could result in increased monitoring overhead. Please refer to the DAMON documentation (:doc:`usage`) for more detail. +Note that this must be 3 or higher. Please refer to the :ref:`Monitoring +<damon_design_monitoring>` section of the design document for the rationale +behind this lower bound. + max_nr_regions -------------- @@ -318,6 +326,11 @@ granularity reclamation. :: # echo 200 > wmarks_low # echo Y > enabled +Note that this module (damon_reclaim) cannot run simultaneously with other +DAMON-based special-purpose modules. Refer to :ref:`DAMON design special +purpose modules exclusivity <damon_design_special_purpose_modules_exclusivity>` +for more details. + .. [1] https://research.google/pubs/pub48551/ .. [2] https://lwn.net/Articles/787611/ .. [3] https://www.kernel.org/doc/html/latest/mm/free_page_reporting.html diff --git a/Documentation/admin-guide/mm/damon/stat.rst b/Documentation/admin-guide/mm/damon/stat.rst index e5a5a2c4f803..c4b14daeb2dd 100644 --- a/Documentation/admin-guide/mm/damon/stat.rst +++ b/Documentation/admin-guide/mm/damon/stat.rst @@ -45,6 +45,11 @@ You can enable DAMON_STAT by setting the value of this parameter as ``Y``. Setting it as ``N`` disables DAMON_STAT. The default value is set by ``CONFIG_DAMON_STAT_ENABLED_DEFAULT`` build config option. +Note that this module (damon_stat) cannot run simultaneously with other +DAMON-based special-purpose modules. Refer to :ref:`DAMON design special +purpose modules exclusivity <damon_design_special_purpose_modules_exclusivity>` +for more details. + .. _damon_stat_aggr_interval_us: aggr_interval_us diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index b0f3969b6b3b..534e1199cf09 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -83,7 +83,7 @@ comma (","). │ │ │ │ │ │ │ │ sz/min,max │ │ │ │ │ │ │ │ nr_accesses/min,max │ │ │ │ │ │ │ │ age/min,max - │ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,effective_bytes + │ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,effective_bytes,goal_tuner │ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil │ │ │ │ │ │ │ │ :ref:`goals <sysfs_schemes_quota_goals>`/nr_goals │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid,path @@ -377,9 +377,9 @@ schemes/<N>/quotas/ The directory for the :ref:`quotas <damon_design_damos_quotas>` of the given DAMON-based operation scheme. -Under ``quotas`` directory, four files (``ms``, ``bytes``, -``reset_interval_ms``, ``effective_bytes``) and two directories (``weights`` and -``goals``) exist. +Under ``quotas`` directory, five files (``ms``, ``bytes``, +``reset_interval_ms``, ``effective_bytes`` and ``goal_tuner``) and two +directories (``weights`` and ``goals``) exist. You can set the ``time quota`` in milliseconds, ``size quota`` in bytes, and ``reset interval`` in milliseconds by writing the values to the three files, @@ -390,6 +390,14 @@ apply the action to only up to ``bytes`` bytes of memory regions within the quota limits unless at least one :ref:`goal <sysfs_schemes_quota_goals>` is set. +You can set the goal-based effective quota auto-tuning algorithm to use, by +writing the algorithm name to ``goal_tuner`` file. Reading the file returns +the currently selected tuner algorithm. Refer to the design documentation of +:ref:`automatic quota tuning goals <damon_design_damos_quotas_auto_tuning>` for +the background design of the feature and the name of the selectable algorithms. +Refer to :ref:`goals directory <sysfs_schemes_quota_goals>` for the goals +setup. + The time quota is internally transformed to a size quota. Between the transformed size quota and user-specified size quota, smaller one is applied. Based on the user-specified :ref:`goal <sysfs_schemes_quota_goals>`, the diff --git a/Documentation/admin-guide/mm/kho.rst b/Documentation/admin-guide/mm/kho.rst index 6dc18ed4b886..2c26e560bd78 100644 --- a/Documentation/admin-guide/mm/kho.rst +++ b/Documentation/admin-guide/mm/kho.rst @@ -28,20 +28,10 @@ per NUMA node scratch regions on boot. Perform a KHO kexec =================== -First, before you perform a KHO kexec, you need to move the system into -the :ref:`KHO finalization phase <kho-finalization-phase>` :: - - $ echo 1 > /sys/kernel/debug/kho/out/finalize - -After this command, the KHO FDT is available in -``/sys/kernel/debug/kho/out/fdt``. Other subsystems may also register -their own preserved sub FDTs under -``/sys/kernel/debug/kho/out/sub_fdts/``. - -Next, load the target payload and kexec into it. It is important that you -use the ``-s`` parameter to use the in-kernel kexec file loader, as user -space kexec tooling currently has no support for KHO with the user space -based file loader :: +To perform a KHO kexec, load the target payload and kexec into it. It +is important that you use the ``-s`` parameter to use the in-kernel +kexec file loader, as user space kexec tooling currently has no +support for KHO with the user space based file loader :: # kexec -l /path/to/bzImage --initrd /path/to/initrd -s # kexec -e @@ -52,40 +42,58 @@ For example, if you used ``reserve_mem`` command line parameter to create an early memory reservation, the new kernel will have that memory at the same physical address as the old kernel. -Abort a KHO exec -================ +Kexec Metadata +============== + +KHO automatically tracks metadata about the kexec chain, passing information +about the previous kernel to the next kernel. This feature helps diagnose +bugs that only reproduce when kexecing from specific kernel versions. + +On each KHO kexec, the kernel logs the previous kernel's version and the +number of kexec reboots since the last cold boot:: + + [ 0.000000] KHO: exec from: 6.19.0-rc4-next-20260107 (count 1) + +The metadata includes: -You can move the system out of KHO finalization phase again by calling :: +``previous_release`` + The kernel version string (from ``uname -r``) of the kernel that + initiated the kexec. - $ echo 0 > /sys/kernel/debug/kho/out/active +``kexec_count`` + The number of kexec boots since the last cold boot. On cold boot, + this counter starts at 0 and increments with each kexec. This helps + identify issues that only manifest after multiple consecutive kexec + reboots. -After this command, the KHO FDT is no longer available in -``/sys/kernel/debug/kho/out/fdt``. +Use Cases +--------- + +This metadata is particularly useful for debugging kexec transition bugs, +where a buggy kernel kexecs into a new kernel and the bug manifests only +in the second kernel. Examples of such bugs include: + +- Memory corruption from the previous kernel affecting the new kernel +- Incorrect hardware state left by the previous kernel +- Firmware/ACPI state issues that only appear in kexec scenarios + +At scale, correlating crashes to the previous kernel version enables +faster root cause analysis when issues only occur in specific kernel +transition scenarios. debugfs Interfaces ================== +These debugfs interfaces are available when the kernel is compiled with +``CONFIG_KEXEC_HANDOVER_DEBUGFS`` enabled. + Currently KHO creates the following debugfs interfaces. Notice that these interfaces may change in the future. They will be moved to sysfs once KHO is stabilized. -``/sys/kernel/debug/kho/out/finalize`` - Kexec HandOver (KHO) allows Linux to transition the state of - compatible drivers into the next kexec'ed kernel. To do so, - device drivers will instruct KHO to preserve memory regions, - which could contain serialized kernel state. - While the state is serialized, they are unable to perform - any modifications to state that was serialized, such as - handed over memory allocations. - - When this file contains "1", the system is in the transition - state. When contains "0", it is not. To switch between the - two states, echo the respective number into this file. - ``/sys/kernel/debug/kho/out/fdt`` - When KHO state tree is finalized, the kernel exposes the - flattened device tree blob that carries its current KHO - state in this file. Kexec user space tooling can use this + The kernel exposes the flattened device tree blob that carries its + current KHO state in this file. Kexec user space tooling can use this as input file for the KHO payload image. ``/sys/kernel/debug/kho/out/scratch_len`` @@ -100,8 +108,8 @@ stabilized. it should place its payload images. ``/sys/kernel/debug/kho/out/sub_fdts/`` - In the KHO finalization phase, KHO producers register their own - FDT blob under this directory. + KHO producers can register their own FDT or another binary blob under + this directory. ``/sys/kernel/debug/kho/in/fdt`` When the kernel was booted with Kexec HandOver (KHO), @@ -111,5 +119,5 @@ stabilized. it finished to interpret their metadata. ``/sys/kernel/debug/kho/in/sub_fdts/`` - Similar to ``kho/out/sub_fdts/``, but contains sub FDT blobs + Similar to ``kho/out/sub_fdts/``, but contains sub blobs of KHO producers passed from the old kernel. diff --git a/Documentation/admin-guide/mm/numa_memory_policy.rst b/Documentation/admin-guide/mm/numa_memory_policy.rst index a70f20ce1ffb..90ab26e805a9 100644 --- a/Documentation/admin-guide/mm/numa_memory_policy.rst +++ b/Documentation/admin-guide/mm/numa_memory_policy.rst @@ -217,7 +217,7 @@ MPOL_PREFERRED the MPOL_F_STATIC_NODES or MPOL_F_RELATIVE_NODES flags described below. -MPOL_INTERLEAVED +MPOL_INTERLEAVE This mode specifies that page allocations be interleaved, on a page granularity, across the nodes specified in the policy. This mode also behaves slightly differently, based on the diff --git a/Documentation/admin-guide/nfs/pnfs-block-server.rst b/Documentation/admin-guide/nfs/pnfs-block-server.rst index 20fe9f5117fe..7667dd2e17f1 100644 --- a/Documentation/admin-guide/nfs/pnfs-block-server.rst +++ b/Documentation/admin-guide/nfs/pnfs-block-server.rst @@ -40,3 +40,33 @@ how to translate the device into a serial number from SCSI EVPD 0x80:: echo "fencing client ${CLIENT} serial ${EVPD}" >> /var/log/pnfsd-fence.log EOF + +If the nfsd server needs to fence a non-responding client and the +fencing operation fails, the server logs a warning message in the +system log with the following format: + + FENCE failed client[IP_address] clid[#n] device[dev_name] + + where: + + - IP_address: refers to the IP address of the affected client. + - #n: indicates the unique client identifier. + - dev_name: specifies the name of the block device related + to the fencing attempt. + +The server will repeatedly retry the operation indefinitely. During +this time, access to the affected file is restricted for all other +clients. This is to prevent potential data corruption if multiple +clients access the same file simultaneously. + +To restore access to the affected file for other clients, the admin +needs to take the following actions: + + - shutdown or power off the client being fenced. + - manually expire the client to release all its state on the server:: + + echo 'expire' > /proc/fs/nfsd/clients/clid/ctl + + where: + + - clid: is the unique client identifier displayed in the system log. diff --git a/Documentation/admin-guide/nfs/pnfs-scsi-server.rst b/Documentation/admin-guide/nfs/pnfs-scsi-server.rst index b2eec2288329..b202508d281d 100644 --- a/Documentation/admin-guide/nfs/pnfs-scsi-server.rst +++ b/Documentation/admin-guide/nfs/pnfs-scsi-server.rst @@ -22,3 +22,34 @@ option and the underlying SCSI device support persistent reservations. On the client make sure the kernel has the CONFIG_PNFS_BLOCK option enabled, and the file system is mounted using the NFSv4.1 protocol version (mount -o vers=4.1). + +If the nfsd server needs to fence a non-responding client and the +fencing operation fails, the server logs a warning message in the +system log with the following format: + + FENCE failed client[IP_address] clid[#n] device[dev_name] + + where: + + - IP_address: refers to the IP address of the affected client. + - #n: indicates the unique client identifier. + - dev_name: specifies the name of the block device related + to the fencing attempt. + +The server will repeatedly retry the operation indefinitely. During +this time, access to the affected file is restricted for all other +clients. This is to prevent potential data corruption if multiple +clients access the same file simultaneously. + +To restore access to the affected file for other clients, the admin +needs to take the following actions: + + - shutdown or power off the client being fenced. + - manually expire the client to release all its state on the server:: + + echo 'expire' > /proc/fs/nfsd/clients/clid/ctl + + where: + + - clid: is the unique client identifier displayed in the system log. + diff --git a/Documentation/admin-guide/perf/index.rst b/Documentation/admin-guide/perf/index.rst index 47d9a3df6329..aa12708ddb96 100644 --- a/Documentation/admin-guide/perf/index.rst +++ b/Documentation/admin-guide/perf/index.rst @@ -24,7 +24,8 @@ Performance monitor support thunderx2-pmu alibaba_pmu dwc_pcie_pmu - nvidia-pmu + nvidia-tegra241-pmu + nvidia-tegra410-pmu meson-ddr-pmu cxl ampere_cspmu diff --git a/Documentation/admin-guide/perf/nvidia-pmu.rst b/Documentation/admin-guide/perf/nvidia-tegra241-pmu.rst index f538ef67e0e8..fad5bc4cee6c 100644 --- a/Documentation/admin-guide/perf/nvidia-pmu.rst +++ b/Documentation/admin-guide/perf/nvidia-tegra241-pmu.rst @@ -1,8 +1,8 @@ -========================================================= -NVIDIA Tegra SoC Uncore Performance Monitoring Unit (PMU) -========================================================= +============================================================ +NVIDIA Tegra241 SoC Uncore Performance Monitoring Unit (PMU) +============================================================ -The NVIDIA Tegra SoC includes various system PMUs to measure key performance +The NVIDIA Tegra241 SoC includes various system PMUs to measure key performance metrics like memory bandwidth, latency, and utilization: * Scalable Coherency Fabric (SCF) diff --git a/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst new file mode 100644 index 000000000000..0656223b61d4 --- /dev/null +++ b/Documentation/admin-guide/perf/nvidia-tegra410-pmu.rst @@ -0,0 +1,522 @@ +===================================================================== +NVIDIA Tegra410 SoC Uncore Performance Monitoring Unit (PMU) +===================================================================== + +The NVIDIA Tegra410 SoC includes various system PMUs to measure key performance +metrics like memory bandwidth, latency, and utilization: + +* Unified Coherence Fabric (UCF) +* PCIE +* PCIE-TGT +* CPU Memory (CMEM) Latency +* NVLink-C2C +* NV-CLink +* NV-DLink + +PMU Driver +---------- + +The PMU driver describes the available events and configuration of each PMU in +sysfs. Please see the sections below to get the sysfs path of each PMU. Like +other uncore PMU drivers, the driver provides "cpumask" sysfs attribute to show +the CPU id used to handle the PMU event. There is also "associated_cpus" +sysfs attribute, which contains a list of CPUs associated with the PMU instance. + +UCF PMU +------- + +The Unified Coherence Fabric (UCF) in the NVIDIA Tegra410 SoC serves as a +distributed cache, last level for CPU Memory and CXL Memory, and cache coherent +interconnect that supports hardware coherence across multiple coherently caching +agents, including: + + * CPU clusters + * GPU + * PCIe Ordering Controller Unit (OCU) + * Other IO-coherent requesters + +The events and configuration options of this PMU device are described in sysfs, +see /sys/bus/event_source/devices/nvidia_ucf_pmu_<socket-id>. + +Some of the events available in this PMU can be used to measure bandwidth and +utilization: + + * slc_access_rd: count the number of read requests to SLC. + * slc_access_wr: count the number of write requests to SLC. + * slc_bytes_rd: count the number of bytes transferred by slc_access_rd. + * slc_bytes_wr: count the number of bytes transferred by slc_access_wr. + * mem_access_rd: count the number of read requests to local or remote memory. + * mem_access_wr: count the number of write requests to local or remote memory. + * mem_bytes_rd: count the number of bytes transferred by mem_access_rd. + * mem_bytes_wr: count the number of bytes transferred by mem_access_wr. + * cycles: counts the UCF cycles. + +The average bandwidth is calculated as:: + + AVG_SLC_READ_BANDWIDTH_IN_GBPS = SLC_BYTES_RD / ELAPSED_TIME_IN_NS + AVG_SLC_WRITE_BANDWIDTH_IN_GBPS = SLC_BYTES_WR / ELAPSED_TIME_IN_NS + AVG_MEM_READ_BANDWIDTH_IN_GBPS = MEM_BYTES_RD / ELAPSED_TIME_IN_NS + AVG_MEM_WRITE_BANDWIDTH_IN_GBPS = MEM_BYTES_WR / ELAPSED_TIME_IN_NS + +The average request rate is calculated as:: + + AVG_SLC_READ_REQUEST_RATE = SLC_ACCESS_RD / CYCLES + AVG_SLC_WRITE_REQUEST_RATE = SLC_ACCESS_WR / CYCLES + AVG_MEM_READ_REQUEST_RATE = MEM_ACCESS_RD / CYCLES + AVG_MEM_WRITE_REQUEST_RATE = MEM_ACCESS_WR / CYCLES + +More details about what other events are available can be found in Tegra410 SoC +technical reference manual. + +The events can be filtered based on source or destination. The source filter +indicates the traffic initiator to the SLC, e.g local CPU, non-CPU device, or +remote socket. The destination filter specifies the destination memory type, +e.g. local system memory (CMEM), local GPU memory (GMEM), or remote memory. The +local/remote classification of the destination filter is based on the home +socket of the address, not where the data actually resides. The available +filters are described in +/sys/bus/event_source/devices/nvidia_ucf_pmu_<socket-id>/format/. + +The list of UCF PMU event filters: + +* Source filter: + + * src_loc_cpu: if set, count events from local CPU + * src_loc_noncpu: if set, count events from local non-CPU device + * src_rem: if set, count events from CPU, GPU, PCIE devices of remote socket + +* Destination filter: + + * dst_loc_cmem: if set, count events to local system memory (CMEM) address + * dst_loc_gmem: if set, count events to local GPU memory (GMEM) address + * dst_loc_other: if set, count events to local CXL memory address + * dst_rem: if set, count events to CPU, GPU, and CXL memory address of remote socket + +If the source is not specified, the PMU will count events from all sources. If +the destination is not specified, the PMU will count events to all destinations. + +Example usage: + +* Count event id 0x0 in socket 0 from all sources and to all destinations:: + + perf stat -a -e nvidia_ucf_pmu_0/event=0x0/ + +* Count event id 0x0 in socket 0 with source filter = local CPU and destination + filter = local system memory (CMEM):: + + perf stat -a -e nvidia_ucf_pmu_0/event=0x0,src_loc_cpu=0x1,dst_loc_cmem=0x1/ + +* Count event id 0x0 in socket 1 with source filter = local non-CPU device and + destination filter = remote memory:: + + perf stat -a -e nvidia_ucf_pmu_1/event=0x0,src_loc_noncpu=0x1,dst_rem=0x1/ + +PCIE PMU +-------- + +This PMU is located in the SOC fabric connecting the PCIE root complex (RC) and +the memory subsystem. It monitors all read/write traffic from the root port(s) +or a particular BDF in a PCIE RC to local or remote memory. There is one PMU per +PCIE RC in the SoC. Each RC can have up to 16 lanes that can be bifurcated into +up to 8 root ports. The traffic from each root port can be filtered using RP or +BDF filter. For example, specifying "src_rp_mask=0xFF" means the PMU counter will +capture traffic from all RPs. Please see below for more details. + +The events and configuration options of this PMU device are described in sysfs, +see /sys/bus/event_source/devices/nvidia_pcie_pmu_<socket-id>_rc_<pcie-rc-id>. + +The events in this PMU can be used to measure bandwidth, utilization, and +latency: + + * rd_req: count the number of read requests by PCIE device. + * wr_req: count the number of write requests by PCIE device. + * rd_bytes: count the number of bytes transferred by rd_req. + * wr_bytes: count the number of bytes transferred by wr_req. + * rd_cum_outs: count outstanding rd_req each cycle. + * cycles: count the clock cycles of SOC fabric connected to the PCIE interface. + +The average bandwidth is calculated as:: + + AVG_RD_BANDWIDTH_IN_GBPS = RD_BYTES / ELAPSED_TIME_IN_NS + AVG_WR_BANDWIDTH_IN_GBPS = WR_BYTES / ELAPSED_TIME_IN_NS + +The average request rate is calculated as:: + + AVG_RD_REQUEST_RATE = RD_REQ / CYCLES + AVG_WR_REQUEST_RATE = WR_REQ / CYCLES + + +The average latency is calculated as:: + + FREQ_IN_GHZ = CYCLES / ELAPSED_TIME_IN_NS + AVG_LATENCY_IN_CYCLES = RD_CUM_OUTS / RD_REQ + AVERAGE_LATENCY_IN_NS = AVG_LATENCY_IN_CYCLES / FREQ_IN_GHZ + +The PMU events can be filtered based on the traffic source and destination. +The source filter indicates the PCIE devices that will be monitored. The +destination filter specifies the destination memory type, e.g. local system +memory (CMEM), local GPU memory (GMEM), or remote memory. The local/remote +classification of the destination filter is based on the home socket of the +address, not where the data actually resides. These filters can be found in +/sys/bus/event_source/devices/nvidia_pcie_pmu_<socket-id>_rc_<pcie-rc-id>/format/. + +The list of event filters: + +* Source filter: + + * src_rp_mask: bitmask of root ports that will be monitored. Each bit in this + bitmask represents the RP index in the RC. If the bit is set, all devices under + the associated RP will be monitored. E.g "src_rp_mask=0xF" will monitor + devices in root port 0 to 3. + * src_bdf: the BDF that will be monitored. This is a 16-bit value that + follows formula: (bus << 8) + (device << 3) + (function). For example, the + value of BDF 27:01.1 is 0x2781. + * src_bdf_en: enable the BDF filter. If this is set, the BDF filter value in + "src_bdf" is used to filter the traffic. + + Note that Root-Port and BDF filters are mutually exclusive and the PMU in + each RC can only have one BDF filter for the whole counters. If BDF filter + is enabled, the BDF filter value will be applied to all events. + +* Destination filter: + + * dst_loc_cmem: if set, count events to local system memory (CMEM) address + * dst_loc_gmem: if set, count events to local GPU memory (GMEM) address + * dst_loc_pcie_p2p: if set, count events to local PCIE peer address + * dst_loc_pcie_cxl: if set, count events to local CXL memory address + * dst_rem: if set, count events to remote memory address + +If the source filter is not specified, the PMU will count events from all root +ports. If the destination filter is not specified, the PMU will count events +to all destinations. + +Example usage: + +* Count event id 0x0 from root port 0 of PCIE RC-0 on socket 0 targeting all + destinations:: + + perf stat -a -e nvidia_pcie_pmu_0_rc_0/event=0x0,src_rp_mask=0x1/ + +* Count event id 0x1 from root port 0 and 1 of PCIE RC-1 on socket 0 and + targeting just local CMEM of socket 0:: + + perf stat -a -e nvidia_pcie_pmu_0_rc_1/event=0x1,src_rp_mask=0x3,dst_loc_cmem=0x1/ + +* Count event id 0x2 from root port 0 of PCIE RC-2 on socket 1 targeting all + destinations:: + + perf stat -a -e nvidia_pcie_pmu_1_rc_2/event=0x2,src_rp_mask=0x1/ + +* Count event id 0x3 from root port 0 and 1 of PCIE RC-3 on socket 1 and + targeting just local CMEM of socket 1:: + + perf stat -a -e nvidia_pcie_pmu_1_rc_3/event=0x3,src_rp_mask=0x3,dst_loc_cmem=0x1/ + +* Count event id 0x4 from BDF 01:01.0 of PCIE RC-4 on socket 0 targeting all + destinations:: + + perf stat -a -e nvidia_pcie_pmu_0_rc_4/event=0x4,src_bdf=0x0180,src_bdf_en=0x1/ + +.. _NVIDIA_T410_PCIE_PMU_RC_Mapping_Section: + +Mapping the RC# to lspci segment number +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Mapping the RC# to lspci segment number can be non-trivial; hence a new NVIDIA +Designated Vendor Specific Capability (DVSEC) register is added into the PCIE config space +for each RP. This DVSEC has vendor id "10de" and DVSEC id of "0x4". The DVSEC register +contains the following information to map PCIE devices under the RP back to its RC# : + + - Bus# (byte 0xc) : bus number as reported by the lspci output + - Segment# (byte 0xd) : segment number as reported by the lspci output + - RP# (byte 0xe) : port number as reported by LnkCap attribute from lspci for a device with Root Port capability + - RC# (byte 0xf): root complex number associated with the RP + - Socket# (byte 0x10): socket number associated with the RP + +Example script for mapping lspci BDF to RC# and socket#:: + + #!/bin/bash + while read bdf rest; do + dvsec4_reg=$(lspci -vv -s $bdf | awk ' + /Designated Vendor-Specific: Vendor=10de ID=0004/ { + match($0, /\[([0-9a-fA-F]+)/, arr); + print "0x" arr[1]; + exit + } + ') + if [ -n "$dvsec4_reg" ]; then + bus=$(setpci -s $bdf $(printf '0x%x' $((${dvsec4_reg} + 0xc))).b) + segment=$(setpci -s $bdf $(printf '0x%x' $((${dvsec4_reg} + 0xd))).b) + rp=$(setpci -s $bdf $(printf '0x%x' $((${dvsec4_reg} + 0xe))).b) + rc=$(setpci -s $bdf $(printf '0x%x' $((${dvsec4_reg} + 0xf))).b) + socket=$(setpci -s $bdf $(printf '0x%x' $((${dvsec4_reg} + 0x10))).b) + echo "$bdf: Bus=$bus, Segment=$segment, RP=$rp, RC=$rc, Socket=$socket" + fi + done < <(lspci -d 10de:) + +Example output:: + + 0001:00:00.0: Bus=00, Segment=01, RP=00, RC=00, Socket=00 + 0002:80:00.0: Bus=80, Segment=02, RP=01, RC=01, Socket=00 + 0002:a0:00.0: Bus=a0, Segment=02, RP=02, RC=01, Socket=00 + 0002:c0:00.0: Bus=c0, Segment=02, RP=03, RC=01, Socket=00 + 0002:e0:00.0: Bus=e0, Segment=02, RP=04, RC=01, Socket=00 + 0003:00:00.0: Bus=00, Segment=03, RP=00, RC=02, Socket=00 + 0004:00:00.0: Bus=00, Segment=04, RP=00, RC=03, Socket=00 + 0005:00:00.0: Bus=00, Segment=05, RP=00, RC=04, Socket=00 + 0005:40:00.0: Bus=40, Segment=05, RP=01, RC=04, Socket=00 + 0005:c0:00.0: Bus=c0, Segment=05, RP=02, RC=04, Socket=00 + 0006:00:00.0: Bus=00, Segment=06, RP=00, RC=05, Socket=00 + 0009:00:00.0: Bus=00, Segment=09, RP=00, RC=00, Socket=01 + 000a:80:00.0: Bus=80, Segment=0a, RP=01, RC=01, Socket=01 + 000a:a0:00.0: Bus=a0, Segment=0a, RP=02, RC=01, Socket=01 + 000a:e0:00.0: Bus=e0, Segment=0a, RP=03, RC=01, Socket=01 + 000b:00:00.0: Bus=00, Segment=0b, RP=00, RC=02, Socket=01 + 000c:00:00.0: Bus=00, Segment=0c, RP=00, RC=03, Socket=01 + 000d:00:00.0: Bus=00, Segment=0d, RP=00, RC=04, Socket=01 + 000d:40:00.0: Bus=40, Segment=0d, RP=01, RC=04, Socket=01 + 000d:c0:00.0: Bus=c0, Segment=0d, RP=02, RC=04, Socket=01 + 000e:00:00.0: Bus=00, Segment=0e, RP=00, RC=05, Socket=01 + +PCIE-TGT PMU +------------ + +This PMU is located in the SOC fabric connecting the PCIE root complex (RC) and +the memory subsystem. It monitors traffic targeting PCIE BAR and CXL HDM ranges. +There is one PCIE-TGT PMU per PCIE RC in the SoC. Each RC in Tegra410 SoC can +have up to 16 lanes that can be bifurcated into up to 8 root ports (RP). The PMU +provides RP filter to count PCIE BAR traffic to each RP and address filter to +count access to PCIE BAR or CXL HDM ranges. The details of the filters are +described in the following sections. + +Mapping the RC# to lspci segment number is similar to the PCIE PMU. Please see +:ref:`NVIDIA_T410_PCIE_PMU_RC_Mapping_Section` for more info. + +The events and configuration options of this PMU device are available in sysfs, +see /sys/bus/event_source/devices/nvidia_pcie_tgt_pmu_<socket-id>_rc_<pcie-rc-id>. + +The events in this PMU can be used to measure bandwidth and utilization: + + * rd_req: count the number of read requests to PCIE. + * wr_req: count the number of write requests to PCIE. + * rd_bytes: count the number of bytes transferred by rd_req. + * wr_bytes: count the number of bytes transferred by wr_req. + * cycles: count the clock cycles of SOC fabric connected to the PCIE interface. + +The average bandwidth is calculated as:: + + AVG_RD_BANDWIDTH_IN_GBPS = RD_BYTES / ELAPSED_TIME_IN_NS + AVG_WR_BANDWIDTH_IN_GBPS = WR_BYTES / ELAPSED_TIME_IN_NS + +The average request rate is calculated as:: + + AVG_RD_REQUEST_RATE = RD_REQ / CYCLES + AVG_WR_REQUEST_RATE = WR_REQ / CYCLES + +The PMU events can be filtered based on the destination root port or target +address range. Filtering based on RP is only available for PCIE BAR traffic. +Address filter works for both PCIE BAR and CXL HDM ranges. These filters can be +found in sysfs, see +/sys/bus/event_source/devices/nvidia_pcie_tgt_pmu_<socket-id>_rc_<pcie-rc-id>/format/. + +Destination filter settings: + +* dst_rp_mask: bitmask to select the root port(s) to monitor. E.g. "dst_rp_mask=0xFF" + corresponds to all root ports (from 0 to 7) in the PCIE RC. Note that this filter is + only available for PCIE BAR traffic. +* dst_addr_base: BAR or CXL HDM filter base address. +* dst_addr_mask: BAR or CXL HDM filter address mask. +* dst_addr_en: enable BAR or CXL HDM address range filter. If this is set, the + address range specified by "dst_addr_base" and "dst_addr_mask" will be used to filter + the PCIE BAR and CXL HDM traffic address. The PMU uses the following comparison + to determine if the traffic destination address falls within the filter range:: + + (txn's addr & dst_addr_mask) == (dst_addr_base & dst_addr_mask) + + If the comparison succeeds, then the event will be counted. + +If the destination filter is not specified, the RP filter will be configured by default +to count PCIE BAR traffic to all root ports. + +Example usage: + +* Count event id 0x0 to root port 0 and 1 of PCIE RC-0 on socket 0:: + + perf stat -a -e nvidia_pcie_tgt_pmu_0_rc_0/event=0x0,dst_rp_mask=0x3/ + +* Count event id 0x1 for accesses to PCIE BAR or CXL HDM address range + 0x10000 to 0x100FF on socket 0's PCIE RC-1:: + + perf stat -a -e nvidia_pcie_tgt_pmu_0_rc_1/event=0x1,dst_addr_base=0x10000,dst_addr_mask=0xFFF00,dst_addr_en=0x1/ + +CPU Memory (CMEM) Latency PMU +----------------------------- + +This PMU monitors latency events of memory read requests from the edge of the +Unified Coherence Fabric (UCF) to local CPU DRAM: + + * RD_REQ counters: count read requests (32B per request). + * RD_CUM_OUTS counters: accumulated outstanding request counter, which track + how many cycles the read requests are in flight. + * CYCLES counter: counts the number of elapsed cycles. + +The average latency is calculated as:: + + FREQ_IN_GHZ = CYCLES / ELAPSED_TIME_IN_NS + AVG_LATENCY_IN_CYCLES = RD_CUM_OUTS / RD_REQ + AVERAGE_LATENCY_IN_NS = AVG_LATENCY_IN_CYCLES / FREQ_IN_GHZ + +The events and configuration options of this PMU device are described in sysfs, +see /sys/bus/event_source/devices/nvidia_cmem_latency_pmu_<socket-id>. + +Example usage:: + + perf stat -a -e '{nvidia_cmem_latency_pmu_0/rd_req/,nvidia_cmem_latency_pmu_0/rd_cum_outs/,nvidia_cmem_latency_pmu_0/cycles/}' + +NVLink-C2C PMU +-------------- + +This PMU monitors latency events of memory read/write requests that pass through +the NVIDIA Chip-to-Chip (C2C) interface. Bandwidth events are not available +in this PMU, unlike the C2C PMU in Grace (Tegra241 SoC). + +The events and configuration options of this PMU device are available in sysfs, +see /sys/bus/event_source/devices/nvidia_nvlink_c2c_pmu_<socket-id>. + +The list of events: + + * IN_RD_CUM_OUTS: accumulated outstanding request (in cycles) of incoming read requests. + * IN_RD_REQ: the number of incoming read requests. + * IN_WR_CUM_OUTS: accumulated outstanding request (in cycles) of incoming write requests. + * IN_WR_REQ: the number of incoming write requests. + * OUT_RD_CUM_OUTS: accumulated outstanding request (in cycles) of outgoing read requests. + * OUT_RD_REQ: the number of outgoing read requests. + * OUT_WR_CUM_OUTS: accumulated outstanding request (in cycles) of outgoing write requests. + * OUT_WR_REQ: the number of outgoing write requests. + * CYCLES: NVLink-C2C interface cycle counts. + +The incoming events count the reads/writes from remote device to the SoC. +The outgoing events count the reads/writes from the SoC to remote device. + +The sysfs /sys/bus/event_source/devices/nvidia_nvlink_c2c_pmu_<socket-id>/peer +contains the information about the connected device. + +When the C2C interface is connected to GPU(s), the user can use the +"gpu_mask" parameter to filter traffic to/from specific GPU(s). Each bit represents the GPU +index, e.g. "gpu_mask=0x1" corresponds to GPU 0 and "gpu_mask=0x3" is for GPU 0 and 1. +The PMU will monitor all GPUs by default if not specified. + +When connected to another SoC, only the read events are available. + +The events can be used to calculate the average latency of the read/write requests:: + + C2C_FREQ_IN_GHZ = CYCLES / ELAPSED_TIME_IN_NS + + IN_RD_AVG_LATENCY_IN_CYCLES = IN_RD_CUM_OUTS / IN_RD_REQ + IN_RD_AVG_LATENCY_IN_NS = IN_RD_AVG_LATENCY_IN_CYCLES / C2C_FREQ_IN_GHZ + + IN_WR_AVG_LATENCY_IN_CYCLES = IN_WR_CUM_OUTS / IN_WR_REQ + IN_WR_AVG_LATENCY_IN_NS = IN_WR_AVG_LATENCY_IN_CYCLES / C2C_FREQ_IN_GHZ + + OUT_RD_AVG_LATENCY_IN_CYCLES = OUT_RD_CUM_OUTS / OUT_RD_REQ + OUT_RD_AVG_LATENCY_IN_NS = OUT_RD_AVG_LATENCY_IN_CYCLES / C2C_FREQ_IN_GHZ + + OUT_WR_AVG_LATENCY_IN_CYCLES = OUT_WR_CUM_OUTS / OUT_WR_REQ + OUT_WR_AVG_LATENCY_IN_NS = OUT_WR_AVG_LATENCY_IN_CYCLES / C2C_FREQ_IN_GHZ + +Example usage: + + * Count incoming traffic from all GPUs connected via NVLink-C2C:: + + perf stat -a -e nvidia_nvlink_c2c_pmu_0/in_rd_req/ + + * Count incoming traffic from GPU 0 connected via NVLink-C2C:: + + perf stat -a -e nvidia_nvlink_c2c_pmu_0/in_rd_cum_outs,gpu_mask=0x1/ + + * Count incoming traffic from GPU 1 connected via NVLink-C2C:: + + perf stat -a -e nvidia_nvlink_c2c_pmu_0/in_rd_cum_outs,gpu_mask=0x2/ + + * Count outgoing traffic to all GPUs connected via NVLink-C2C:: + + perf stat -a -e nvidia_nvlink_c2c_pmu_0/out_rd_req/ + + * Count outgoing traffic to GPU 0 connected via NVLink-C2C:: + + perf stat -a -e nvidia_nvlink_c2c_pmu_0/out_rd_cum_outs,gpu_mask=0x1/ + + * Count outgoing traffic to GPU 1 connected via NVLink-C2C:: + + perf stat -a -e nvidia_nvlink_c2c_pmu_0/out_rd_cum_outs,gpu_mask=0x2/ + +NV-CLink PMU +------------ + +This PMU monitors latency events of memory read requests that pass through +the NV-CLINK interface. Bandwidth events are not available in this PMU. +In Tegra410 SoC, the NV-CLink interface is used to connect to another Tegra410 +SoC and this PMU only counts read traffic. + +The events and configuration options of this PMU device are available in sysfs, +see /sys/bus/event_source/devices/nvidia_nvclink_pmu_<socket-id>. + +The list of events: + + * IN_RD_CUM_OUTS: accumulated outstanding request (in cycles) of incoming read requests. + * IN_RD_REQ: the number of incoming read requests. + * OUT_RD_CUM_OUTS: accumulated outstanding request (in cycles) of outgoing read requests. + * OUT_RD_REQ: the number of outgoing read requests. + * CYCLES: NV-CLINK interface cycle counts. + +The incoming events count the reads from remote device to the SoC. +The outgoing events count the reads from the SoC to remote device. + +The events can be used to calculate the average latency of the read requests:: + + CLINK_FREQ_IN_GHZ = CYCLES / ELAPSED_TIME_IN_NS + + IN_RD_AVG_LATENCY_IN_CYCLES = IN_RD_CUM_OUTS / IN_RD_REQ + IN_RD_AVG_LATENCY_IN_NS = IN_RD_AVG_LATENCY_IN_CYCLES / CLINK_FREQ_IN_GHZ + + OUT_RD_AVG_LATENCY_IN_CYCLES = OUT_RD_CUM_OUTS / OUT_RD_REQ + OUT_RD_AVG_LATENCY_IN_NS = OUT_RD_AVG_LATENCY_IN_CYCLES / CLINK_FREQ_IN_GHZ + +Example usage: + + * Count incoming read traffic from remote SoC connected via NV-CLINK:: + + perf stat -a -e nvidia_nvclink_pmu_0/in_rd_req/ + + * Count outgoing read traffic to remote SoC connected via NV-CLINK:: + + perf stat -a -e nvidia_nvclink_pmu_0/out_rd_req/ + +NV-DLink PMU +------------ + +This PMU monitors latency events of memory read requests that pass through +the NV-DLINK interface. Bandwidth events are not available in this PMU. +In Tegra410 SoC, this PMU only counts CXL memory read traffic. + +The events and configuration options of this PMU device are available in sysfs, +see /sys/bus/event_source/devices/nvidia_nvdlink_pmu_<socket-id>. + +The list of events: + + * IN_RD_CUM_OUTS: accumulated outstanding read requests (in cycles) to CXL memory. + * IN_RD_REQ: the number of read requests to CXL memory. + * CYCLES: NV-DLINK interface cycle counts. + +The events can be used to calculate the average latency of the read requests:: + + DLINK_FREQ_IN_GHZ = CYCLES / ELAPSED_TIME_IN_NS + + IN_RD_AVG_LATENCY_IN_CYCLES = IN_RD_CUM_OUTS / IN_RD_REQ + IN_RD_AVG_LATENCY_IN_NS = IN_RD_AVG_LATENCY_IN_CYCLES / DLINK_FREQ_IN_GHZ + +Example usage: + + * Count read events to CXL memory:: + + perf stat -a -e '{nvidia_nvdlink_pmu_0/in_rd_req/,nvidia_nvdlink_pmu_0/in_rd_cum_outs/}' diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst index e1771f2225d5..f8e7050fc762 100644 --- a/Documentation/admin-guide/pm/amd-pstate.rst +++ b/Documentation/admin-guide/pm/amd-pstate.rst @@ -239,8 +239,12 @@ control its functionality at the system level. They are located in the root@hr-test1:/home/ray# ls /sys/devices/system/cpu/cpufreq/policy0/*amd* /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_highest_perf + /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_hw_prefcore /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_lowest_nonlinear_freq /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_max_freq + /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_floor_freq + /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_floor_count + /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_prefcore_ranking ``amd_pstate_highest_perf / amd_pstate_max_freq`` @@ -264,14 +268,46 @@ This attribute is read-only. ``amd_pstate_hw_prefcore`` -Whether the platform supports the preferred core feature and it has been -enabled. This attribute is read-only. +Whether the platform supports the preferred core feature and it has +been enabled. This attribute is read-only. This file is only visible +on platforms which support the preferred core feature. ``amd_pstate_prefcore_ranking`` The performance ranking of the core. This number doesn't have any unit, but larger numbers are preferred at the time of reading. This can change at -runtime based on platform conditions. This attribute is read-only. +runtime based on platform conditions. This attribute is read-only. This file +is only visible on platforms which support the preferred core feature. + +``amd_pstate_floor_freq`` + +The floor frequency associated with each CPU. Userspace can write any +value between ``cpuinfo_min_freq`` and ``scaling_max_freq`` into this +file. When the system is under power or thermal constraints, the +platform firmware will attempt to throttle the CPU frequency to the +value specified in ``amd_pstate_floor_freq`` before throttling it +further. This allows userspace to specify different floor frequencies +to different CPUs. For optimal results, threads of the same core +should have the same floor frequency value. This file is only visible +on platforms that support the CPPC Performance Priority feature. + + +``amd_pstate_floor_count`` + +The number of distinct Floor Performance levels supported by the +platform. For example, if this value is 2, then the number of unique +values obtained from the command ``cat +/sys/devices/system/cpu/cpufreq/policy*/amd_pstate_floor_freq | +sort -n | uniq`` should be at most this number for the behavior +described in ``amd_pstate_floor_freq`` to take effect. A zero value +implies that the platform supports unlimited floor performance levels. +This file is only visible on platforms that support the CPPC +Performance Priority feature. + +**Note**: When ``amd_pstate_floor_count`` is non-zero, the frequency to +which the CPU is throttled under power or thermal constraints is +undefined when the number of unique values of ``amd_pstate_floor_freq`` +across all CPUs in the system exceeds ``amd_pstate_floor_count``. ``energy_performance_available_preferences`` @@ -280,16 +316,22 @@ A list of all the supported EPP preferences that could be used for These profiles represent different hints that are provided to the low-level firmware about the user's desired energy vs efficiency tradeoff. ``default`` represents the epp value is set by platform -firmware. This attribute is read-only. +firmware. ``custom`` designates that integer values 0-255 may be written +as well. This attribute is read-only. ``energy_performance_preference`` The current energy performance preference can be read from this attribute. and user can change current preference according to energy or performance needs -Please get all support profiles list from -``energy_performance_available_preferences`` attribute, all the profiles are -integer values defined between 0 to 255 when EPP feature is enabled by platform -firmware, if EPP feature is disabled, driver will ignore the written value +Coarse named profiles are available in the attribute +``energy_performance_available_preferences``. +Users can also write individual integer values between 0 to 255. +When dynamic EPP is enabled, writes to energy_performance_preference are blocked +even when EPP feature is enabled by platform firmware. Lower epp values shift the bias +towards improved performance while a higher epp value shifts the bias towards +power-savings. The exact impact can change from one platform to the other. +If a valid integer was last written, then a number will be returned on future reads. +If a valid string was last written then a string will be returned on future reads. This attribute is read-write. ``boost`` @@ -311,6 +353,24 @@ boost or `1` to enable it, for the respective CPU using the sysfs path Other performance and frequency values can be read back from ``/sys/devices/system/cpu/cpuX/acpi_cppc/``, see :ref:`cppc_sysfs`. +Dynamic energy performance profile +================================== +The amd-pstate driver supports dynamically selecting the energy performance +profile based on whether the machine is running on AC or DC power. + +Whether this behavior is enabled by default depends on the kernel +config option `CONFIG_X86_AMD_PSTATE_DYNAMIC_EPP`. This behavior can also be overridden +at runtime by the sysfs file ``/sys/devices/system/cpu/cpufreq/policyX/dynamic_epp``. + +When set to enabled, the driver will select a different energy performance +profile when the machine is running on battery or AC power. The driver will +also register with the platform profile handler to receive notifications of +user desired power state and react to those. +When set to disabled, the driver will not change the energy performance profile +based on the power source and will not react to user desired power state. + +Attempting to manually write to the ``energy_performance_preference`` sysfs +file will fail when ``dynamic_epp`` is enabled. ``amd-pstate`` vs ``acpi-cpufreq`` ====================================== @@ -422,6 +482,13 @@ For systems that support ``amd-pstate`` preferred core, the core rankings will always be advertised by the platform. But OS can choose to ignore that via the kernel parameter ``amd_prefcore=disable``. +``amd_dynamic_epp`` + +When AMD pstate is in auto mode, dynamic EPP will control whether the kernel +autonomously changes the EPP mode. The default is configured by +``CONFIG_X86_AMD_PSTATE_DYNAMIC_EPP`` but can be explicitly enabled with +``amd_dynamic_epp=enable`` or disabled with ``amd_dynamic_epp=disable``. + User Space Interface in ``sysfs`` - General =========================================== @@ -790,13 +857,13 @@ Reference =========== .. [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming, - https://www.amd.com/system/files/TechDocs/24593.pdf + https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2 .. [2] Advanced Configuration and Power Interface Specification, https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf .. [3] Processor Programming Reference (PPR) for AMD Family 19h Model 51h, Revision A1 Processors - https://www.amd.com/system/files/TechDocs/56569-A1-PUB.zip + https://docs.amd.com/v/u/en-US/56569-A1-PUB_3.03 .. [4] Linux Kernel Selftests, https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html diff --git a/Documentation/admin-guide/pm/intel-speed-select.rst b/Documentation/admin-guide/pm/intel-speed-select.rst index a2bfb971654f..dec2a25f10bc 100644 --- a/Documentation/admin-guide/pm/intel-speed-select.rst +++ b/Documentation/admin-guide/pm/intel-speed-select.rst @@ -287,7 +287,7 @@ level. Check presence of other Intel(R) SST features --------------------------------------------- -Each of the performance profiles also specifies weather there is support of +Each of the performance profiles also specifies whether there is support of other two Intel(R) SST features (Intel(R) Speed Select Technology - Base Frequency (Intel(R) SST-BF) and Intel(R) Speed Select Technology - Turbo Frequency (Intel SST-TF)). diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst index cb4b78468a93..cb178e0a6208 100644 --- a/Documentation/admin-guide/quickly-build-trimmed-linux.rst +++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst @@ -349,12 +349,14 @@ again. .. _submit_improvements_qbtl: -Did you run into trouble following any of the above steps that is not cleared up -by the reference section below? Or do you have ideas how to improve the text? -Then please take a moment of your time and let the maintainer of this document -know by email (Thorsten Leemhuis <linux@leemhuis.info>), ideally while CCing the -Linux docs mailing list (linux-doc@vger.kernel.org). Such feedback is vital to -improve this document further, which is in everybody's interest, as it will +Did you run into trouble following the step-by-step guide not cleared up by the +reference section below? Did you spot errors? Or do you have ideas on how to +improve the guide? + +If any of that applies, please let the developers know by sending a short note +or a patch to Thorsten Leemhuis <linux@leemhuis.info> while ideally CCing the +public Linux docs mailing list <linux-doc@vger.kernel.org>. Such feedback is +vital to improve this text further, which is in everybody's interest, as it will enable more people to master the task described here. Reference section for the step-by-step guide diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst index a68e6d909274..16a66a1f1975 100644 --- a/Documentation/admin-guide/reporting-issues.rst +++ b/Documentation/admin-guide/reporting-issues.rst @@ -48,6 +48,16 @@ Once the report is out, answer any questions that come up and help where you can. That includes keeping the ball rolling by occasionally retesting with newer releases and sending a status update afterwards. +.. + Note: If you see this note, you are reading the text's source file. You + might want to switch to a rendered version: It makes it a lot easier to + read and navigate this document -- especially when you want to look something + up in the reference section, then jump back to where you left off. +.. + Find the latest rendered version of this text here: + https://docs.kernel.org/admin-guide/reporting-issues.html + + Step-by-step guide how to report issues to the kernel maintainers ================================================================= @@ -231,45 +241,54 @@ kernels regularly rebased on those. If that is the case, follow these steps: The reference section below explains each of these steps in more detail. +Conclusion of the step-by-step guide +------------------------------------ + +Did you run into trouble following the step-by-step guide not cleared up by the +reference section below? Did you spot errors? Or do you have ideas on how to +improve the guide? + +If any of that applies, please let the developers know by sending a short note +or a patch to Thorsten Leemhuis <linux@leemhuis.info> while ideally CCing the +public Linux docs mailing list <linux-doc@vger.kernel.org>. Such feedback is +vital to improve this text further, which is in everybody's interest, as it will +enable more people to master the task described here. + + Reference section: Reporting issues to the kernel maintainers ============================================================= -The detailed guides above outline all the major steps in brief fashion, which -should be enough for most people. But sometimes there are situations where even -experienced users might wonder how to actually do one of those steps. That's -what this section is for, as it will provide a lot more details on each of the -above steps. Consider this as reference documentation: it's possible to read it -from top to bottom. But it's mainly meant to skim over and a place to look up -details how to actually perform those steps. - -A few words of general advice before digging into the details: - - * The Linux kernel developers are well aware this process is complicated and - demands more than other FLOSS projects. We'd love to make it simpler. But - that would require work in various places as well as some infrastructure, - which would need constant maintenance; nobody has stepped up to do that - work, so that's just how things are for now. - - * A warranty or support contract with some vendor doesn't entitle you to - request fixes from developers in the upstream Linux kernel community: such - contracts are completely outside the scope of the Linux kernel, its - development community, and this document. That's why you can't demand - anything such a contract guarantees in this context, not even if the - developer handling the issue works for the vendor in question. If you want - to claim your rights, use the vendor's support channel instead. When doing - so, you might want to mention you'd like to see the issue fixed in the - upstream Linux kernel; motivate them by saying it's the only way to ensure - the fix in the end will get incorporated in all Linux distributions. - - * If you never reported an issue to a FLOSS project before you should consider - reading `How to Report Bugs Effectively - <https://www.chiark.greenend.org.uk/~sgtatham/bugs.html>`_, `How To Ask - Questions The Smart Way - <http://www.catb.org/esr/faqs/smart-questions.html>`_, and `How to ask good - questions <https://jvns.ca/blog/good-questions/>`_. - -With that off the table, find below the details on how to properly report -issues to the Linux kernel developers. +The step-by-step guide above outlines all the major steps in brief fashion, +which usually covers everything required. But even experienced users will +sometimes wonder how to actually realize some of those steps or why they are +needed; there are also corner cases the guide ignores for readability. That is +what the entries in this reference section are for, which provide additional +information for each of the steps in the guide. + +A few words of general advice: + +* The Linux developers are well aware that reporting bugs to them is more + complicated and demanding than in other FLOSS projects. Some of it is because + the kernel is different, among others due to its mail-driven development + process and because it consists mostly of drivers. Some of it is because + improving things would require work in several technical areas and people + triaging bugs –– and nobody has stepped up to do or fund that work. + +* A warranty or support contract with some vendor doesn't entitle you to + request fixes from the upstream Linux developers: Such contracts are + completely outside the scope of the upstream Linux kernel, its development + community, and this document -- even if those handling the issue work for the + vendor who issued the contract. If you want to claim your rights, use the + vendor's support channel. + +* If you never reported an issue to a FLOSS project before, consider skimming + guides like `How to ask good questions + <https://jvns.ca/blog/good-questions/>`_, `How To Ask Questions The Smart Way + <http://www.catb.org/esr/faqs/smart-questions.html>`_, and `How to Report + Bugs Effectively <https://www.chiark.greenend.org.uk/~sgtatham/bugs.html>`_,. + +With that off the table, find below details for the steps from the detailed +guide on reporting issues to the Linux kernel developers. Make sure you're using the upstream Linux kernel @@ -1674,72 +1693,59 @@ for the subsystem where the issue seems to have its roots; CC the mailing list for the subsystem as well as the stable mailing list (stable@vger.kernel.org). -Why some issues won't get any reaction or remain unfixed after being reported -============================================================================= - -When reporting a problem to the Linux developers, be aware only 'issues of high -priority' (regressions, security issues, severe problems) are definitely going -to get resolved. The maintainers or if all else fails Linus Torvalds himself -will make sure of that. They and the other kernel developers will fix a lot of -other issues as well. But be aware that sometimes they can't or won't help; and -sometimes there isn't even anyone to send a report to. - -This is best explained with kernel developers that contribute to the Linux -kernel in their spare time. Quite a few of the drivers in the kernel were -written by such programmers, often because they simply wanted to make their -hardware usable on their favorite operating system. - -These programmers most of the time will happily fix problems other people -report. But nobody can force them to do, as they are contributing voluntarily. - -Then there are situations where such developers really want to fix an issue, -but can't: sometimes they lack hardware programming documentation to do so. -This often happens when the publicly available docs are superficial or the -driver was written with the help of reverse engineering. - -Sooner or later spare time developers will also stop caring for the driver. -Maybe their test hardware broke, got replaced by something more fancy, or is so -old that it's something you don't find much outside of computer museums -anymore. Sometimes developer stops caring for their code and Linux at all, as -something different in their life became way more important. In some cases -nobody is willing to take over the job as maintainer – and nobody can be forced -to, as contributing to the Linux kernel is done on a voluntary basis. Abandoned -drivers nevertheless remain in the kernel: they are still useful for people and -removing would be a regression. - -The situation is not that different with developers that are paid for their -work on the Linux kernel. Those contribute most changes these days. But their -employers sooner or later also stop caring for their code or make its -programmer focus on other things. Hardware vendors for example earn their money -mainly by selling new hardware; quite a few of them hence are not investing -much time and energy in maintaining a Linux kernel driver for something they -stopped selling years ago. Enterprise Linux distributors often care for a -longer time period, but in new versions often leave support for old and rare -hardware aside to limit the scope. Often spare time contributors take over once -a company orphans some code, but as mentioned above: sooner or later they will -leave the code behind, too. - -Priorities are another reason why some issues are not fixed, as maintainers -quite often are forced to set those, as time to work on Linux is limited. -That's true for spare time or the time employers grant their developers to -spend on maintenance work on the upstream kernel. Sometimes maintainers also -get overwhelmed with reports, even if a driver is working nearly perfectly. To -not get completely stuck, the programmer thus might have no other choice than -to prioritize issue reports and reject some of them. - -But don't worry too much about all of this, a lot of drivers have active -maintainers who are quite interested in fixing as many issues as possible. - - -Closing words -============= - -Compared with other Free/Libre & Open Source Software it's hard to report -issues to the Linux kernel developers: the length and complexity of this -document and the implications between the lines illustrate that. But that's how -it is for now. The main author of this text hopes documenting the state of the -art will lay some groundwork to improve the situation over time. - +Appendix: Why it is somewhat hard to report kernel bugs +======================================================= + +The Linux kernel developers are well aware that reporting bugs to them is harder +than in other Free/Libre Open Source Projects. Many reasons for that lie in the +nature of kernels, Linux' development model, and how the world uses the kernel: + +* *Most kernels of Linux distributions are totally unsuitable for reporting bugs + upstream.* The reference section above already explained this in detail: + outdated codebases as well as modifications and add-ons lead to kernel bugs + that were fixed upstream a long time ago or never happened there in the first + place. Developers of other Open Source software face these problems as well, + but the situation is a lot worse when it comes to the kernel, as the changes + and their impact are much more severe -- which is why many kernel developers + expect reports with kernels built from fresh and nearly unmodified sources. + +* *Bugs often only occur in a special environment.* That is because Linux is + mostly drivers and can be used in a multitude of ways. Developers often do not + have a matching setup at hand -- and therefore frequently must rely on bug + reporters for isolating a problems's cause and testing proposed fixes. + +* *The kernel has hundreds of maintainers, but all-rounders are very rare.* That + again is and effect caused by the multitude of features and drivers, due to + which many kernel developers know little about lower or higher layers related + to their code and even less about other areas. + +* *It is hard finding where to report issues to, among others, due to the lack + of a central bug tracker.* This is something even some kernel developers + dislike, but that's the situation everyone has to deal with currently. + +* *Stable and longterm kernels are primarily maintained by a dedicated 'stable + team', which only handles regressions introduced within stable and longterm + series.* When someone reports a bug, say, using Linux 6.1.2, the team will, + therefore, always ask if mainline is affected: if the bug already happened + in 6.1 or occurs with latest mainline (say, 6.2-rc3), they in everybody's + interest shove it to the regular developers, as those know the code best. + +* *Linux developers are free to focus on latest mainline.* Some, thus, react + coldly to reports about bugs in, say, Linux 6.0 when 6.1 is already out; + even the latter might not be enough once 6.2-rc1 is out. Some will also not + be very welcoming to reports with 6.1.5 or 6.1.6, as the problem might be a + series-specific regression the stable team (see above) caused and must fix. + +* *Sometimes there is nobody to help.* Sometimes this is due to the lack of + hardware documentation -- for example, when a driver was built using reverse + engineering or was taken over by spare-time developers when the hardware + manufacturer left it behind. Other times there is nobody to even report bugs + to: when maintainers move on without a replacement, their code often remains + in the kernel as long as it's useful. + +Some of these aspects could be improved to facilitate bug reporting -- many +Linux kernel developers are well aware of this and would be glad if a few +individuals or an entity would make this their mission. .. end-of-content diff --git a/Documentation/admin-guide/sysctl/crypto.rst b/Documentation/admin-guide/sysctl/crypto.rst new file mode 100644 index 000000000000..b707bd314a64 --- /dev/null +++ b/Documentation/admin-guide/sysctl/crypto.rst @@ -0,0 +1,47 @@ +================= +/proc/sys/crypto/ +================= + +These files show up in ``/proc/sys/crypto/``, depending on the +kernel configuration: + +.. contents:: :local: + +fips_enabled +============ + +Read-only flag that indicates whether FIPS mode is enabled. + +- ``0``: FIPS mode is disabled (default). +- ``1``: FIPS mode is enabled. + +This value is set at boot time via the ``fips=1`` kernel command line +parameter. When enabled, the cryptographic API will restrict the use +of certain algorithms and perform self-tests to ensure compliance with +FIPS (Federal Information Processing Standards) requirements, such as +FIPS 140-2 and the newer FIPS 140-3, depending on the kernel +configuration and the module in use. + +fips_name +========= + +Read-only file that contains the name of the FIPS module currently in use. +The value is typically configured via the ``CONFIG_CRYPTO_FIPS_NAME`` +kernel configuration option. + +fips_version +============ + +Read-only file that contains the version string of the FIPS module. +If ``CONFIG_CRYPTO_FIPS_CUSTOM_VERSION`` is set, it uses the value from +``CONFIG_CRYPTO_FIPS_VERSION``. Otherwise, it defaults to the kernel +release version (``UTS_RELEASE``). + +Copyright (c) 2026, Shubham Chakraborty <chakrabortyshubham66@gmail.com> + +For general info and legal blurb, please look in +Documentation/admin-guide/sysctl/index.rst. + +.. See scripts/check-sysctl-docs to keep this up to date: +.. scripts/check-sysctl-docs -vtable="crypto" \ +.. $(git grep -l register_sysctl_) diff --git a/Documentation/admin-guide/sysctl/debug.rst b/Documentation/admin-guide/sysctl/debug.rst new file mode 100644 index 000000000000..506bd5e48594 --- /dev/null +++ b/Documentation/admin-guide/sysctl/debug.rst @@ -0,0 +1,52 @@ +================ +/proc/sys/debug/ +================ + +These files show up in ``/proc/sys/debug/``, depending on the +kernel configuration: + +.. contents:: :local: + +exception-trace +=============== + +This flag controls whether the kernel prints information about unhandled +signals (like segmentation faults) to the kernel log (``dmesg``). + +- ``0``: Unhandled signals are not traced. +- ``1``: Information about unhandled signals is printed. + +The default value is ``1`` on most architectures (like x86, MIPS, RISC-V), +but it is ``0`` on **arm64**. + +The actual information printed and the context provided varies +significantly depending on the CPU architecture. For example: + +- On **x86**, it typically prints the instruction pointer (IP), error + code, and address that caused a page fault. +- On **PowerPC**, it may print the next instruction pointer (NIP), + link register (LR), and other relevant registers. + +When enabled, this feature is often rate-limited to prevent the kernel +log from being flooded during a crash loop. + +kprobes-optimization +==================== + +This flag enables or disables the optimization of Kprobes on certain +architectures (like x86). + +- ``0``: Kprobes optimization is turned off. +- ``1``: Kprobes optimization is turned on (default). + +For more details on Kprobes and its optimization, please refer to +Documentation/trace/kprobes.rst. + +Copyright (c) 2026, Shubham Chakraborty <chakrabortyshubham66@gmail.com> + +For general info and legal blurb, please look in +Documentation/admin-guide/sysctl/index.rst. + +.. See scripts/check-sysctl-docs to keep this up to date: +.. scripts/check-sysctl-docs -vtable="debug" \ +.. $(git grep -l register_sysctl_) diff --git a/Documentation/admin-guide/sysctl/index.rst b/Documentation/admin-guide/sysctl/index.rst index 4dd2c9b5d752..50f00514f0ff 100644 --- a/Documentation/admin-guide/sysctl/index.rst +++ b/Documentation/admin-guide/sysctl/index.rst @@ -67,8 +67,8 @@ This documentation is about: =============== =============================================================== abi/ execution domains & personalities <$ARCH> tuning controls for various CPU architecture (e.g. csky, s390) -crypto/ <undocumented> -debug/ <undocumented> +crypto/ cryptographic subsystem +debug/ debugging features dev/ device specific information (e.g. dev/cdrom/info) fs/ specific filesystems filehandle, inode, dentry and quota tuning @@ -84,7 +84,7 @@ sunrpc/ SUN Remote Procedure Call (NFS) user/ Per user namespace limits vm/ memory management tuning buffer and cache management -xen/ <undocumented> +xen/ Xen hypervisor controls =============== =============================================================== These are the subdirs I have on my system or have been discovered by @@ -96,9 +96,12 @@ it :-) :maxdepth: 1 abi + crypto + debug fs kernel net sunrpc user vm + xen diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 9aed74e65cf4..c6994e55d141 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -418,7 +418,8 @@ hung_task_detect_count ====================== Indicates the total number of tasks that have been detected as hung since -the system boot. +the system boot or since the counter was reset. The counter is zeroed when +a value of 0 is written. This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled. diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst index 3b2ad61995d4..0724a793798f 100644 --- a/Documentation/admin-guide/sysctl/net.rst +++ b/Documentation/admin-guide/sysctl/net.rst @@ -602,3 +602,31 @@ it does not modify the current namespace or any existing children. A namespace with ``ns_mode`` set to ``local`` cannot change ``child_ns_mode`` to ``global`` (returns ``-EPERM``). + +g2h_fallback +------------ + +Controls whether connections to CIDs not owned by the host-to-guest (H2G) +transport automatically fall back to the guest-to-host (G2H) transport. + +When enabled, if a connect targets a CID that the H2G transport (e.g. +vhost-vsock) does not serve, or if no H2G transport is loaded at all, the +connection is routed via the G2H transport (e.g. virtio-vsock) instead. This +allows a host running both nested VMs (via vhost-vsock) and sibling VMs +reachable through the hypervisor (e.g. Nitro Enclaves) to address both using +a single CID space, without requiring applications to set +``VMADDR_FLAG_TO_HOST``. + +When the fallback is taken, ``VMADDR_FLAG_TO_HOST`` is automatically set on +the remote address so that userspace can determine the path via +``getpeername()``. + +Note: With this sysctl enabled, user space that attempts to talk to a guest +CID which is not implemented by the H2G transport will create host vsock +traffic. Environments that rely on H2G-only isolation should set it to 0. + +Values: + + - 0 - Connections to CIDs <= 2 or with VMADDR_FLAG_TO_HOST use G2H; + all others use H2G (or fail with ENODEV if H2G is not loaded). + - 1 - Connections to CIDs not owned by H2G fall back to G2H. (default) diff --git a/Documentation/admin-guide/sysctl/xen.rst b/Documentation/admin-guide/sysctl/xen.rst new file mode 100644 index 000000000000..6c5edc3e5e4c --- /dev/null +++ b/Documentation/admin-guide/sysctl/xen.rst @@ -0,0 +1,31 @@ +=============== +/proc/sys/xen/ +=============== + +Copyright (c) 2026, Shubham Chakraborty <chakrabortyshubham66@gmail.com> + +For general info and legal blurb, please look in +Documentation/admin-guide/sysctl/index.rst. + +------------------------------------------------------------------------------ + +These files show up in ``/proc/sys/xen/``, depending on the +kernel configuration: + +.. contents:: :local: + +balloon/hotplug_unpopulated +=========================== + +This flag controls whether unpopulated memory ranges are automatically +hotplugged as system RAM. + +- ``0``: Unpopulated ranges are not hotplugged (default). +- ``1``: Unpopulated ranges are automatically hotplugged. + +When enabled, the Xen balloon driver will add memory regions that are +marked as unpopulated in the Xen memory map to the system as usable RAM. +This allows for dynamic memory expansion in Xen guest domains. + +This option is only available when the kernel is built with +``CONFIG_XEN_BALLOON_MEMORY_HOTPLUG`` enabled. diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index ed1f8f1e86c5..9ead927a37c0 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -74,7 +74,7 @@ a particular type of taint. It's best to leave that to the aforementioned script, but if you need something quick you can use this shell command to check which bits are set:: - $ for i in $(seq 18); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done + $ for i in $(seq 20); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done Table for decoding tainted state ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst index d83601f2a459..7d38393f31fb 100644 --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst @@ -1062,16 +1062,15 @@ Conclusion You have reached the end of the step-by-step guide. -Did you run into trouble following any of the above steps not cleared up by the -reference section below? Did you spot errors? Or do you have ideas how to +Did you run into trouble following the step-by-step guide not cleared up by the +reference section below? Did you spot errors? Or do you have ideas on how to improve the guide? -If any of that applies, please take a moment and let the maintainer of this -document know by email (Thorsten Leemhuis <linux@leemhuis.info>), ideally while -CCing the Linux docs mailing list (linux-doc@vger.kernel.org). Such feedback is -vital to improve this text further, which is in everybody's interest, as it -will enable more people to master the task described here -- and hopefully also -improve similar guides inspired by this one. +If any of that applies, please let the developers know by sending a short note +or a patch to Thorsten Leemhuis <linux@leemhuis.info> while ideally CCing the +public Linux docs mailing list <linux-doc@vger.kernel.org>. Such feedback is +vital to improve this text further, which is in everybody's interest, as it will +enable more people to master the task described here. Reference section for the step-by-step guide diff --git a/Documentation/admin-guide/xfs.rst b/Documentation/admin-guide/xfs.rst index 746ea60eed3f..acdd4b65964c 100644 --- a/Documentation/admin-guide/xfs.rst +++ b/Documentation/admin-guide/xfs.rst @@ -550,6 +550,10 @@ For zoned file systems, the following attributes are exposed in: is limited by the capabilities of the backing zoned device, file system size and the max_open_zones mount option. + nr_open_zones (Min: 0 Default: Varies Max: UINTMAX) + This read-only attribute exposes the current number of open zones + used by the file system. + zonegc_low_space (Min: 0 Default: 0 Max: 100) Define a percentage for how much of the unused space that GC should keep available for writing. A high value will reclaim more of the space diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst index af52edc8c0ac..98052b4ef4a1 100644 --- a/Documentation/arch/arm64/index.rst +++ b/Documentation/arch/arm64/index.rst @@ -23,6 +23,7 @@ ARM64 Architecture memory memory-tagging-extension mops + mpam perf pointer-authentication ptdump diff --git a/Documentation/arch/arm64/mpam.rst b/Documentation/arch/arm64/mpam.rst new file mode 100644 index 000000000000..570f51a8d4eb --- /dev/null +++ b/Documentation/arch/arm64/mpam.rst @@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==== +MPAM +==== + +What is MPAM +============ +MPAM (Memory Partitioning and Monitoring) is a feature in the CPUs and memory +system components such as the caches or memory controllers that allow memory +traffic to be labelled, partitioned and monitored. + +Traffic is labelled by the CPU, based on the control or monitor group the +current task is assigned to using resctrl. Partitioning policy can be set +using the schemata file in resctrl, and monitor values read via resctrl. +See Documentation/filesystems/resctrl.rst for more details. + +This allows tasks that share memory system resources, such as caches, to be +isolated from each other according to the partitioning policy (so called noisy +neighbours). + +Supported Platforms +=================== +Use of this feature requires CPU support, support in the memory system +components, and a description from firmware of where the MPAM device controls +are in the MMIO address space. (e.g. the 'MPAM' ACPI table). + +The MMIO device that provides MPAM controls/monitors for a memory system +component is called a memory system component. (MSC). + +Because the user interface to MPAM is via resctrl, only MPAM features that are +compatible with resctrl can be exposed to user-space. + +MSC are considered as a group based on the topology. MSC that correspond with +the L3 cache are considered together, it is not possible to mix MSC between L2 +and L3 to 'cover' a resctrl schema. + +The supported features are: + +* Cache portion bitmap controls (CPOR) on the L2 or L3 caches. To expose + CPOR at L2 or L3, every CPU must have a corresponding CPU cache at this + level that also supports the feature. Mismatched big/little platforms are + not supported as resctrl's controls would then also depend on task + placement. + +* Memory bandwidth maximum controls (MBW_MAX) on or after the L3 cache. + resctrl uses the L3 cache-id to identify where the memory bandwidth + control is applied. For this reason the platform must have an L3 cache + with cache-id's supplied by firmware. (It doesn't need to support MPAM.) + + To be exported as the 'MB' schema, the topology of the group of MSC chosen + must match the topology of the L3 cache so that the cache-id's can be + repainted. For example: Platforms with Memory bandwidth maximum controls + on CPU-less NUMA nodes cannot expose the 'MB' schema to resctrl as these + nodes do not have a corresponding L3 cache. If the memory bandwidth + control is on the memory rather than the L3 then there must be a single + global L3 as otherwise it is unknown which L3 the traffic came from. There + must be no caches between the L3 and the memory so that the two ends of + the path have equivalent traffic. + + When the MPAM driver finds multiple groups of MSC it can use for the 'MB' + schema, it prefers the group closest to the L3 cache. + +* Cache Storage Usage (CSU) counters can expose the 'llc_occupancy' provided + there is at least one CSU monitor on each MSC that makes up the L3 group. + Exposing CSU counters from other caches or devices is not supported. + +Reporting Bugs +============== +If you are not seeing the counters or controls you expect please share the +debug messages produced when enabling dynamic debug and booting with: +dyndbg="file mpam_resctrl.c +pl" diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst index 4c300caad901..211119ce7adc 100644 --- a/Documentation/arch/arm64/silicon-errata.rst +++ b/Documentation/arch/arm64/silicon-errata.rst @@ -202,18 +202,29 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-V3AE | #3312417 | ARM64_ERRATUM_3194386 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | C1-Pro | #4193714 | ARM64_ERRATUM_4193714 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-500 | #841119,826419 | ARM_SMMU_MMU_500_CPRE_ERRATA| | | | #562869,1047329 | | +----------------+-----------------+-----------------+-----------------------------+ | ARM | MMU-600 | #1076982,1209401| N/A | +----------------+-----------------+-----------------+-----------------------------+ -| ARM | MMU-700 | #2268618,2812531| N/A | +| ARM | MMU-700 | #2133013, | N/A | +| | | #2268618, | | +| | | #2812531, | | +| | | #3777127 | | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | MMU L1 | #3878312 | N/A | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | MMU S3 | #3995052 | N/A | +----------------+-----------------+-----------------+-----------------------------+ | ARM | GIC-700 | #2941627 | ARM64_ERRATUM_2941627 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | SI L1 | #4311569 | ARM64_ERRATUM_4311569 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | CMN-650 | #3642720 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ ++----------------+-----------------+-----------------+-----------------------------+ | Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 | +----------------+-----------------+-----------------+-----------------------------+ | Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 | @@ -247,6 +258,12 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A | +----------------+-----------------+-----------------+-----------------------------+ +| NVIDIA | T241 MPAM | T241-MPAM-1 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ +| NVIDIA | T241 MPAM | T241-MPAM-4 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ +| NVIDIA | T241 MPAM | T241-MPAM-6 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 | +----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/arch/riscv/zicfilp.rst b/Documentation/arch/riscv/zicfilp.rst index 78a3e01ff68c..ab7d8e62ddaf 100644 --- a/Documentation/arch/riscv/zicfilp.rst +++ b/Documentation/arch/riscv/zicfilp.rst @@ -76,34 +76,49 @@ the program. 4. prctl() enabling -------------------- -:c:macro:`PR_SET_INDIR_BR_LP_STATUS` / :c:macro:`PR_GET_INDIR_BR_LP_STATUS` / -:c:macro:`PR_LOCK_INDIR_BR_LP_STATUS` are three prctls added to manage indirect -branch tracking. These prctls are architecture-agnostic and return -EINVAL if -the underlying functionality is not supported. +Per-task indirect branch tracking state can be monitored and +controlled via the :c:macro:`PR_GET_CFI` and :c:macro:`PR_SET_CFI` +``prctl()` arguments (respectively), by supplying +:c:macro:`PR_CFI_BRANCH_LANDING_PADS` as the second argument. These +are architecture-agnostic, and will return -EINVAL if the underlying +functionality is not supported. -* prctl(PR_SET_INDIR_BR_LP_STATUS, unsigned long arg) +* prctl(:c:macro:`PR_SET_CFI`, :c:macro:`PR_CFI_BRANCH_LANDING_PADS`, unsigned long arg) -If arg1 is :c:macro:`PR_INDIR_BR_LP_ENABLE` and if CPU supports -``zicfilp`` then the kernel will enable indirect branch tracking for the -task. The dynamic loader can issue this :c:macro:`prctl` once it has -determined that all the objects loaded in the address space support -indirect branch tracking. Additionally, if there is a `dlopen` to an -object which wasn't compiled with ``zicfilp``, the dynamic loader can -issue this prctl with arg1 set to 0 (i.e. :c:macro:`PR_INDIR_BR_LP_ENABLE` -cleared). - -* prctl(PR_GET_INDIR_BR_LP_STATUS, unsigned long * arg) +arg is a bitmask. -Returns the current status of indirect branch tracking. If enabled -it'll return :c:macro:`PR_INDIR_BR_LP_ENABLE` - -* prctl(PR_LOCK_INDIR_BR_LP_STATUS, unsigned long arg) +If :c:macro:`PR_CFI_ENABLE` is set in arg, and the CPU supports +``zicfilp``, then the kernel will enable indirect branch tracking for +the task. The dynamic loader can issue this ``prctl()`` once it has +determined that all the objects loaded in the address space support +indirect branch tracking. + +Indirect branch tracking state can also be locked once enabled. This +prevents the task from subsequently disabling it. This is done by +setting the bit :c:macro:`PR_CFI_LOCK` in arg. Either indirect branch +tracking must already be enabled for the task, or the bit +:c:macro:`PR_CFI_ENABLE` must also be set in arg. This is intended +for environments that wish to run with a strict security posture that +do not wish to load objects without ``zicfilp`` support. + +Indirect branch tracking can also be disabled for the task, assuming +that it has not previously been enabled and locked. If there is a +``dlopen()`` to an object which wasn't compiled with ``zicfilp``, the +dynamic loader can issue this ``prctl()`` with arg set to +:c:macro:`PR_CFI_DISABLE`. Disabling indirect branch tracking for the +task is not possible if it has previously been enabled and locked. + + +* prctl(:c:macro:`PR_GET_CFI`, :c:macro:`PR_CFI_BRANCH_LANDING_PADS`, unsigned long * arg) + +Returns the current status of indirect branch tracking into a bitmask +stored into the memory location pointed to by arg. The bitmask will +have the :c:macro:`PR_CFI_ENABLE` bit set if indirect branch tracking +is currently enabled for the task, and if it is locked, will +additionally have the :c:macro:`PR_CFI_LOCK` bit set. If indirect +branch tracking is currently disabled for the task, the +:c:macro:`PR_CFI_DISABLE` bit will be set. -Locks the current status of indirect branch tracking on the task. User -space may want to run with a strict security posture and wouldn't want -loading of objects without ``zicfilp`` support in them, to disallow -disabling of indirect branch tracking. In this case, user space can -use this prctl to lock the current settings. 5. violations related to indirect branch tracking -------------------------------------------------- diff --git a/Documentation/arch/s390/pci.rst b/Documentation/arch/s390/pci.rst index d5755484d8e7..80f4ba193159 100644 --- a/Documentation/arch/s390/pci.rst +++ b/Documentation/arch/s390/pci.rst @@ -6,6 +6,7 @@ S/390 PCI Authors: - Pierre Morel + - Niklas Schnelle Copyright, IBM Corp. 2020 @@ -27,14 +28,16 @@ Command line parameters debugfs entries --------------- -The S/390 debug feature (s390dbf) generates views to hold various debug results in sysfs directories of the form: +The S/390 debug feature (s390dbf) generates views to hold various debug results +in sysfs directories of the form: * /sys/kernel/debug/s390dbf/pci_*/ For example: - /sys/kernel/debug/s390dbf/pci_msg/sprintf - Holds messages from the processing of PCI events, like machine check handling + + holds messages from the processing of PCI events, like machine check handling and setting of global functionality, like UID checking. Change the level of logging to be more or less verbose by piping @@ -47,87 +50,141 @@ Sysfs entries Entries specific to zPCI functions and entries that hold zPCI information. -* /sys/bus/pci/slots/XXXXXXXX +* /sys/bus/pci/slots/XXXXXXXX: - The slot entries are set up using the function identifier (FID) of the - PCI function. The format depicted as XXXXXXXX above is 8 hexadecimal digits - with 0 padding and lower case hexadecimal digits. + The slot entries are set up using the function identifier (FID) of the PCI + function as slot name. The format depicted as XXXXXXXX above is 8 hexadecimal + digits with 0 padding and lower case hexadecimal digits. - /sys/bus/pci/slots/XXXXXXXX/power + In addition to using the FID as the name of the slot, the slot directory + also contains the following s390-specific slot attributes. + + - uid: + The User-defined identifier (UID) of the function which may be configured + by this slot. See also the corresponding attribute of the device. + A physical function that currently supports a virtual function cannot be powered off until all virtual functions are removed with: - echo 0 > /sys/bus/pci/devices/XXXX:XX:XX.X/sriov_numvf + echo 0 > /sys/bus/pci/devices/DDDD:BB:dd.f/sriov_numvf -* /sys/bus/pci/devices/XXXX:XX:XX.X/ +* /sys/bus/pci/devices/DDDD:BB:dd.f/: - - function_id - A zPCI function identifier that uniquely identifies the function in the Z server. + - function_id: + The zPCI function identifier (FID) is a 32-bit hexadecimal value that + uniquely identifies the PCI function. Unless the hypervisor provides + a virtual FID e.g. on KVM this identifier is unique across the machine even + between different partitions. - - function_handle - Low-level identifier used for a configured PCI function. - It might be useful for debugging. + - function_handle: + This 32-bit hexadecimal value is a low-level identifier used for a PCI + function. Note that the function handle may be changed and become invalid + on PCI events and when enabling/disabling the PCI function. - - pchid - Model-dependent location of the I/O adapter. + - pchid: + This 16-bit hexadecimal value encodes a model-dependent location for + the PCI function. - - pfgid - PCI function group ID, functions that share identical functionality + - pfgid: + PCI function group ID; functions that share identical functionality use a common identifier. A PCI group defines interrupts, IOMMU, IOTLB, and DMA specifics. - - vfn + - vfn: The virtual function number, from 1 to N for virtual functions, 0 for physical functions. - - pft - The PCI function type - - - port - The port corresponds to the physical port the function is attached to. - It also gives an indication of the physical function a virtual function - is attached to. - - - uid - The user identifier (UID) may be defined as part of the machine - configuration or the z/VM or KVM guest configuration. If the accompanying - uid_is_unique attribute is 1 the platform guarantees that the UID is unique - within that instance and no devices with the same UID can be attached - during the lifetime of the system. - - - uid_is_unique - Indicates whether the user identifier (UID) is guaranteed to be and remain - unique within this Linux instance. - - - pfip/segmentX + - pft: + The PCI function type is an s390-specific type attribute. It indicates + a more general, usage oriented, type than PCI Specification + class/vendor/device identifiers. That is PCI functions with the same pft + value may be backed by different hardware implementations. At the same time + apart from unclassified functions (pft is 0x00) the same pft value + generally implies a similar usage model. At the same time the same + PCI hardware device may appear with different pft values when in a + different usage model. For example NETD and NETH VFs may be implemented + by the same PCI hardware device but in NETD the parent Physical Function + is user managed while with NETH it is platform managed. + + Currently the following PFT values are defined: + + - 0x00 (UNC): Unclassified + - 0x02 (ROCE): RoCE Express + - 0x05 (ISM): Internal Shared Memory + - 0x0a (ROC2): RoCE Express 2 + - 0x0b (NVMe): NVMe + - 0x0c (NETH): Network Express hybrid + - 0x0d (CNW): Cloud Network Adapter + - 0x0f (NETD): Network Express direct + + - port: + The port is a decimal value corresponding to the physical port the function + is attached to. Virtual Functions (VFs) share the port with their parent + Physical Function (PF). A value of 0 indicates that the port attribute is + not applicable for that PCI function type. + + - uid: + The user-defined identifier (UID) for a PCI function is a 32-bit + hexadecimal value. It is defined on a per instance basis as part of the + partition, KVM guest, or z/VM guest configuration. If UID Checking is + enabled the platform ensures that the UID is unique within that instance + and no two PCI functions with the same UID will be visible to the instance. + + Independent of this guarantee and unlike the function ID (FID) the UID may + be the same in different partitions within the same machine. This allows to + create PCI configurations in multiple partitions to be identical in the + UID-namespace. + + - uid_is_unique: + A 0 or 1 flag indicating whether the user-defined identifier (UID) is + guaranteed to be and remain unique within this Linux instance. This + platform feature is called UID Checking. + + - pfip/segmentX: The segments determine the isolation of a function. They correspond to the physical path to the function. The more the segments are different, the more the functions are isolated. + - fidparm: + Contains an 8-bit-per-PCI function parameter field in hexadecimal provided + by the platform. The meaning of this field is PCI function type specific. + For NETH VFs a value of 0x01 indicates that the function supports + promiscuous mode. + +* /sys/firmware/clp/uid_checking: + + In addition to the per-device uid_is_unique attribute this presents a + global indication of whether UID Checking is enabled. This allows users + to check for UID Checking even when no PCI functions are configured. + Enumeration and hotplug ======================= The PCI address consists of four parts: domain, bus, device and function, -and is of this form: DDDD:BB:dd.f +and is of this form: DDDD:BB:dd.f. -* When not using multi-functions (norid is set, or the firmware does not - support multi-functions): +* For a PCI function for which the platform does not expose the RID, the + pci=norid kernel parameter is used, or a so-called isolated Virtual Function + which does have RID information but is used without its parent Physical + Function being part of the same PCI configuration: - There is only one function per domain. - - The domain is set from the zPCI function's UID as defined during the - LPAR creation. + - The domain is set from the zPCI function's UID if UID Checking is on; + otherwise the domain ID is generated dynamically and is not stable + across reboots or hot plug. -* When using multi-functions (norid parameter is not set), - zPCI functions are addressed differently: +* For a PCI function for which the platform exposes the RID and which + is not an Isolated Virtual Function: - There is still only one bus per domain. - - There can be up to 256 functions per bus. + - There can be up to 256 PCI functions per bus. - - The domain part of the address of all functions for - a multi-Function device is set from the zPCI function's UID as defined - in the LPAR creation for the function zero. + - The domain part of the address of all functions within the same topology is + that of the configured PCI function with the lowest devfn within that + topology. - - New functions will only be ready for use after the function zero - (the function with devfn 0) has been enumerated. + - Virtual Functions generated by an SR-IOV capable Physical Function only + become visible once SR-IOV is enabled. diff --git a/Documentation/arch/s390/vfio-ap.rst b/Documentation/arch/s390/vfio-ap.rst index eba1991fbdba..ac0c07f76ddd 100644 --- a/Documentation/arch/s390/vfio-ap.rst +++ b/Documentation/arch/s390/vfio-ap.rst @@ -431,17 +431,14 @@ matrix device. * callback interfaces open_device: - The vfio_ap driver uses this callback to register a - VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the matrix mdev - devices. The open_device callback is invoked by userspace to connect the - VFIO iommu group for the matrix mdev device to the MDEV bus. Access to the - KVM structure used to configure the KVM guest is provided via this callback. - The KVM structure, is used to configure the guest's access to the AP matrix - defined via the vfio_ap mediated device's sysfs attribute files. + the open_device callback is invoked by userspace to connect the + VFIO iommu group for the matrix mdev device to the MDEV bus. The + callback retrieves the KVM structure used to configure the KVM guest + and configures the guest's access to the AP matrix defined via the + vfio_ap mediated device's sysfs attribute files. close_device: - unregisters the VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the - matrix mdev device and deconfigures the guest's AP matrix. + this callback deconfigures the guest's AP matrix. ioctl: this callback handles the VFIO_DEVICE_GET_INFO and VFIO_DEVICE_RESET ioctls @@ -449,9 +446,8 @@ matrix device. Configure the guest's AP resources ---------------------------------- -Configuring the AP resources for a KVM guest will be performed when the -VFIO_GROUP_NOTIFY_SET_KVM notifier callback is invoked. The notifier -function is called when userspace connects to KVM. The guest's AP resources are +Configuring the AP resources for a KVM guest will be performed at the +time of ``open_device`` and ``close_device``. The guest's AP resources are configured via its APCB by: * Setting the bits in the APM corresponding to the APIDs assigned to the diff --git a/Documentation/arch/x86/tdx.rst b/Documentation/arch/x86/tdx.rst index 61670e7df2f7..ff6b110291bc 100644 --- a/Documentation/arch/x86/tdx.rst +++ b/Documentation/arch/x86/tdx.rst @@ -60,44 +60,18 @@ Besides initializing the TDX module, a per-cpu initialization SEAMCALL must be done on one cpu before any other SEAMCALLs can be made on that cpu. -The kernel provides two functions, tdx_enable() and tdx_cpu_enable() to -allow the user of TDX to enable the TDX module and enable TDX on local -cpu respectively. - -Making SEAMCALL requires VMXON has been done on that CPU. Currently only -KVM implements VMXON. For now both tdx_enable() and tdx_cpu_enable() -don't do VMXON internally (not trivial), but depends on the caller to -guarantee that. - -To enable TDX, the caller of TDX should: 1) temporarily disable CPU -hotplug; 2) do VMXON and tdx_enable_cpu() on all online cpus; 3) call -tdx_enable(). For example:: - - cpus_read_lock(); - on_each_cpu(vmxon_and_tdx_cpu_enable()); - ret = tdx_enable(); - cpus_read_unlock(); - if (ret) - goto no_tdx; - // TDX is ready to use - -And the caller of TDX must guarantee the tdx_cpu_enable() has been -successfully done on any cpu before it wants to run any other SEAMCALL. -A typical usage is do both VMXON and tdx_cpu_enable() in CPU hotplug -online callback, and refuse to online if tdx_cpu_enable() fails. - User can consult dmesg to see whether the TDX module has been initialized. If the TDX module is initialized successfully, dmesg shows something like below:: [..] virt/tdx: 262668 KBs allocated for PAMT - [..] virt/tdx: module initialized + [..] virt/tdx: TDX-Module initialized If the TDX module failed to initialize, dmesg also shows it failed to initialize:: - [..] virt/tdx: module initialization failed ... + [..] virt/tdx: TDX-Module initialization failed ... TDX Interaction to Other Kernel Components ------------------------------------------ @@ -129,9 +103,9 @@ CPU Hotplug ~~~~~~~~~~~ TDX module requires the per-cpu initialization SEAMCALL must be done on -one cpu before any other SEAMCALLs can be made on that cpu. The kernel -provides tdx_cpu_enable() to let the user of TDX to do it when the user -wants to use a new cpu for TDX task. +one cpu before any other SEAMCALLs can be made on that cpu. The kernel, +via the CPU hotplug framework, performs the necessary initialization when +a CPU is first brought online. TDX doesn't support physical (ACPI) CPU hotplug. During machine boot, TDX verifies all boot-time present logical CPUs are TDX compatible before diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 7e0703a12dfb..cae23949a626 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -153,7 +153,7 @@ blk-crypto-fallback completes the original bio. If the original bio is too large, multiple bounce bios may be required; see the code for details. For decryption, blk-crypto-fallback "wraps" the bio's completion callback -(``bi_complete``) and private data (``bi_private``) with its own, unsets the +(``bi_end_io``) and private data (``bi_private``) with its own, unsets the bio's encryption context, then submits the bio. If the read completes successfully, blk-crypto-fallback restores the bio's original completion callback and private data, then decrypts the bio's data in-place using the diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst index 6ad28039663d..0413dcd9ef69 100644 --- a/Documentation/block/ublk.rst +++ b/Documentation/block/ublk.rst @@ -485,6 +485,125 @@ Limitations in case that too many ublk devices are handled by this single io_ring_ctx and each one has very large queue depth +Shared Memory Zero Copy (UBLK_F_SHMEM_ZC) +------------------------------------------ + +The ``UBLK_F_SHMEM_ZC`` feature provides an alternative zero-copy path +that works by sharing physical memory pages between the client application +and the ublk server. Unlike the io_uring fixed buffer approach above, +shared memory zero copy does not require io_uring buffer registration +per I/O — instead, it relies on the kernel matching physical pages +at I/O time. This allows the ublk server to access the shared +buffer directly, which is unlikely for the io_uring fixed buffer +approach. + +Motivation +~~~~~~~~~~ + +Shared memory zero copy takes a different approach: if the client +application and the ublk server both map the same physical memory, there is +nothing to copy. The kernel detects the shared pages automatically and +tells the server where the data already lives. + +``UBLK_F_SHMEM_ZC`` can be thought of as a supplement for optimized client +applications — when the client is willing to allocate I/O buffers from +shared memory, the entire data path becomes zero-copy. + +Use Cases +~~~~~~~~~ + +This feature is useful when the client application can be configured to +use a specific shared memory region for its I/O buffers: + +- **Custom storage clients** that allocate I/O buffers from shared memory + (memfd, hugetlbfs) and issue direct I/O to the ublk device +- **Database engines** that use pre-allocated buffer pools with O_DIRECT + +How It Works +~~~~~~~~~~~~ + +1. The ublk server and client both ``mmap()`` the same file (memfd or + hugetlbfs) with ``MAP_SHARED``. This gives both processes access to the + same physical pages. + +2. The ublk server registers its mapping with the kernel:: + + struct ublk_shmem_buf_reg buf = { .addr = mmap_va, .len = size }; + ublk_ctrl_cmd(UBLK_U_CMD_REG_BUF, .addr = &buf); + + The kernel pins the pages and builds a PFN lookup tree. + +3. When the client issues direct I/O (``O_DIRECT``) to ``/dev/ublkb*``, + the kernel checks whether the I/O buffer pages match any registered + pages by comparing PFNs. + +4. On a match, the kernel sets ``UBLK_IO_F_SHMEM_ZC`` in the I/O + descriptor and encodes the buffer index and offset in ``addr``:: + + if (iod->op_flags & UBLK_IO_F_SHMEM_ZC) { + /* Data is already in our shared mapping — zero copy */ + index = ublk_shmem_zc_index(iod->addr); + offset = ublk_shmem_zc_offset(iod->addr); + buf = shmem_table[index].mmap_base + offset; + } + +5. If pages do not match (e.g., the client used a non-shared buffer), + the I/O falls back to the normal copy path silently. + +The shared memory can be set up via two methods: + +- **Socket-based**: the client sends a memfd to the ublk server via + ``SCM_RIGHTS`` on a unix socket. The server mmaps and registers it. +- **Hugetlbfs-based**: both processes ``mmap(MAP_SHARED)`` the same + hugetlbfs file. No IPC needed — same file gives same physical pages. + +Advantages +~~~~~~~~~~ + +- **Simple**: no per-I/O buffer registration or unregistration commands. + Once the shared buffer is registered, all matching I/O is zero-copy + automatically. +- **Direct buffer access**: the ublk server can read and write the shared + buffer directly via its own mmap, without going through io_uring fixed + buffer operations. This is more friendly for server implementations. +- **Fast**: PFN matching is a single maple tree lookup per bvec. No + io_uring command round-trips for buffer management. +- **Compatible**: non-matching I/O silently falls back to the copy path. + The device works normally for any client, with zero-copy as an + optimization when shared memory is available. + +Limitations +~~~~~~~~~~~ + +- **Requires client cooperation**: the client must allocate its I/O + buffers from the shared memory region. This requires a custom or + configured client — standard applications using their own buffers + will not benefit. +- **Direct I/O only**: buffered I/O (without ``O_DIRECT``) goes through + the page cache, which allocates its own pages. These kernel-allocated + pages will never match the registered shared buffer. Only ``O_DIRECT`` + puts the client's buffer pages directly into the block I/O. +- **Contiguous data only**: each I/O request's data must be contiguous + within a single registered buffer. Scatter/gather I/O that spans + multiple non-adjacent registered buffers cannot use the zero-copy path. + +Control Commands +~~~~~~~~~~~~~~~~ + +- ``UBLK_U_CMD_REG_BUF`` + + Register a shared memory buffer. ``ctrl_cmd.addr`` points to a + ``struct ublk_shmem_buf_reg`` containing the buffer virtual address and size. + Returns the assigned buffer index (>= 0) on success. The kernel pins + pages and builds the PFN lookup tree. Queue freeze is handled + internally. + +- ``UBLK_U_CMD_UNREG_BUF`` + + Unregister a previously registered buffer. ``ctrl_cmd.data[0]`` is the + buffer index. Unpins pages and removes PFN entries from the lookup + tree. + References ========== diff --git a/Documentation/bpf/drgn.rst b/Documentation/bpf/drgn.rst index 41f223c3161e..cabf702eb75a 100644 --- a/Documentation/bpf/drgn.rst +++ b/Documentation/bpf/drgn.rst @@ -26,8 +26,8 @@ about these objects, including id, type and name. The main use-case `bpf_inspect.py`_ covers is to show BPF programs of types ``BPF_PROG_TYPE_EXT`` and ``BPF_PROG_TYPE_TRACING`` attached to other BPF -programs via ``freplace``/``fentry``/``fexit`` mechanisms, since there is no -user-space API to get this information. +programs via ``freplace``/``fentry``/``fexit``/``fsession`` mechanisms, since +there is no user-space API to get this information. Getting started =============== diff --git a/Documentation/bpf/libbpf/program_types.rst b/Documentation/bpf/libbpf/program_types.rst index 3b837522834b..3a07ce3b7f79 100644 --- a/Documentation/bpf/libbpf/program_types.rst +++ b/Documentation/bpf/libbpf/program_types.rst @@ -207,6 +207,10 @@ described in more detail in the footnotes. + + +----------------------------------+-----------+ | | | ``fexit.s+`` [#fentry]_ | Yes | + +----------------------------------------+----------------------------------+-----------+ +| | ``BPF_TRACE_FSESSION`` | ``fsession+`` [#fentry]_ | | ++ + +----------------------------------+-----------+ +| | | ``fsession.s+`` [#fentry]_ | Yes | ++ +----------------------------------------+----------------------------------+-----------+ | | ``BPF_TRACE_ITER`` | ``iter+`` [#iter]_ | | + + +----------------------------------+-----------+ | | | ``iter.s+`` [#iter]_ | Yes | diff --git a/Documentation/conf.py b/Documentation/conf.py index 679861503a25..9b822ab470d9 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -455,6 +455,7 @@ if html_theme == "alabaster": # The name of an image file (relative to this directory) to place at the top # of the sidebar. html_logo = "images/logo.svg" +html_favicon = "images/logo.svg" # Output file base name for HTML help builder. htmlhelp_basename = "TheLinuxKerneldoc" diff --git a/Documentation/core-api/housekeeping.rst b/Documentation/core-api/housekeeping.rst index e5417302774c..92c6e53cea75 100644 --- a/Documentation/core-api/housekeeping.rst +++ b/Documentation/core-api/housekeeping.rst @@ -15,7 +15,7 @@ various deferrals etc... Sometimes housekeeping is just some unbound work (unbound workqueues, unbound timers, ...) that gets easily assigned to non-isolated CPUs. But sometimes housekeeping is tied to a specific CPU and requires -elaborated tricks to be offloaded to non-isolated CPUs (RCU_NOCB, remote +elaborate tricks to be offloaded to non-isolated CPUs (RCU_NOCB, remote scheduler tick, etc...). Thus, a housekeeping CPU can be considered as the reverse of an isolated diff --git a/Documentation/core-api/irq/index.rst b/Documentation/core-api/irq/index.rst index 0d65d11e5420..13bd24dd2b1c 100644 --- a/Documentation/core-api/irq/index.rst +++ b/Documentation/core-api/irq/index.rst @@ -9,3 +9,4 @@ IRQs irq-affinity irq-domain irqflags-tracing + managed_irq diff --git a/Documentation/core-api/irq/managed_irq.rst b/Documentation/core-api/irq/managed_irq.rst new file mode 100644 index 000000000000..05e295f3c289 --- /dev/null +++ b/Documentation/core-api/irq/managed_irq.rst @@ -0,0 +1,116 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +Affinity managed interrupts +=========================== + +The IRQ core provides support for managing interrupts according to a specified +CPU affinity. Under normal operation, an interrupt is associated with a +particular CPU. If that CPU is taken offline, the interrupt is migrated to +another online CPU. + +Devices with large numbers of interrupt vectors can stress the available vector +space. For example, an NVMe device with 128 I/O queues typically requests one +interrupt per queue on systems with at least 128 CPUs. Two such devices +therefore request 256 interrupts. On x86, the interrupt vector space is +notoriously low, providing only 256 vectors per CPU, and the kernel reserves a +subset of these, further reducing the number available for device interrupts. +In practice this is not an issue because the interrupts are distributed across +many CPUs, so each CPU only receives a small number of vectors. + +During system suspend, however, all secondary CPUs are taken offline and all +interrupts are migrated to the single CPU that remains online. This can exhaust +the available interrupt vectors on that CPU and cause the suspend operation to +fail. + +Affinity‑managed interrupts address this limitation. Each interrupt is assigned +a CPU affinity mask that specifies the set of CPUs on which the interrupt may +be targeted. When a CPU in the mask goes offline, the interrupt is moved to the +next CPU in the mask. If the last CPU in the mask goes offline, the interrupt +is shut down. Drivers using affinity‑managed interrupts must ensure that the +associated queue is quiesced before the interrupt is disabled so that no +further interrupts are generated. When a CPU in the affinity mask comes back +online, the interrupt is re‑enabled. + +Implementation +-------------- + +Devices must provide per‑instance interrupts, such as per‑I/O‑queue interrupts +for storage devices like NVMe. The driver allocates interrupt vectors with the +required affinity settings using struct irq_affinity. For MSI‑X devices, this +is done via pci_alloc_irq_vectors_affinity() with the PCI_IRQ_AFFINITY flag +set. + +Based on the provided affinity information, the IRQ core attempts to spread the +interrupts evenly across the system. The affinity masks are computed during +this allocation step, but the final IRQ assignment is performed when +request_irq() is invoked. + +Isolated CPUs +------------- + +The affinity of managed interrupts is handled entirely in the kernel and cannot +be modified from user space through the /proc interfaces. The managed_irq +sub‑parameter of the isolcpus boot option specifies a CPU mask that managed +interrupts should attempt to avoid. This isolation is best‑effort and only +applies if the automatically assigned interrupt mask also contains online CPUs +outside the avoided mask. If the requested mask contains only isolated CPUs, +the setting has no effect. + +CPUs listed in the avoided mask remain part of the interrupt’s affinity mask. +This means that if all non‑isolated CPUs go offline while isolated CPUs remain +online, the interrupt will be assigned to one of the isolated CPUs. + +The following examples assume a system with 8 CPUs. + +- A QEMU instance is booted with "-device virtio-scsi-pci". + The MSI‑X device exposes 11 interrupts: 3 "management" interrupts and 8 + "queue" interrupts. The driver requests the 8 queue interrupts, each of which + is affine to exactly one CPU. If that CPU goes offline, the interrupt is shut + down. + + Assuming interrupt 48 is one of the queue interrupts, the following appears:: + + /proc/irq/48/effective_affinity_list:7 + /proc/irq/48/smp_affinity_list:7 + + This indicates that the interrupt is served only by CPU7. Shutting down CPU7 + does not migrate the interrupt to another CPU:: + + /proc/irq/48/effective_affinity_list:0 + /proc/irq/48/smp_affinity_list:7 + + This can be verified via the debugfs interface + (/sys/kernel/debug/irq/irqs/48). The dstate field will include + IRQD_IRQ_DISABLED, IRQD_IRQ_MASKED and IRQD_MANAGED_SHUTDOWN. + +- A QEMU instance is booted with "-device virtio-scsi-pci,num_queues=2" + and the kernel command line includes: + "irqaffinity=0,1 isolcpus=domain,2-7 isolcpus=managed_irq,1-3,5-7". + The MSI‑X device exposes 5 interrupts: 3 management interrupts and 2 queue + interrupts. The management interrupts follow the irqaffinity= setting. The + queue interrupts are spread across available CPUs:: + + /proc/irq/47/effective_affinity_list:0 + /proc/irq/47/smp_affinity_list:0-3 + /proc/irq/48/effective_affinity_list:4 + /proc/irq/48/smp_affinity_list:4-7 + + The two queue interrupts are evenly distributed. Interrupt 48 is placed on CPU4 + because the managed_irq mask avoids CPUs 5–7 when possible. + + Replacing the managed_irq argument with "isolcpus=managed_irq,1-3,4-5,7" + results in:: + + /proc/irq/48/effective_affinity_list:6 + /proc/irq/48/smp_affinity_list:4-7 + + Interrupt 48 is now served on CPU6 because the system avoids CPUs 4, 5 and + 7. If CPU6 is taken offline, the interrupt migrates to one of the "isolated" + CPUs:: + + /proc/irq/48/effective_affinity_list:7 + /proc/irq/48/smp_affinity_list:4-7 + + The interrupt is shut down once all CPUs listed in its smp_affinity mask are + offline. diff --git a/Documentation/core-api/kho/abi.rst b/Documentation/core-api/kho/abi.rst index 2e63be3486cf..799d743105a6 100644 --- a/Documentation/core-api/kho/abi.rst +++ b/Documentation/core-api/kho/abi.rst @@ -22,6 +22,12 @@ memblock preservation ABI .. kernel-doc:: include/linux/kho/abi/memblock.h :doc: memblock kexec handover ABI +KHO persistent memory tracker ABI +================================= + +.. kernel-doc:: include/linux/kho/abi/kexec_handover.h + :doc: KHO persistent memory tracker + See Also ======== diff --git a/Documentation/core-api/kho/index.rst b/Documentation/core-api/kho/index.rst index dcc6a36cc134..0a2dee4f8e7d 100644 --- a/Documentation/core-api/kho/index.rst +++ b/Documentation/core-api/kho/index.rst @@ -71,17 +71,17 @@ for boot memory allocations and as target memory for kexec blobs, some parts of that memory region may be reserved. These reservations are irrelevant for the next KHO, because kexec can overwrite even the original kernel. -.. _kho-finalization-phase: +Kexec Handover Radix Tree +========================= -KHO finalization phase -====================== +.. kernel-doc:: include/linux/kho_radix_tree.h + :doc: Kexec Handover Radix Tree -To enable user space based kexec file loader, the kernel needs to be able to -provide the FDT that describes the current kernel's state before -performing the actual kexec. The process of generating that FDT is -called serialization. When the FDT is generated, some properties -of the system may become immutable because they are already written down -in the FDT. That state is called the KHO finalization phase. +Public API +========== + +.. kernel-doc:: kernel/liveupdate/kexec_handover.c + :export: See Also ======== diff --git a/Documentation/core-api/memory-hotplug.rst b/Documentation/core-api/memory-hotplug.rst index 8fc97c2379de..46b0490f5319 100644 --- a/Documentation/core-api/memory-hotplug.rst +++ b/Documentation/core-api/memory-hotplug.rst @@ -96,7 +96,7 @@ NODE_CANCEL_ADDING_FIRST_MEMORY Generated if NODE_ADDING_FIRST_MEMORY fails. NODE_ADDED_FIRST_MEMORY - Generated when memory has become available fo this node for the first time. + Generated when memory has become available for this node for the first time. NODE_REMOVING_LAST_MEMORY Generated when the last memory available to this node is about to be offlined. diff --git a/Documentation/core-api/printk-basics.rst b/Documentation/core-api/printk-basics.rst index 2dde24ca7d9f..48eaff0ce44c 100644 --- a/Documentation/core-api/printk-basics.rst +++ b/Documentation/core-api/printk-basics.rst @@ -103,6 +103,42 @@ For debugging purposes there are also two conditionally-compiled macros: pr_debug() and pr_devel(), which are compiled-out unless ``DEBUG`` (or also ``CONFIG_DYNAMIC_DEBUG`` in the case of pr_debug()) is defined. +Avoiding lockups from excessive printk() use +============================================ + +.. note:: + + This section is relevant only for legacy console drivers (those not + using the nbcon API) and !PREEMPT_RT kernels. Once all console drivers + are updated to nbcon, this documentation can be removed. + +Using ``printk()`` in hot paths (such as interrupt handlers, timer +callbacks, or high-frequency network receive routines) with legacy +consoles (e.g., ``console=ttyS0``) may cause lockups. Legacy consoles +synchronously acquire ``console_sem`` and block while flushing messages, +potentially disabling interrupts long enough to trigger hard or soft +lockup detectors. + +To avoid this: + +- Use rate-limited variants (e.g., ``pr_*_ratelimited()``) or one-time + macros (e.g., ``pr_*_once()``) to reduce message frequency. +- Assign lower log levels (e.g., ``KERN_DEBUG``) to non-essential messages + and filter console output via ``console_loglevel``. +- Use ``printk_deferred()`` to log messages immediately to the ringbuffer + and defer console printing. This is a workaround for legacy consoles. +- Port legacy console drivers to the non-blocking ``nbcon`` API (indicated + by ``CON_NBCON``). This is the preferred solution, as nbcon consoles + offload message printing to a dedicated kernel thread. + +For temporary debugging, ``trace_printk()`` can be used, but it must not +appear in mainline code. See ``Documentation/trace/debugging.rst`` for +more information. + +If more permanent output is needed in a hot path, trace events can be used. +See ``Documentation/trace/events.rst`` and +``samples/trace_events/trace-events-sample.[ch]``. + Function reference ================== diff --git a/Documentation/core-api/real-time/architecture-porting.rst b/Documentation/core-api/real-time/architecture-porting.rst index c90a426d8062..c9a39d708866 100644 --- a/Documentation/core-api/real-time/architecture-porting.rst +++ b/Documentation/core-api/real-time/architecture-porting.rst @@ -74,7 +74,7 @@ Exception handlers Enabling interrupts is especially important on PREEMPT_RT, where certain locks, such as spinlock_t, become sleepable. For example, handling an invalid opcode may result in sending a SIGILL signal to the user task. A - debug excpetion will send a SIGTRAP signal. + debug exception will send a SIGTRAP signal. In both cases, if the exception occurred in user space, it is safe to enable interrupts early. Sending a signal requires both interrupts and kernel preemption to be enabled. diff --git a/Documentation/core-api/real-time/differences.rst b/Documentation/core-api/real-time/differences.rst index 83ec9aa1c61a..a129570dab5a 100644 --- a/Documentation/core-api/real-time/differences.rst +++ b/Documentation/core-api/real-time/differences.rst @@ -213,7 +213,7 @@ to suspend until the callback completes, ensuring forward progress without risking livelock. In order to solve the problem at the API level, the sequence locks were extended -to allow a proper handover between the the spinning reader and the maybe +to allow a proper handover between the spinning reader and the maybe blocked writer. Sequence locks diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst index 034898e81ba2..2304d5bffcce 100644 --- a/Documentation/core-api/symbol-namespaces.rst +++ b/Documentation/core-api/symbol-namespaces.rst @@ -114,6 +114,11 @@ inspected with modinfo:: import_ns: USB_STORAGE [...] +For modules that are currently loaded, imported namespaces are also available +via sysfs:: + + $ cat /sys/module/ums_karma/import_ns + USB_STORAGE It is advisable to add the MODULE_IMPORT_NS() statement close to other module metadata definitions like MODULE_AUTHOR() or MODULE_LICENSE(). diff --git a/Documentation/core-api/workqueue.rst b/Documentation/core-api/workqueue.rst index 165ca73e8351..411e1b28b8de 100644 --- a/Documentation/core-api/workqueue.rst +++ b/Documentation/core-api/workqueue.rst @@ -378,9 +378,9 @@ Affinity Scopes An unbound workqueue groups CPUs according to its affinity scope to improve cache locality. For example, if a workqueue is using the default affinity -scope of "cache", it will group CPUs according to last level cache -boundaries. A work item queued on the workqueue will be assigned to a worker -on one of the CPUs which share the last level cache with the issuing CPU. +scope of "cache_shard", it will group CPUs into sub-LLC shards. A work item +queued on the workqueue will be assigned to a worker on one of the CPUs +within the same shard as the issuing CPU. Once started, the worker may or may not be allowed to move outside the scope depending on the ``affinity_strict`` setting of the scope. @@ -402,7 +402,13 @@ Workqueue currently supports the following affinity scopes. ``cache`` CPUs are grouped according to cache boundaries. Which specific cache boundary is used is determined by the arch code. L3 is used in a lot of - cases. This is the default affinity scope. + cases. + +``cache_shard`` + CPUs are grouped into sub-LLC shards of at most ``wq_cache_shard_size`` + cores (default 8, tunable via the ``workqueue.cache_shard_size`` boot + parameter). Shards are always split on core (SMT group) boundaries. + This is the default affinity scope. ``numa`` CPUs are grouped according to NUMA boundaries. diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst index 4ee667c446f9..705f186d662b 100644 --- a/Documentation/crypto/index.rst +++ b/Documentation/crypto/index.rst @@ -13,6 +13,7 @@ for cryptographic use cases, as well as programming examples. :caption: Table of contents :maxdepth: 2 + libcrypto intro api-intro architecture @@ -27,4 +28,3 @@ for cryptographic use cases, as well as programming examples. descore-readme device_drivers/index krb5 - sha3 diff --git a/Documentation/crypto/libcrypto-blockcipher.rst b/Documentation/crypto/libcrypto-blockcipher.rst new file mode 100644 index 000000000000..dd5ce2f8b515 --- /dev/null +++ b/Documentation/crypto/libcrypto-blockcipher.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Block ciphers +============= + +AES +--- + +Support for the AES block cipher. + +.. kernel-doc:: include/crypto/aes.h + +DES +--- + +Support for the DES block cipher. This algorithm is obsolete and is supported +only for backwards compatibility. + +.. kernel-doc:: include/crypto/des.h diff --git a/Documentation/crypto/libcrypto-hash.rst b/Documentation/crypto/libcrypto-hash.rst new file mode 100644 index 000000000000..4248e6fdc952 --- /dev/null +++ b/Documentation/crypto/libcrypto-hash.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Hash functions, MACs, and XOFs +============================== + +AES-CMAC and AES-XCBC-MAC +------------------------- + +Support for the AES-CMAC and AES-XCBC-MAC message authentication codes. + +.. kernel-doc:: include/crypto/aes-cbc-macs.h + +BLAKE2b +------- + +Support for the BLAKE2b cryptographic hash function. + +.. kernel-doc:: include/crypto/blake2b.h + +BLAKE2s +------- + +Support for the BLAKE2s cryptographic hash function. + +.. kernel-doc:: include/crypto/blake2s.h + +GHASH and POLYVAL +----------------- + +Support for the GHASH and POLYVAL universal hash functions. These algorithms +are used only as internal components of other algorithms. + +.. kernel-doc:: include/crypto/gf128hash.h + +MD5 +--- + +Support for the MD5 cryptographic hash function and HMAC-MD5. This algorithm is +obsolete and is supported only for backwards compatibility. + +.. kernel-doc:: include/crypto/md5.h + +NH +-- + +Support for the NH universal hash function. This algorithm is used only as an +internal component of other algorithms. + +.. kernel-doc:: include/crypto/nh.h + +Poly1305 +-------- + +Support for the Poly1305 universal hash function. This algorithm is used only +as an internal component of other algorithms. + +.. kernel-doc:: include/crypto/poly1305.h + +SHA-1 +----- + +Support for the SHA-1 cryptographic hash function and HMAC-SHA1. This algorithm +is obsolete and is supported only for backwards compatibility. + +.. kernel-doc:: include/crypto/sha1.h + +SHA-2 +----- + +Support for the SHA-2 family of cryptographic hash functions, including SHA-224, +SHA-256, SHA-384, and SHA-512. This also includes their corresponding HMACs: +HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512. + +.. kernel-doc:: include/crypto/sha2.h + +SHA-3 +----- + +The SHA-3 functions are documented in :ref:`sha3`. + +SM3 +--- + +Support for the SM3 cryptographic hash function. + +.. kernel-doc:: include/crypto/sm3.h diff --git a/Documentation/crypto/libcrypto-signature.rst b/Documentation/crypto/libcrypto-signature.rst new file mode 100644 index 000000000000..e80d59fa51b6 --- /dev/null +++ b/Documentation/crypto/libcrypto-signature.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Digital signature algorithms +============================ + +ML-DSA +------ + +Support for the ML-DSA digital signature algorithm. + +.. kernel-doc:: include/crypto/mldsa.h diff --git a/Documentation/crypto/libcrypto-utils.rst b/Documentation/crypto/libcrypto-utils.rst new file mode 100644 index 000000000000..9d833f47ed39 --- /dev/null +++ b/Documentation/crypto/libcrypto-utils.rst @@ -0,0 +1,6 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Utility functions +================= + +.. kernel-doc:: include/crypto/utils.h diff --git a/Documentation/crypto/libcrypto.rst b/Documentation/crypto/libcrypto.rst new file mode 100644 index 000000000000..a1557d45b0e5 --- /dev/null +++ b/Documentation/crypto/libcrypto.rst @@ -0,0 +1,165 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +============== +Crypto library +============== + +``lib/crypto/`` provides faster and easier access to cryptographic algorithms +than the traditional crypto API. + +Each cryptographic algorithm is supported via a set of dedicated functions. +"Crypto agility", where needed, is left to calling code. + +The crypto library functions are intended to be boring and straightforward, and +to follow familiar conventions. Their primary documentation is their (fairly +extensive) kernel-doc. This page just provides some extra high-level context. + +Note that the crypto library isn't entirely new. ``lib/`` has contained some +crypto functions since 2005. Rather, it's just an approach that's been expanded +over time as it's been found to work well. It also largely just matches how the +kernel already does things elsewhere. + +Scope and intended audience +=========================== + +The crypto library documentation is primarily meant for kernel developers who +need to use a particular cryptographic algorithm(s) in kernel code. For +example, "I just need to compute a SHA-256 hash." A secondary audience is +developers working on the crypto algorithm implementations themselves. + +If you're looking for more general information about cryptography, like the +differences between the different crypto algorithms or how to select an +appropriate algorithm, you should refer to external sources which cover that +type of information much more comprehensively. If you need help selecting +algorithms for a new kernel feature that doesn't already have its algorithms +predefined, please reach out to ``linux-crypto@vger.kernel.org`` for advice. + +Code organization +================= + +- ``lib/crypto/*.c``: the crypto algorithm implementations + +- ``lib/crypto/$(SRCARCH)/``: architecture-specific code for crypto algorithms. + It is here rather than somewhere in ``arch/`` partly because this allows + generic and architecture-optimized code to be easily built into a single + loadable module (when the algorithm is set to 'm' in the kconfig). + +- ``lib/crypto/tests/``: KUnit tests for the crypto algorithms + +- ``include/crypto/``: crypto headers, for both the crypto library and the + traditional crypto API + +Generally, there is one kernel module per algorithm. Sometimes related +algorithms are grouped into one module. There is intentionally no common +framework, though there are some utility functions that multiple algorithms use. + +Each algorithm module is controlled by a tristate kconfig symbol +``CRYPTO_LIB_$(ALGORITHM)``. As is the norm for library functions in the +kernel, these are hidden symbols which don't show up in the kconfig menu. +Instead, they are just selected by all the kconfig symbols that need them. + +Many of the algorithms have multiple implementations: a generic implementation +and architecture-optimized implementation(s). Each module initialization +function, or initcall in the built-in case, automatically enables the best +implementation based on the available CPU features. + +Note that the crypto library doesn't use the ``crypto/``, +``arch/$(SRCARCH)/crypto/``, or ``drivers/crypto/`` directories. These +directories are used by the traditional crypto API. When possible, algorithms +in the traditional crypto API are implemented by calls into the library. + +Advantages +========== + +Some of the advantages of the library over the traditional crypto API are: + +- The library functions tend to be much easier to use. For example, a hash + value can be computed using only a single function call. Most of the library + functions always succeed and return void, eliminating the need to write + error-handling code. Most also accept standard virtual addresses, rather than + scatterlists which are difficult and less efficient to work with. + +- The library functions are usually faster, especially for short inputs. They + call the crypto algorithms directly without inefficient indirect calls, memory + allocations, string parsing, lookups in an algorithm registry, and other + unnecessary API overhead. Architecture-optimized code is enabled by default. + +- The library functions use standard link-time dependencies instead of + error-prone dynamic loading by name. There's no need for workarounds such as + forcing algorithms to be built-in or adding module soft dependencies. + +- The library focuses on the approach that works the best on the vast majority + of systems: CPU-based implementations of the crypto algorithms, utilizing + on-CPU acceleration (such as AES instructions) when available. + +- The library uses standard KUnit tests, rather than custom ad-hoc tests. + +- The library tends to have higher assurance implementations of the crypto + algorithms. This is both due to its simpler design and because more of its + code is being regularly tested. + +- The library supports features that don't fit into the rigid framework of the + traditional crypto API, for example interleaved hashing and XOFs. + +When to use it +============== + +In-kernel users should use the library (rather than the traditional crypto API) +whenever possible. Many subsystems have already been converted. It usually +simplifies their code significantly and improves performance. + +Some kernel features allow userspace to provide an arbitrary string that selects +an arbitrary algorithm from the traditional crypto API by name. These features +generally will have to keep using the traditional crypto API for backwards +compatibility. + +Note: new kernel features shouldn't support every algorithm, but rather make a +deliberate choice about what algorithm(s) to support. History has shown that +making a deliberate, thoughtful choice greatly simplifies code maintenance, +reduces the chance for mistakes (such as using an obsolete, insecure, or +inappropriate algorithm), and makes your feature easier to use. + +Testing +======= + +The crypto library uses standard KUnit tests. Like many of the kernel's other +KUnit tests, they are included in the set of tests that is run by +``tools/testing/kunit/kunit.py run --alltests``. + +A ``.kunitconfig`` file is also provided to run just the crypto library tests. +For example, here's how to run them in user-mode Linux: + +.. code-block:: sh + + tools/testing/kunit/kunit.py run --kunitconfig=lib/crypto/ + +Many of the crypto algorithms have architecture-optimized implementations. +Testing those requires building an appropriate kernel and running the tests +either in QEMU or on appropriate hardware. Here's one example with QEMU: + +.. code-block:: sh + + tools/testing/kunit/kunit.py run --kunitconfig=lib/crypto/ --arch=arm64 --make_options LLVM=1 + +Depending on the code being tested, flags may need to be passed to QEMU to +emulate the correct type of hardware for the code to be reached. + +Since correctness is essential in cryptographic code, new architecture-optimized +code is accepted only if it can be tested in QEMU. + +Note: the crypto library also includes FIPS 140 self-tests. These are +lightweight, are designed specifically to meet FIPS 140 requirements, and exist +*only* to meet those requirements. Normal testing done by kernel developers and +integrators should use the much more comprehensive KUnit tests instead. + +API documentation +================= + +.. toctree:: + :maxdepth: 2 + + libcrypto-blockcipher + libcrypto-hash + libcrypto-signature + libcrypto-utils + sha3 diff --git a/Documentation/crypto/sha3.rst b/Documentation/crypto/sha3.rst index 37640f295118..250669c98f6b 100644 --- a/Documentation/crypto/sha3.rst +++ b/Documentation/crypto/sha3.rst @@ -1,5 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0-or-later +.. _sha3: + ========================== SHA-3 Algorithm Collection ========================== diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst index 8158b363cd98..021759198fe7 100644 --- a/Documentation/crypto/userspace-if.rst +++ b/Documentation/crypto/userspace-if.rst @@ -23,7 +23,7 @@ user space, however. This includes the difference between synchronous and asynchronous invocations. The user space API call is fully synchronous. -[1] https://www.chronox.de/libkcapi.html +[1] https://www.chronox.de/libkcapi/index.html User Space API General Remarks ------------------------------ @@ -406,4 +406,4 @@ Please see [1] for libkcapi which provides an easy-to-use wrapper around the aforementioned Netlink kernel interface. [1] also contains a test application that invokes all libkcapi API calls. -[1] https://www.chronox.de/libkcapi.html +[1] https://www.chronox.de/libkcapi/index.html diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst index c714780d458a..b8ecb481ddff 100644 --- a/Documentation/dev-tools/coccinelle.rst +++ b/Documentation/dev-tools/coccinelle.rst @@ -29,12 +29,13 @@ of many distributions, e.g. : - Ubuntu - OpenSUSE - Arch Linux + - Gentoo - NetBSD - FreeBSD Some distribution packages are obsolete and it is recommended to use the latest version released from the Coccinelle homepage at -http://coccinelle.lip6.fr/ +https://coccinelle.gitlabpages.inria.fr/website Or from Github at: @@ -60,7 +61,7 @@ Supplemental documentation For supplemental documentation refer to the wiki: -https://bottest.wiki.kernel.org/coccicheck +https://bottest.wiki.kernel.org/coccicheck.html The wiki documentation always refers to the linux-next version of the script. diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index a034700da7c4..4968b2aa60c8 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -75,9 +75,6 @@ Software Tag-Based KASAN supports slab, page_alloc, vmalloc, and stack memory. Hardware Tag-Based KASAN supports slab, page_alloc, and non-executable vmalloc memory. -For slab, both software KASAN modes support SLUB and SLAB allocators, while -Hardware Tag-Based KASAN only supports SLUB. - Usage ----- diff --git a/Documentation/dev-tools/kfence.rst b/Documentation/dev-tools/kfence.rst index 541899353865..b03d1201ddae 100644 --- a/Documentation/dev-tools/kfence.rst +++ b/Documentation/dev-tools/kfence.rst @@ -81,6 +81,13 @@ tables being allocated. Error reports ~~~~~~~~~~~~~ +The boot parameter ``kfence.fault`` can be used to control the behavior when a +KFENCE error is detected: + +- ``kfence.fault=report``: Print the error report and continue (default). +- ``kfence.fault=oops``: Print the error report and oops. +- ``kfence.fault=panic``: Print the error report and panic. + A typical out-of-bounds access looks like this:: ================================================================== diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml index 13a3a9696821..206686f3eebc 100644 --- a/Documentation/devicetree/bindings/arm/altera.yaml +++ b/Documentation/devicetree/bindings/arm/altera.yaml @@ -84,6 +84,12 @@ properties: - altr,socfpga-stratix10-swvp - const: altr,socfpga-stratix10 + - description: Stratix 10 SoCDK eMMC variant + items: + - const: altr,socfpga-stratix10-socdk-emmc + - const: altr,socfpga-stratix10-socdk + - const: altr,socfpga-stratix10 + - description: AgileX boards items: - enum: @@ -105,6 +111,7 @@ properties: - enum: - intel,socfpga-agilex5-socdk - intel,socfpga-agilex5-socdk-013b + - intel,socfpga-agilex5-socdk-modular - intel,socfpga-agilex5-socdk-nand - const: intel,socfpga-agilex5 diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml index 2a91670ccb8c..949444aba1f8 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml @@ -128,6 +128,9 @@ properties: "#address-cells": const: 1 + access-controllers: + maxItems: 1 + patternProperties: '^trig-conns@([0-9]+)$': type: object diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml index b74db15e5f8a..b0693cd46d27 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml @@ -78,6 +78,9 @@ properties: description: Output connection to CoreSight Trace bus $ref: /schemas/graph.yaml#/properties/port + access-controllers: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml index 71f2e1ed27e5..10ebbbeadf93 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml @@ -118,6 +118,9 @@ properties: description: Output connection from the ETM to CoreSight Trace bus. $ref: /schemas/graph.yaml#/properties/port + access-controllers: + maxItems: 1 + required: - compatible - clocks diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml index 378380c3f5aa..f243e76f597f 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml @@ -73,6 +73,9 @@ properties: description: Output connection to the CoreSight Trace bus. $ref: /schemas/graph.yaml#/properties/port + access-controllers: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml index 96dd5b5f771a..9dc096698c65 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml @@ -128,6 +128,9 @@ properties: - const: tracedata - const: metadata + access-controllers: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml index a207f6899e67..29bbc3961fdf 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml @@ -70,6 +70,9 @@ properties: description: Input connection from the CoreSight Trace bus. $ref: /schemas/graph.yaml#/properties/port + access-controllers: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml b/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml index cff1cdaadb13..48ab3356e383 100644 --- a/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml +++ b/Documentation/devicetree/bindings/arm/arm,corstone1000.yaml @@ -15,11 +15,11 @@ description: |+ provides a flexible compute architecture that combines Cortex‑A and Cortex‑M processors. - Support for Cortex‑A32, Cortex‑A35 and Cortex‑A53 processors. Two expansion - systems for M-Class (or other) processors for adding sensors, connectivity, - video, audio and machine learning at the edge System and security IPs to build - a secure SoC for a range of rich IoT applications, for example gateways, smart - cameras and embedded systems. + Support for Cortex‑A32, Cortex‑A35, Cortex‑A53 and Cortex-A320 processors. + Two expansion systems for M-Class (or other) processors for adding sensors, + connectivity, video, audio and machine learning at the edge System and + security IPs to build a secure SoC for a range of rich IoT applications, for + example gateways, smart cameras and embedded systems. Integrated Secure Enclave providing hardware Root of Trust and supporting seamless integration of the optional CryptoCell™-312 cryptographic @@ -39,6 +39,11 @@ properties: implementation of this system. See ARM ecosystems FVP's. items: - const: arm,corstone1000-fvp + - description: Corstone1000-A320 FVP is the Fixed Virtual Platform + implementation of this system with Cortex-A320 cores and Ethos-U85 + NPU. See ARM ecosystems FVP's. + items: + - const: arm,corstone1000-a320-fvp additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml index ba04576f0ad6..95d4baa85506 100644 --- a/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml +++ b/Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml @@ -119,6 +119,16 @@ properties: items: - const: arm,foundation-aarch64 - const: arm,vexpress + - description: Arm Zena Compute Subsystem Platforms + Arm Zena Compute Subsystem (CSS) is a compute platform targeting + the automotive sector. Arm Zena CSS is a high-performance Arm + Cortex-A720AE Application Processor system augmented with an Arm + Cortex-R82AE based Safety Island and real-time domain. + items: + - enum: + - arm,zena-css-fvp + - const: arm,zena-css + - const: arm,vexpress arm,vexpress,position: description: When daughterboards are stacked on one site, their position diff --git a/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml b/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml new file mode 100644 index 000000000000..9b8f7e0c4ea0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,vexpress-scc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Versatile Express Serial Configuration Controller + +maintainers: + - Liviu Dudau <liviu.dudau@arm.com> + - Sudeep Holla <sudeep.holla@arm.com> + +description: | + Test chips for ARM Versatile Express platform implement SCC (Serial + Configuration Controller) interface, used to set initial conditions + for the test chip. + + In some cases its registers are also mapped in normal address space + and can be used to obtain runtime information about the chip internals + (like silicon temperature sensors) and as interface to other subsystems + like platform configuration control and power management. + +properties: + compatible: + items: + - enum: + - arm,vexpress-scc,v2p-ca15_a7 + - const: arm,vexpress-scc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + scc@7fff0000 { + compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; + reg = <0 0x7fff0000 0 0x1000>; + interrupts = <0 95 4>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml index f9925a14680e..8ec7a3e74a21 100644 --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml @@ -35,6 +35,7 @@ properties: - ampere,mtjade-bmc - aspeed,ast2500-evb - asrock,altrad8-bmc + - asrock,ast2500-paul-ipmi-card - asrock,e3c246d4i-bmc - asrock,e3c256d4i-bmc - asrock,romed8hm3-bmc @@ -80,6 +81,7 @@ properties: - ampere,mtmitchell-bmc - aspeed,ast2600-evb - aspeed,ast2600-evb-a1 + - asus,ast2600-kommando-ipmi-card - asus,x4tf-bmc - facebook,anacapa-bmc - facebook,bletchley-bmc diff --git a/Documentation/devicetree/bindings/arm/atmel,at91rm9200-sdramc.yaml b/Documentation/devicetree/bindings/arm/atmel,at91rm9200-sdramc.yaml new file mode 100644 index 000000000000..ac7e0f454a34 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/atmel,at91rm9200-sdramc.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/atmel,at91rm9200-sdramc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip (Atmel) SDRAM / DDR Controller (RAMC / DDRAMC / UDDRC) + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Claudiu Beznea <claudiu.beznea@tuxon.dev> + +description: + The SDRAM/DDR Controller (often called RAMC or DDRAMC) in various + Atmel/Microchip ARM9 and Cortex-A5/A7 SoCs manages external + SDRAM / DDR memory. It is typically exposed as a syscon node for + register access from other drivers (e.g. for initialization or mode + configuration). No interrupts or clocks are usually required in the + binding. + +properties: + compatible: + oneOf: + - items: + - const: atmel,at91rm9200-sdramc + - const: syscon + - items: + - const: microchip,sama7d65-uddrc + - const: microchip,sama7g5-uddrc + - enum: + - atmel,at91sam9260-sdramc + - atmel,at91sam9g45-ddramc + - atmel,sama5d3-ddramc + - microchip,sam9x60-ddramc + - microchip,sam9x7-ddramc + - microchip,sama7g5-uddrc + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: ddrck + - const: mpddr + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/at91.h> + ramc@ffffe400 { + compatible = "atmel,at91sam9g45-ddramc"; + reg = <0xffffe400 0x200>; + clocks = <&pmc PMC_TYPE_SYSTEM 2>; + clock-names = "ddrck"; + }; +... diff --git a/Documentation/devicetree/bindings/arm/atmel,at91rm9200-st.yaml b/Documentation/devicetree/bindings/arm/atmel,at91rm9200-st.yaml new file mode 100644 index 000000000000..3f6a934a2a69 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/atmel,at91rm9200-st.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/atmel,at91rm9200-st.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel System Timer + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Claudiu Beznea <claudiu.beznea@tuxon.dev> + +description: + The System Timer (ST) module in AT91RM9200 provides periodic tick and + alarm capabilities. It is exposed as a simple multi-function device + (simple-mfd + syscon) because it shares its register space and interrupt + with other System Controller blocks. + +properties: + compatible: + items: + - const: atmel,at91rm9200-st + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + +patternProperties: + "^watchdog@[0-9a-f]+$": + $ref: /schemas/watchdog/atmel,at91rm9200-wdt.yaml# + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + timer@fffffd00 { + compatible = "atmel,at91rm9200-st", "syscon", "simple-mfd"; + reg = <0xfffffd00 0x100>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; + clocks = <&slow_xtal>; + #address-cells = <1>; + #size-cells = <1>; + + watchdog@fffffd40 { + compatible = "atmel,at91rm9200-wdt"; + reg = <0xfffffd40 0x40>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/atmel,at91sam9260-pit.yaml b/Documentation/devicetree/bindings/arm/atmel,at91sam9260-pit.yaml new file mode 100644 index 000000000000..d1bdc4a4f9e0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/atmel,at91sam9260-pit.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/atmel,at91sam9260-pit.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel AT91SAM9260 Periodic Interval Timer (PIT) + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Claudiu Beznea <claudiu.beznea@tuxon.dev> + +description: + The Periodic Interval Timer (PIT) is part of the System Controller of + various Microchip 32-bit ARM-based SoCs (formerly Atmel AT91 series). + It is a simple down-counter timer used mainly as the kernel tick source. + The PIT is clocked from the slow clock and shares a single IRQ line with + other System Controller peripherals. + +properties: + compatible: + const: atmel,at91sam9260-pit + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + timer@fffffd30 { + compatible = "atmel,at91sam9260-pit"; + reg = <0xfffffd30 0x10>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk32k>; + }; +... diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml index 68d306d17c2a..bf161e0950ea 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml @@ -243,6 +243,12 @@ properties: - const: microchip,lan9668 - const: microchip,lan966 + - description: Microchip LAN9696 EV23X71A Evaluation Board + items: + - const: microchip,ev23x71a + - const: microchip,lan9696 + - const: microchip,lan9691 + - description: Kontron KSwitch D10 MMT series items: - enum: diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt deleted file mode 100644 index 5ce54f9befe6..000000000000 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ /dev/null @@ -1,48 +0,0 @@ -Atmel system registers - -Chipid required properties: -- compatible: Should be "atmel,sama5d2-chipid" or "microchip,sama7g5-chipid" - "microchip,sama7d65-chipid" -- reg : Should contain registers location and length - -PIT Timer required properties: -- compatible: Should be "atmel,at91sam9260-pit" -- reg: Should contain registers location and length -- interrupts: Should contain interrupt for the PIT which is the IRQ line - shared across all System Controller members. - -PIT64B Timer required properties: -- compatible: Should be "microchip,sam9x60-pit64b" or - "microchip,sam9x7-pit64b", "microchip,sam9x60-pit64b" - "microchip,sama7d65-pit64b", "microchip,sam9x60-pit64b" -- reg: Should contain registers location and length -- interrupts: Should contain interrupt for PIT64B timer -- clocks: Should contain the available clock sources for PIT64B timer. - -System Timer (ST) required properties: -- compatible: Should be "atmel,at91rm9200-st", "syscon", "simple-mfd" -- reg: Should contain registers location and length -- interrupts: Should contain interrupt for the ST which is the IRQ line - shared across all System Controller members. -- clocks: phandle to input clock. -Its subnodes can be: -- watchdog: compatible should be "atmel,at91rm9200-wdt" - -RAMC SDRAM/DDR Controller required properties: -- compatible: Should be "atmel,at91rm9200-sdramc", "syscon" or - "atmel,at91sam9260-sdramc" or - "atmel,at91sam9g45-ddramc" or - "atmel,sama5d3-ddramc" or - "microchip,sam9x60-ddramc" or - "microchip,sama7g5-uddrc" or - "microchip,sama7d65-uddrc", "microchip,sama7g5-uddrc" or - "microchip,sam9x7-ddramc", "atmel,sama5d3-ddramc". -- reg: Should contain registers location and length - -Examples: - - ramc0: ramc@ffffe800 { - compatible = "atmel,at91sam9g45-ddramc"; - reg = <0xffffe800 0x200>; - }; - diff --git a/Documentation/devicetree/bindings/arm/axis.yaml b/Documentation/devicetree/bindings/arm/axis.yaml index 63e9aca85db7..3062901196a6 100644 --- a/Documentation/devicetree/bindings/arm/axis.yaml +++ b/Documentation/devicetree/bindings/arm/axis.yaml @@ -31,6 +31,12 @@ properties: - axis,artpec8-grizzly - const: axis,artpec8 + - description: Axis ARTPEC-9 SoC board + items: + - enum: + - axis,artpec9-alfred + - const: axis,artpec9 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 736b7ab1bd0a..5f5ff5e51e51 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -79,149 +79,162 @@ properties: All other bits in the reg cells must be set to 0. compatible: - enum: - - apm,potenza - - apm,strega - - apple,avalanche - - apple,blizzard - - apple,cyclone - - apple,firestorm - - apple,hurricane-zephyr - - apple,icestorm - - apple,mistral - - apple,monsoon - - apple,twister - - apple,typhoon - - arm,arm710t - - arm,arm720t - - arm,arm740t - - arm,arm7ej-s - - arm,arm7tdmi - - arm,arm7tdmi-s - - arm,arm9es - - arm,arm9ej-s - - arm,arm920t - - arm,arm922t - - arm,arm925 - - arm,arm926e-s - - arm,arm926ej-s - - arm,arm940t - - arm,arm946e-s - - arm,arm966e-s - - arm,arm968e-s - - arm,arm9tdmi - - arm,arm1020e - - arm,arm1020t - - arm,arm1022e - - arm,arm1026ej-s - - arm,arm1136j-s - - arm,arm1136jf-s - - arm,arm1156t2-s - - arm,arm1156t2f-s - - arm,arm1176jzf - - arm,arm1176jz-s - - arm,arm1176jzf-s - - arm,arm11mpcore - - arm,armv8 # Only for s/w models - - arm,c1-nano - - arm,c1-premium - - arm,c1-pro - - arm,c1-ultra - - arm,cortex-a5 - - arm,cortex-a7 - - arm,cortex-a8 - - arm,cortex-a9 - - arm,cortex-a12 - - arm,cortex-a15 - - arm,cortex-a17 - - arm,cortex-a32 - - arm,cortex-a34 - - arm,cortex-a35 - - arm,cortex-a53 - - arm,cortex-a55 - - arm,cortex-a57 - - arm,cortex-a65 - - arm,cortex-a72 - - arm,cortex-a73 - - arm,cortex-a75 - - arm,cortex-a76 - - arm,cortex-a77 - - arm,cortex-a78 - - arm,cortex-a78ae - - arm,cortex-a78c - - arm,cortex-a320 - - arm,cortex-a510 - - arm,cortex-a520 - - arm,cortex-a520ae - - arm,cortex-a710 - - arm,cortex-a715 - - arm,cortex-a720 - - arm,cortex-a720ae - - arm,cortex-a725 - - arm,cortex-m0 - - arm,cortex-m0+ - - arm,cortex-m1 - - arm,cortex-m3 - - arm,cortex-m4 - - arm,cortex-r4 - - arm,cortex-r5 - - arm,cortex-r7 - - arm,cortex-r52 - - arm,cortex-x1 - - arm,cortex-x1c - - arm,cortex-x2 - - arm,cortex-x3 - - arm,cortex-x4 - - arm,cortex-x925 - - arm,neoverse-e1 - - arm,neoverse-n1 - - arm,neoverse-n2 - - arm,neoverse-n3 - - arm,neoverse-v1 - - arm,neoverse-v2 - - arm,neoverse-v3 - - arm,neoverse-v3ae - - arm,rainier - - brcm,brahma-b15 - - brcm,brahma-b53 - - brcm,vulcan - - cavium,thunder - - cavium,thunder2 - - faraday,fa526 - - intel,sa110 - - intel,sa1100 - - marvell,feroceon - - marvell,mohawk - - marvell,pj4a - - marvell,pj4b - - marvell,sheeva-v5 - - marvell,sheeva-v7 - - nvidia,tegra132-denver - - nvidia,tegra186-denver - - nvidia,tegra194-carmel - - qcom,krait - - qcom,kryo - - qcom,kryo240 - - qcom,kryo250 - - qcom,kryo260 - - qcom,kryo280 - - qcom,kryo360 - - qcom,kryo385 - - qcom,kryo465 - - qcom,kryo468 - - qcom,kryo470 - - qcom,kryo485 - - qcom,kryo560 - - qcom,kryo570 - - qcom,kryo660 - - qcom,kryo670 - - qcom,kryo685 - - qcom,kryo780 - - qcom,oryon - - qcom,scorpion - - samsung,mongoose-m2 - - samsung,mongoose-m3 - - samsung,mongoose-m5 + oneOf: + - enum: + - apm,potenza + - apm,strega + - apple,avalanche + - apple,blizzard + - apple,cyclone + - apple,everest + - apple,firestorm + - apple,hurricane-zephyr + - apple,icestorm + - apple,mistral + - apple,monsoon + - apple,sawtooth + - apple,twister + - apple,typhoon + - arm,arm710t + - arm,arm720t + - arm,arm740t + - arm,arm7ej-s + - arm,arm7tdmi + - arm,arm7tdmi-s + - arm,arm9es + - arm,arm9ej-s + - arm,arm920t + - arm,arm922t + - arm,arm925 + - arm,arm926e-s + - arm,arm926ej-s + - arm,arm940t + - arm,arm946e-s + - arm,arm966e-s + - arm,arm968e-s + - arm,arm9tdmi + - arm,arm1020e + - arm,arm1020t + - arm,arm1022e + - arm,arm1026ej-s + - arm,arm1136j-s + - arm,arm1136jf-s + - arm,arm1156t2-s + - arm,arm1156t2f-s + - arm,arm1176jzf + - arm,arm1176jz-s + - arm,arm1176jzf-s + - arm,arm11mpcore + - arm,armv8 # Only for s/w models + - arm,c1-nano + - arm,c1-premium + - arm,c1-pro + - arm,c1-ultra + - arm,cortex-a5 + - arm,cortex-a7 + - arm,cortex-a8 + - arm,cortex-a9 + - arm,cortex-a12 + - arm,cortex-a15 + - arm,cortex-a17 + - arm,cortex-a32 + - arm,cortex-a34 + - arm,cortex-a35 + - arm,cortex-a53 + - arm,cortex-a55 + - arm,cortex-a57 + - arm,cortex-a65 + - arm,cortex-a72 + - arm,cortex-a73 + - arm,cortex-a75 + - arm,cortex-a76 + - arm,cortex-a77 + - arm,cortex-a78 + - arm,cortex-a78ae + - arm,cortex-a78c + - arm,cortex-a320 + - arm,cortex-a510 + - arm,cortex-a520 + - arm,cortex-a520ae + - arm,cortex-a710 + - arm,cortex-a715 + - arm,cortex-a720 + - arm,cortex-a720ae + - arm,cortex-a725 + - arm,cortex-m0 + - arm,cortex-m0+ + - arm,cortex-m1 + - arm,cortex-m3 + - arm,cortex-m4 + - arm,cortex-r4 + - arm,cortex-r5 + - arm,cortex-r7 + - arm,cortex-r52 + - arm,cortex-x1 + - arm,cortex-x1c + - arm,cortex-x2 + - arm,cortex-x3 + - arm,cortex-x4 + - arm,cortex-x925 + - arm,neoverse-e1 + - arm,neoverse-n1 + - arm,neoverse-n2 + - arm,neoverse-n3 + - arm,neoverse-v1 + - arm,neoverse-v2 + - arm,neoverse-v3 + - arm,neoverse-v3ae + - arm,rainier + - brcm,brahma-b15 + - brcm,brahma-b53 + - brcm,vulcan + - cavium,thunder + - cavium,thunder2 + - faraday,fa526 + - intel,sa110 + - intel,sa1100 + - marvell,feroceon + - marvell,mohawk + - marvell,pj4a + - marvell,pj4b + - marvell,sheeva-v5 + - marvell,sheeva-v7 + - nvidia,tegra132-denver + - nvidia,tegra186-denver + - nvidia,tegra194-carmel + - qcom,krait + - qcom,kryo240 + - qcom,kryo250 + - qcom,kryo260 + - qcom,kryo280 + - qcom,kryo360 + - qcom,kryo385 + - qcom,kryo465 + - qcom,kryo468 + - qcom,kryo470 + - qcom,kryo485 + - qcom,kryo560 + - qcom,kryo570 + - qcom,kryo660 + - qcom,kryo670 + - qcom,kryo685 + - qcom,kryo780 + - qcom,oryon-1-1 + - qcom,oryon-1-2 + - qcom,oryon-1-3 + - qcom,oryon-1-4 + - qcom,oryon-2-1 + - qcom,oryon-2-2 + - qcom,oryon-2-3 + - qcom,scorpion + - samsung,mongoose-m2 + - samsung,mongoose-m3 + - samsung,mongoose-m5 + - enum: + - qcom,kryo + - qcom,oryon + # Too generic, do not use in new code + deprecated: true enable-method: $ref: /schemas/types.yaml#/definitions/string diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,imx51-m4if.yaml b/Documentation/devicetree/bindings/arm/freescale/fsl,imx51-m4if.yaml index 1f515bea3959..6130b048de7b 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,imx51-m4if.yaml +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx51-m4if.yaml @@ -15,6 +15,7 @@ properties: compatible: oneOf: - enum: + - fsl,imx25-aips - fsl,imx51-m4if - fsl,imx51-tigerp - fsl,imx51-aipstz diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml index 9d377e193c12..7ad470260c0d 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.yaml @@ -28,6 +28,9 @@ properties: reg: maxItems: 1 + '#clock-cells': + const: 1 + clocks: maxItems: 2 @@ -39,6 +42,7 @@ properties: required: - compatible - reg + - '#clock-cells' additionalProperties: false @@ -47,4 +51,5 @@ examples: smc1@40410000 { compatible = "fsl,imx7ulp-smc1"; reg = <0x40410000 0x1000>; + #clock-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 5716d701292c..0023cd126807 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -996,6 +996,14 @@ properties: - const: engicam,icore-mx8mm # i.MX8MM Engicam i.Core MX8M Mini SoM - const: fsl,imx8mm + - description: Ka-Ro Electronics TX8M-1610 based boards + items: + - enum: + - gocontroll,moduline-iv-306-d + - gocontroll,moduline-mini-111 + - const: karo,tx8m-1610 + - const: fsl,imx8mm + - description: Kontron BL i.MX8MM (N801X S) Board items: - const: kontron,imx8mm-bl @@ -1041,6 +1049,13 @@ properties: - const: phytec,imx8mm-phycore-som # phyCORE-i.MX8MM SoM - const: fsl,imx8mm + - description: SolidRun i.MX8MM SoM based boards + items: + - enum: + - solidrun,imx8mm-hummingboard-ripple # SolidRun i.MX8MM SoM on HummingBoard Ripple + - const: solidrun,imx8mm-sr-som + - const: fsl,imx8mm + - description: Variscite VAR-SOM-MX8MM based boards items: - const: variscite,var-som-mx8mm-symphony @@ -1069,6 +1084,7 @@ properties: - fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board - fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board - gw,imx8mn-gw7902 # i.MX8MM Gateworks Board + - solidrun,solidsense-n8-compact # SolidRun SolidSense N8 Compact - const: fsl,imx8mn - description: ifm i.MX8MN VHIP4 based boards @@ -1106,6 +1122,7 @@ properties: - beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit - dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC - emcraft,imx8mp-navqp # i.MX8MP Emcraft Systems NavQ+ Kit + - fsl,imx8mp-ab2 # i.MX8MP Audio Board V2 - fsl,imx8mp-evk # i.MX8MP EVK Board - fsl,imx8mp-evk-revb4 # i.MX8MP EVK Rev B4 Board - fsl,imx8mp-frdm # i.MX8MP Freedom Board @@ -1225,6 +1242,7 @@ properties: items: - enum: - solidrun,imx8mp-cubox-m # SolidRun i.MX8MP SoM on CuBox-M + - solidrun,imx8mp-hummingboard-iiot # SolidRun i.MX8MP SoM on HummingBoard IIoT - solidrun,imx8mp-hummingboard-mate # SolidRun i.MX8MP SoM on HummingBoard Mate - solidrun,imx8mp-hummingboard-pro # SolidRun i.MX8MP SoM on HummingBoard Pro - solidrun,imx8mp-hummingboard-pulse # SolidRun i.MX8MP SoM on HummingBoard Pulse @@ -1420,6 +1438,16 @@ properties: - const: tq,imx8dxp-tqma8xdps # TQ-Systems GmbH TQMa8XDPS SOM - const: fsl,imx8dxp + - description: + TQMa8x is a series of SOM featuring NXP i.MX8 system-on-chip + variants. It is designed to be clicked on different carrier boards + MBa8x is the starterkit + items: + - enum: + - tq,imx8qm-tqma8qm-mba8x # TQ-Systems GmbH TQMa8QM SOM on MBa8x + - const: tq,imx8qm-tqma8qm # TQ-Systems GmbH TQMa8QM SOM + - const: fsl,imx8qm + - description: i.MX8ULP based Boards items: - enum: @@ -1432,6 +1460,7 @@ properties: - enum: - fsl,imx91-11x11-evk # i.MX91 11x11 EVK Board - fsl,imx91-11x11-frdm # FRDM i.MX91 Development Board + - fsl,imx91-11x11-frdm-s # FRDM i.MX91S Development Board - const: fsl,imx91 - description: i.MX93 based Boards @@ -1441,6 +1470,7 @@ properties: - fsl,imx93-11x11-evk # i.MX93 11x11 EVK Board - fsl,imx93-11x11-frdm # i.MX93 11x11 FRDM Board - fsl,imx93-14x14-evk # i.MX93 14x14 EVK Board + - fsl,imx93-wireless-evk # i.MX93 and IW610G WLCSP (Wi-Fi + BLE + 802.15.4) SiP EVK Board - const: fsl,imx93 - description: i.MX94 based Boards @@ -1477,6 +1507,36 @@ properties: - const: toradex,smarc-imx95 # Toradex SMARC iMX95 Module - const: fsl,imx95 + - description: Toradex Boards with Verdin iMX95 Modules + items: + - enum: + - toradex,verdin-imx95-nonwifi-dahlia # Verdin iMX95 Module on Dahlia + - toradex,verdin-imx95-nonwifi-dev # Verdin iMX95 Module on Verdin Development Board + - toradex,verdin-imx95-nonwifi-ivy # Verdin iMX95 Module on Ivy + - toradex,verdin-imx95-nonwifi-mallow # Verdin iMX95 Module on Mallow + - toradex,verdin-imx95-nonwifi-yavia # Verdin iMX95 Module on Yavia + - const: toradex,verdin-imx95-nonwifi # Verdin iMX95 Module without Wi-Fi / BT + - const: toradex,verdin-imx95 # Verdin iMX95 Module + - const: fsl,imx95 + + - description: Toradex Boards with Verdin iMX95 Wi-Fi / BT Modules + items: + - enum: + - toradex,verdin-imx95-wifi-dahlia # Verdin iMX95 Wi-Fi / BT Module on Dahlia + - toradex,verdin-imx95-wifi-dev # Verdin iMX95 Wi-Fi / BT Module on Verdin Development B. + - toradex,verdin-imx95-wifi-ivy # Verdin iMX95 Wi-Fi / BT Module on Ivy + - toradex,verdin-imx95-wifi-mallow # Verdin iMX95 Wi-Fi / BT Module on Mallow + - toradex,verdin-imx95-wifi-yavia # Verdin iMX95 Wi-Fi / BT Module on Yavia + - const: toradex,verdin-imx95-wifi # Verdin iMX95 Wi-Fi / BT Module + - const: toradex,verdin-imx95 # Verdin iMX95 Module + - const: fsl,imx95 + + - description: Variscite DART-MX95 based Boards + items: + - const: variscite,var-dart-mx95-sonata # Variscite DART-MX95 SOM on Sonata Development Board + - const: variscite,var-dart-mx95 # Variscite DART-MX95 SOM + - const: fsl,imx95 + - description: i.MXRT1050 based Boards items: - enum: @@ -1522,11 +1582,14 @@ properties: soldered on an adapter board or for the connector variant MBa93xxLA mainboard is a single board computer using the solderable SOM variant + MBa93xxLA-MINI mainboard is a single board computer using the solderable + SOM variant items: - enum: - tq,imx93-tqma9352-mba91xxca # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM on MBa91xxCA - tq,imx93-tqma9352-mba93xxca # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM on MBa93xxCA - tq,imx93-tqma9352-mba93xxla # TQ-Systems GmbH i.MX93 TQMa93xxLA SOM on MBa93xxLA SBC + - tq,imx93-tqma9352-mba93xxla-mini # TQ-Systems GmbH i.MX93 TQMa93xxLA SOM on MBa93xxLA-MINI SBC - const: tq,imx93-tqma9352 # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM - const: fsl,imx93 @@ -1545,6 +1608,12 @@ properties: - const: phytec,imx93-phycore-som # phyCORE-i.MX93 SoM - const: fsl,imx93 + - description: Variscite DART-MX91 based boards + items: + - const: variscite,var-dart-mx91-sonata # Variscite DART-MX91 on Sonata Development Board + - const: variscite,var-dart-mx91 # Variscite DART-MX91 SOM + - const: fsl,imx91 + - description: Variscite VAR-SOM-MX93 based boards items: - const: variscite,var-som-mx93-symphony @@ -1558,6 +1627,17 @@ properties: - const: fsl,imx93 - description: + TQMa95xxLA is a series of SOM featuring NXP i.MX95 SoC variants, + designed to be soldered on different carrier boards. + MBa95xxCA is a carrier reference design / starter kit that allows + to use TQMa95xxLA via an adaper board. + items: + - enum: + - tq,imx95-tqma9596la-mba95xxca # TQ-Systems GmbH i.MX95 TQMa95xxLA SOM on MBa95xxCA + - const: tq,imx95-tqma9596la # TQ-Systems GmbH i.MX95 TQMa95xxLA SOM + - const: fsl,imx95 + + - description: TQMa95xxSA is a series of SOM featuring NXP i.MX95 SoC variants. It has the SMARC form factor and is designed to be placed on different carrier boards. MB-SMARC-2 is a carrier reference design. @@ -1827,6 +1907,12 @@ properties: - fsl,s32v234-evb # S32V234-EVB2 Customer Evaluation Board - const: fsl,s32v234 + - description: S32N79 based Boards + items: + - enum: + - nxp,s32n79-rdb + - const: nxp,s32n79 + - description: Traverse LS1088A based Boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml index 09a6c16e7e82..9aa39b002361 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml @@ -49,38 +49,37 @@ required: - '#clock-cells' allOf: - - if: - properties: - compatible: - contains: - enum: - - mediatek,mt2701-audsys - - mediatek,mt7622-audsys - then: - properties: - audio-controller: - $ref: /schemas/sound/mediatek,mt2701-audio.yaml# - - - if: - properties: - compatible: - contains: - const: mediatek,mt8183-audiosys - then: - properties: - audio-controller: - $ref: /schemas/sound/mediatek,mt8183-audio.yaml# - - - if: - properties: - compatible: - contains: - const: mediatek,mt8192-audsys - then: - properties: - audio-controller: - $ref: /schemas/sound/mt8192-afe-pcm.yaml# - + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt2701-audsys + - mediatek,mt7622-audsys + then: + properties: + audio-controller: + $ref: /schemas/sound/mediatek,mt2701-audio.yaml# + + - if: + properties: + compatible: + contains: + const: mediatek,mt8183-audiosys + then: + properties: + audio-controller: + $ref: /schemas/sound/mediatek,mt8183-audio.yaml# + + - if: + properties: + compatible: + contains: + const: mediatek,mt8192-audsys + then: + properties: + audio-controller: + $ref: /schemas/sound/mt8192-afe-pcm.yaml# additionalProperties: false diff --git a/Documentation/devicetree/bindings/arm/microchip,sam9x60-pit64b.yaml b/Documentation/devicetree/bindings/arm/microchip,sam9x60-pit64b.yaml new file mode 100644 index 000000000000..802cf2424c42 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/microchip,sam9x60-pit64b.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/microchip,sam9x60-pit64b.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip PIT64B 64-bit Periodic Interval Timer + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Claudiu Beznea <claudiu.beznea@tuxon.dev> + +description: + The Microchip PIT64B is a 64-bit periodic interval timer used in + several modern Microchip ARM SoCs including SAM9X60, SAM9X7 and + SAMA7D65 families. It provides extended timing range, flexible + clock selection and supports both periodic and one-shot interrupt + generation modes. + +properties: + compatible: + oneOf: + - const: microchip,sam9x60-pit64b + - items: + - enum: + - microchip,sam9x7-pit64b + - microchip,sama7d65-pit64b + - microchip,sama7g5-pit64b + - const: microchip,sam9x60-pit64b + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + enum: + - pclk + - gclk + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/at91.h> + timer@f0028000 { + compatible = "microchip,sama7g5-pit64b", "microchip,sam9x60-pit64b"; + reg = <0xf0028000 0x100>; + interrupts = <37 IRQ_TYPE_LEVEL_HIGH 7>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 37>, <&pmc PMC_TYPE_GCK 37>; + clock-names = "pclk", "gclk"; + }; +... diff --git a/Documentation/devicetree/bindings/arm/microchip,sama7g5-chipid.yaml b/Documentation/devicetree/bindings/arm/microchip,sama7g5-chipid.yaml new file mode 100644 index 000000000000..4d6442ba5ac9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/microchip,sama7g5-chipid.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/microchip,sama7g5-chipid.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel/Microchip RAMC SDRAM/DDR Controller + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Claudiu Beznea <claudiu.beznea@tuxon.dev> + +description: + This binding describes the Atmel/Microchip Chip ID register block used + for SoC identification and revision information. It requires compatible + strings matching specific SoC families and a reg property defining the + register address and size. + +properties: + compatible: + enum: + - atmel,sama5d2-chipid + - microchip,sama7d65-chipid + - microchip,sama7g5-chipid + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + chipid@fc069000 { + compatible = "atmel,sama5d2-chipid"; + reg = <0xfc069000 0x8>; + }; +... diff --git a/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml b/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml index 6b7f5e6f99cf..1e290f16a7a5 100644 --- a/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml +++ b/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml @@ -22,5 +22,27 @@ properties: - phytec,phy3250 - const: nxp,lpc3250 + - items: + - enum: + - ea,lpc4357-developers-kit + - const: nxp,lpc4357 + - const: nxp,lpc4350 + + - items: + - enum: + - ciaa,lpc4337 + - const: nxp,lpc4337 + - const: nxp,lpc4350 + + - items: + - enum: + - hitex,lpc4350-eval-board + - const: nxp,lpc4350 + + - items: + - enum: + - myir,myd-lpc4357 + - const: nxp,lpc4357 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index d48c625d3fc4..b4943123d2e4 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -63,6 +63,21 @@ properties: - items: - enum: + - qcom,eliza-mtp + - const: qcom,eliza + + - items: + - enum: + - qcom,glymur-crd + - const: qcom,glymur + + - items: + - enum: + - qcom,mahua-crd + - const: qcom,mahua + + - items: + - enum: - fairphone,fp6 - const: qcom,milos @@ -171,6 +186,7 @@ properties: - qcom,msm8916-mtp - samsung,a3u-eur - samsung,a5u-eur + - samsung,coreprimeltevzw - samsung,e5 - samsung,e7 - samsung,fortuna3g @@ -186,6 +202,7 @@ properties: - samsung,serranove - thwc,uf896 - thwc,ufi001c + - wiko,chuppito - wingtech,wt86518 - wingtech,wt86528 - wingtech,wt88047 @@ -195,6 +212,8 @@ properties: - items: - enum: - xiaomi,riva + - xiaomi,rolex + - xiaomi,tiare - const: qcom,msm8917 - items: @@ -244,6 +263,13 @@ properties: - const: qcom,apq8096 - items: + - const: arrow,apq8096sg-db820c + - const: arrow,apq8096-db820c + - const: qcom,apq8096-sbc + - const: qcom,apq8096sg + - const: qcom,apq8096 + + - items: - enum: - oneplus,oneplus3 - oneplus,oneplus3t @@ -299,6 +325,11 @@ properties: - items: - enum: + - qcom,ipq5210-rdp504 + - const: qcom,ipq5210 + + - items: + - enum: - qcom,ipq5332-ap-mi01.2 - qcom,ipq5332-ap-mi01.3 - qcom,ipq5332-ap-mi01.6 @@ -326,8 +357,10 @@ properties: - items: - enum: - qcom,ipq9574-ap-al02-c2 + - qcom,ipq9574-ap-al02-c2-emmc - qcom,ipq9574-ap-al02-c6 - qcom,ipq9574-ap-al02-c7 + - qcom,ipq9574-ap-al02-c7-emmc - qcom,ipq9574-ap-al02-c8 - qcom,ipq9574-ap-al02-c9 - const: qcom,ipq9574 @@ -360,6 +393,7 @@ properties: - qcom,qcs6490-rb3gen2 - radxa,dragon-q6a - shift,otter + - thundercomm,minipc-g1iot - thundercomm,rubikpi3 - const: qcom,qcm6490 @@ -385,6 +419,7 @@ properties: - items: - enum: - acer,aspire1 + - ecs,liva-qc710 - qcom,sc7180-idp - const: qcom,sc7180 @@ -846,6 +881,12 @@ properties: - items: - enum: + - google,bonito-tianma + - const: google,bonito + - const: qcom,sdm670 + + - items: + - enum: - qcom,sdx55-mtp - qcom,sdx55-telit-fn980-tlb - qcom,sdx55-t55 @@ -876,6 +917,7 @@ properties: - items: - enum: + - arduino,monza - qcom,monaco-evk - qcom,qcs8300-ride - const: qcom,qcs8300 @@ -883,6 +925,7 @@ properties: - items: - enum: - qcom,qcs615-ride + - qcom,talos-evk - const: qcom,qcs615 - const: qcom,sm6150 @@ -966,6 +1009,7 @@ properties: - sony,pdx201 - xiaomi,ginkgo - xiaomi,laurel-sprout + - xiaomi,willow - const: qcom,sm6125 - items: @@ -1057,6 +1101,7 @@ properties: - items: - enum: + - ayaneo,pocket-s2 - qcom,sm8650-hdk - qcom,sm8650-mtp - qcom,sm8650-qrd @@ -1104,6 +1149,7 @@ properties: - dell,xps13-9345 - hp,elitebook-ultra-g1q - hp,omnibook-x14 + - lenovo,ideacentre-mini-01q8x10 - lenovo,yoga-slim7x - microsoft,romulus13 - microsoft,romulus15 @@ -1124,6 +1170,12 @@ properties: - items: - enum: + - qcom,purwa-iot-evk + - const: qcom,purwa-iot-som + - const: qcom,x1p42100 + + - items: + - enum: - asus,zenbook-a14-ux3407qa-lcd - asus,zenbook-a14-ux3407qa-oled - const: asus,zenbook-a14-ux3407qa @@ -1131,6 +1183,7 @@ properties: - items: - enum: + - asus,vivobook-s15-x1p4 - hp,omnibook-x14-fe1 - lenovo,thinkbook-16 - qcom,x1p42100-crd diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index ae77ded9fe47..1a9dde18626d 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -754,6 +754,11 @@ properties: - const: khadas,edge2 - const: rockchip,rk3588s + - description: Khadas Edge-2L series boards + items: + - const: khadas,edge-2l + - const: rockchip,rk3576 + - description: Kobol Helios64 items: - const: kobol,helios64 @@ -808,11 +813,22 @@ properties: - const: netxeon,r89 - const: rockchip,rk3288 + - description: Onion Omega4 Evaluation board + items: + - const: onion,omega4-evb + - const: onion,omega4 + - const: rockchip,rv1103b + - description: OPEN AI LAB EAIDK-610 items: - const: openailab,eaidk-610 - const: rockchip,rk3399 + - description: OneThing Edge Cube series + items: + - const: onething,edge-cube + - const: rockchip,rk3566 + - description: Xunlong Orange Pi RK3399 board items: - const: xunlong,rk3399-orangepi @@ -1187,7 +1203,9 @@ properties: - description: Rockchip RK3576 Evaluation board items: - - const: rockchip,rk3576-evb1-v10 + - enum: + - rockchip,rk3576-evb1-v10 + - rockchip,rk3576-evb2-v10 - const: rockchip,rk3576 - description: Rockchip RK3588 Evaluation board diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index f8e20e602c20..753b3ba1b607 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml @@ -117,6 +117,7 @@ properties: - description: Exynos5250 based boards items: - enum: + - google,manta # Google Manta (Nexus 10) - google,snow-rev5 # Google Snow Rev 5+ - google,spring # Google Spring - insignal,arndale # Insignal Arndale @@ -216,7 +217,9 @@ properties: items: - enum: - samsung,a2corelte # Samsung Galaxy A2 Core + - samsung,j5y17lte # Samsung Galaxy J5 (2017) - samsung,j6lte # Samsung Galaxy J6 + - samsung,j7xelte # Samsung Galaxy J7 (2016) - samsung,on7xelte # Samsung Galaxy J7 Prime - const: samsung,exynos7870 diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index ad144c02eb7e..c6af3a46364f 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -183,10 +183,12 @@ properties: - const: seeed,stm32mp157c-odyssey-som - const: st,stm32mp157 - - description: Phytec STM32MP1 SoM based Boards + - description: Phytec STM32MP157 SoM based Boards items: - - const: phytec,phycore-stm32mp1-3 - - const: phytec,phycore-stm32mp157c-som + - enum: + - phytec,phycore-stm32mp1-3 # phyBOARD-Sargas with phyCORE-STM32MP157C SoM + - enum: + - phytec,phycore-stm32mp157c-som # phyCORE-STM32MP157C SoM - const: st,stm32mp157 - description: Ultratronik STM32MP1 SBC based Boards diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 9e4627f97d7e..e6443c266fa1 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -901,6 +901,11 @@ properties: - const: allwinner,sl631 - const: allwinner,sun8i-v3 + - description: TaiqiCat A01 + items: + - const: ultrapower,taiqicat-a01 + - const: allwinner,sun50i-h6 + - description: Tanix TX1 items: - const: oranth,tanix-tx1 diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 50a31dba7bec..033a63f6c068 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -132,6 +132,33 @@ properties: - const: toradex,apalis-tk1 - const: nvidia,tegra124 - items: + - const: google,nyan-big-rev7 + - const: google,nyan-big-rev6 + - const: google,nyan-big-rev5 + - const: google,nyan-big-rev4 + - const: google,nyan-big-rev3 + - const: google,nyan-big-rev2 + - const: google,nyan-big-rev1 + - const: google,nyan-big-rev0 + - const: google,nyan-big + - const: google,nyan + - const: nvidia,tegra124 + - items: + - const: google,nyan-blaze-rev10 + - const: google,nyan-blaze-rev9 + - const: google,nyan-blaze-rev8 + - const: google,nyan-blaze-rev7 + - const: google,nyan-blaze-rev6 + - const: google,nyan-blaze-rev5 + - const: google,nyan-blaze-rev4 + - const: google,nyan-blaze-rev3 + - const: google,nyan-blaze-rev2 + - const: google,nyan-blaze-rev1 + - const: google,nyan-blaze-rev0 + - const: google,nyan-blaze + - const: google,nyan + - const: nvidia,tegra124 + - items: - enum: - nvidia,norrin - const: nvidia,tegra132 @@ -184,17 +211,35 @@ properties: - const: nvidia,tegra124 - items: - enum: - - nvidia,darcy - nvidia,p2371-0000 - nvidia,p2371-2180 - nvidia,p2571 - - nvidia,p2894-0050-a08 - - nvidia,p3450-0000 - const: nvidia,tegra210 - items: - const: nvidia,p3541-0000 - const: nvidia,p3450-0000 - const: nvidia,tegra210 + - description: NVIDIA Jetson Nano + items: + - const: nvidia,p3450-0000 + - const: nvidia,tegra210 + - description: NVIDIA Shield TV + items: + - const: nvidia,p2894-0050-a08 + - const: nvidia,darcy + - const: nvidia,tegra210 + - description: Google Pixel C + items: + - const: google,smaug-rev8 + - const: google,smaug-rev7 + - const: google,smaug-rev6 + - const: google,smaug-rev5 + - const: google,smaug-rev4 + - const: google,smaug-rev3 + - const: google,smaug-rev2 + - const: google,smaug-rev1 + - const: google,smaug + - const: nvidia,tegra210 - description: Jetson TX2 Developer Kit items: - const: nvidia,p2771-0000 @@ -268,5 +313,10 @@ properties: - const: nvidia,p3971-0089+p3834-0008 - const: nvidia,p3834-0008 - const: nvidia,tegra264 + - description: Jetson AGX Thor Developer Kit + items: + - const: nvidia,p4071-0000+p3834-0008 + - const: nvidia,p3834-0008 + - const: nvidia,tegra264 additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml index 36dbd0838f2d..fe9c8791f227 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml @@ -24,6 +24,7 @@ properties: enum: - nvidia,tegra186-ccplex-cluster - nvidia,tegra234-ccplex-cluster + - nvidia,tegra238-ccplex-cluster reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml index fcdf03131323..e69ee6a48fcc 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml @@ -48,6 +48,10 @@ properties: - nvidia,tegra234-dce-fabric - nvidia,tegra234-rce-fabric - nvidia,tegra234-sce-fabric + - nvidia,tegra238-ape-fabric + - nvidia,tegra238-aon-fabric + - nvidia,tegra238-bpmp-fabric + - nvidia,tegra238-cbb-fabric reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index 85deda6d4292..2a6a9441c23d 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -79,6 +79,7 @@ properties: - toradex,verdin-am62-nonwifi-ivy # Verdin AM62 Module on Ivy - toradex,verdin-am62-nonwifi-mallow # Verdin AM62 Module on Mallow - toradex,verdin-am62-nonwifi-yavia # Verdin AM62 Module on Yavia + - toradex,verdin-am62-nonwifi-zinnia # Verdin AM62 Module on Zinnia - const: toradex,verdin-am62-nonwifi # Verdin AM62 Module without Wi-Fi / BT - const: toradex,verdin-am62 # Verdin AM62 Module - const: ti,am625 @@ -91,6 +92,7 @@ properties: - toradex,verdin-am62-wifi-ivy # Verdin AM62 Wi-Fi / BT Module on Ivy - toradex,verdin-am62-wifi-mallow # Verdin AM62 Wi-Fi / BT Module on Mallow - toradex,verdin-am62-wifi-yavia # Verdin AM62 Wi-Fi / BT Module on Yavia + - toradex,verdin-am62-wifi-zinnia # Verdin AM62 Wi-Fi / BT Module on Zinnia - const: toradex,verdin-am62-wifi # Verdin AM62 Wi-Fi / BT Module - const: toradex,verdin-am62 # Verdin AM62 Module - const: ti,am625 @@ -103,6 +105,7 @@ properties: - toradex,verdin-am62p-nonwifi-ivy # Verdin AM62P Module on Ivy - toradex,verdin-am62p-nonwifi-mallow # Verdin AM62P Module on Mallow - toradex,verdin-am62p-nonwifi-yavia # Verdin AM62P Module on Yavia + - toradex,verdin-am62p-nonwifi-zinnia # Verdin AM62P Module on Zinnia - const: toradex,verdin-am62p-nonwifi # Verdin AM62P Module without Wi-Fi / BT - const: toradex,verdin-am62p # Verdin AM62P Module - const: ti,am62p5 @@ -115,6 +118,7 @@ properties: - toradex,verdin-am62p-wifi-ivy # Verdin AM62P Wi-Fi / BT Module on Ivy - toradex,verdin-am62p-wifi-mallow # Verdin AM62P Wi-Fi / BT Module on Mallow - toradex,verdin-am62p-wifi-yavia # Verdin AM62P Wi-Fi / BT Module on Yavia + - toradex,verdin-am62p-wifi-zinnia # Verdin AM62P Wi-Fi / BT Module on Zinnia - const: toradex,verdin-am62p-wifi # Verdin AM62P Wi-Fi / BT Module - const: toradex,verdin-am62p # Verdin AM62P Module - const: ti,am62p5 @@ -208,7 +212,6 @@ properties: items: - enum: - beagle,am67a-beagley-ai - - kontron,sa67 # Kontron SMARC-sAM67 board - ti,j722s-evm - const: ti,j722s diff --git a/Documentation/devicetree/bindings/arm/ti/omap.yaml b/Documentation/devicetree/bindings/arm/ti/omap.yaml index 14f1b9d8f59d..f694dcbf2348 100644 --- a/Documentation/devicetree/bindings/arm/ti/omap.yaml +++ b/Documentation/devicetree/bindings/arm/ti/omap.yaml @@ -144,6 +144,8 @@ properties: - motorola,droid-bionic # Motorola Droid Bionic XT875 - motorola,xyboard-mz609 - motorola,xyboard-mz617 + - samsung,espresso7 + - samsung,espresso10 - ti,omap4-panda - ti,omap4-sdp - const: ti,omap4430 diff --git a/Documentation/devicetree/bindings/arm/vexpress-scc.txt b/Documentation/devicetree/bindings/arm/vexpress-scc.txt deleted file mode 100644 index ae5043e42e5d..000000000000 --- a/Documentation/devicetree/bindings/arm/vexpress-scc.txt +++ /dev/null @@ -1,33 +0,0 @@ -ARM Versatile Express Serial Configuration Controller ------------------------------------------------------ - -Test chips for ARM Versatile Express platform implement SCC (Serial -Configuration Controller) interface, used to set initial conditions -for the test chip. - -In some cases its registers are also mapped in normal address space -and can be used to obtain runtime information about the chip internals -(like silicon temperature sensors) and as interface to other subsystems -like platform configuration control and power management. - -Required properties: - -- compatible value: "arm,vexpress-scc,<model>", "arm,vexpress-scc"; - where <model> is the full tile model name (as used - in the tile's Technical Reference Manual), - eg. for Coretile Express A15x2 A7x3 (V2P-CA15_A7): - compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; - -Optional properties: - -- reg: when the SCC is memory mapped, physical address and size of the - registers window -- interrupts: when the SCC can generate a system-level interrupt - -Example: - - scc@7fff0000 { - compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; - reg = <0 0x7fff0000 0 0x1000>; - interrupts = <0 95 4>; - }; diff --git a/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml b/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml deleted file mode 100644 index 9b7ca4759bd7..000000000000 --- a/Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml +++ /dev/null @@ -1,115 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/ata/baikal,bt1-ahci.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Baikal-T1 SoC AHCI SATA controller - -maintainers: - - Serge Semin <fancer.lancer@gmail.com> - -description: - AHCI SATA controller embedded into the Baikal-T1 SoC is based on the - DWC AHCI SATA v4.10a IP-core. - -allOf: - - $ref: snps,dwc-ahci-common.yaml# - -properties: - compatible: - const: baikal,bt1-ahci - - clocks: - items: - - description: Peripheral APB bus clock - - description: Application AXI BIU clock - - description: SATA Ports reference clock - - clock-names: - items: - - const: pclk - - const: aclk - - const: ref - - resets: - items: - - description: Application AXI BIU domain reset - - description: SATA Ports clock domain reset - - reset-names: - items: - - const: arst - - const: ref - - ports-implemented: - maximum: 0x3 - -patternProperties: - "^sata-port@[0-1]$": - $ref: /schemas/ata/snps,dwc-ahci-common.yaml#/$defs/dwc-ahci-port - - properties: - reg: - minimum: 0 - maximum: 1 - - snps,tx-ts-max: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - Due to having AXI3 bus interface utilized the maximum Tx DMA - transaction size can't exceed 16 beats (AxLEN[3:0]). - enum: [ 1, 2, 4, 8, 16 ] - - snps,rx-ts-max: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - Due to having AXI3 bus interface utilized the maximum Rx DMA - transaction size can't exceed 16 beats (AxLEN[3:0]). - enum: [ 1, 2, 4, 8, 16 ] - - unevaluatedProperties: false - -required: - - compatible - - reg - - interrupts - - clocks - - clock-names - - resets - -unevaluatedProperties: false - -examples: - - | - sata@1f050000 { - compatible = "baikal,bt1-ahci"; - reg = <0x1f050000 0x2000>; - #address-cells = <1>; - #size-cells = <0>; - - interrupts = <0 64 4>; - - clocks = <&ccu_sys 1>, <&ccu_axi 2>, <&sata_ref_clk>; - clock-names = "pclk", "aclk", "ref"; - - resets = <&ccu_axi 2>, <&ccu_sys 0>; - reset-names = "arst", "ref"; - - ports-implemented = <0x3>; - - sata-port@0 { - reg = <0>; - - snps,tx-ts-max = <4>; - snps,rx-ts-max = <4>; - }; - - sata-port@1 { - reg = <1>; - - snps,tx-ts-max = <4>; - snps,rx-ts-max = <4>; - }; - }; -... diff --git a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml index b90eec2077b4..fe1272e86467 100644 --- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml +++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml @@ -66,7 +66,7 @@ then: required: - refresh-rate-hz -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml b/Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml deleted file mode 100644 index 37ba3337f944..000000000000 --- a/Documentation/devicetree/bindings/bus/baikal,bt1-apb.yaml +++ /dev/null @@ -1,90 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/bus/baikal,bt1-apb.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Baikal-T1 APB-bus - -maintainers: - - Serge Semin <fancer.lancer@gmail.com> - -description: | - Baikal-T1 CPU or DMAC MMIO requests are handled by the AMBA 3 AXI Interconnect - which routes them to the AXI-APB bridge. This interface is a single master - multiple slaves bus in turn serializing IO accesses and routing them to the - addressed APB slave devices. In case of any APB protocol collisions, slave - device not responding on timeout an IRQ is raised with an erroneous address - reported to the APB terminator (APB Errors Handler Block). - -allOf: - - $ref: /schemas/simple-bus.yaml# - -properties: - compatible: - contains: - const: baikal,bt1-apb - - reg: - items: - - description: APB EHB MMIO registers - - description: APB MMIO region with no any device mapped - - reg-names: - items: - - const: ehb - - const: nodev - - interrupts: - maxItems: 1 - - clocks: - items: - - description: APB reference clock - - clock-names: - items: - - const: pclk - - resets: - items: - - description: APB domain reset line - - reset-names: - items: - - const: prst - -unevaluatedProperties: false - -required: - - compatible - - reg - - reg-names - - interrupts - - clocks - - clock-names - -examples: - - | - #include <dt-bindings/interrupt-controller/mips-gic.h> - - bus@1f059000 { - compatible = "baikal,bt1-apb", "simple-bus"; - reg = <0x1f059000 0x1000>, - <0x1d000000 0x2040000>; - reg-names = "ehb", "nodev"; - #address-cells = <1>; - #size-cells = <1>; - - ranges; - - interrupts = <GIC_SHARED 16 IRQ_TYPE_LEVEL_HIGH>; - - clocks = <&ccu_sys 1>; - clock-names = "pclk"; - - resets = <&ccu_sys 1>; - reset-names = "prst"; - }; -... diff --git a/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml b/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml deleted file mode 100644 index 4ac78b44e45e..000000000000 --- a/Documentation/devicetree/bindings/bus/baikal,bt1-axi.yaml +++ /dev/null @@ -1,107 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/bus/baikal,bt1-axi.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Baikal-T1 AXI-bus - -maintainers: - - Serge Semin <fancer.lancer@gmail.com> - -description: | - AXI3-bus is the main communication bus of Baikal-T1 SoC connecting all - high-speed peripheral IP-cores with RAM controller and with MIPS P5600 - cores. Traffic arbitration is done by means of DW AXI Interconnect (so - called AXI Main Interconnect) routing IO requests from one block to - another: from CPU to SoC peripherals and between some SoC peripherals - (mostly between peripheral devices and RAM, but also between DMA and - some peripherals). In case of any protocol error, device not responding - an IRQ is raised and a faulty situation is reported to the AXI EHB - (Errors Handler Block) embedded on top of the DW AXI Interconnect and - accessible by means of the Baikal-T1 System Controller. - -allOf: - - $ref: /schemas/simple-bus.yaml# - -properties: - compatible: - contains: - const: baikal,bt1-axi - - reg: - minItems: 1 - items: - - description: Synopsys DesignWare AXI Interconnect QoS registers - - description: AXI EHB MMIO system controller registers - - reg-names: - minItems: 1 - items: - - const: qos - - const: ehb - - '#interconnect-cells': - const: 1 - - syscon: - $ref: /schemas/types.yaml#/definitions/phandle - description: Phandle to the Baikal-T1 System Controller DT node - - interrupts: - maxItems: 1 - - clocks: - items: - - description: Main Interconnect uplink reference clock - - clock-names: - items: - - const: aclk - - resets: - items: - - description: Main Interconnect reset line - - reset-names: - items: - - const: arst - -unevaluatedProperties: false - -required: - - compatible - - reg - - reg-names - - syscon - - interrupts - - clocks - - clock-names - -examples: - - | - #include <dt-bindings/interrupt-controller/mips-gic.h> - - bus@1f05a000 { - compatible = "baikal,bt1-axi", "simple-bus"; - reg = <0x1f05a000 0x1000>, - <0x1f04d110 0x8>; - reg-names = "qos", "ehb"; - #address-cells = <1>; - #size-cells = <1>; - #interconnect-cells = <1>; - - syscon = <&syscon>; - - ranges; - - interrupts = <GIC_SHARED 127 IRQ_TYPE_LEVEL_HIGH>; - - clocks = <&ccu_axi 0>; - clock-names = "aclk"; - - resets = <&ccu_axi 0>; - reset-names = "arst"; - }; -... diff --git a/Documentation/devicetree/bindings/bus/st,stm32mp131-dbg-bus.yaml b/Documentation/devicetree/bindings/bus/st,stm32mp131-dbg-bus.yaml new file mode 100644 index 000000000000..6c74433efbe3 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/st,stm32mp131-dbg-bus.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/st,stm32mp131-dbg-bus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STM32 Coresight bus + +maintainers: + - Gatien Chevallier <gatien.chevallier@foss.st.com> + +description: + The STM32 debug bus is in charge of checking the debug configuration + of the platform before probing the peripheral drivers that rely on the debug + domain. + +properties: + compatible: + items: + - enum: + - st,stm32mp131-dbg-bus + - st,stm32mp151-dbg-bus + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: + minItems: 1 + maxItems: 2 + + "#access-controller-cells": + const: 1 + description: + Contains the debug profile necessary to access the peripheral. + +patternProperties: + "@[0-9a-f]+$": + description: Debug related peripherals + type: object + + additionalProperties: true + + required: + - access-controllers + +required: + - "#access-controller-cells" + - "#address-cells" + - "#size-cells" + - compatible + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/stm32mp1-clks.h> + + dbg_bus: bus@50080000 { + compatible = "st,stm32mp131-dbg-bus"; + #address-cells = <1>; + #size-cells = <1>; + #access-controller-cells = <1>; + ranges = <0x50080000 0x50080000 0x3f80000>; + + cti@50094000 { + compatible = "arm,coresight-cti", "arm,primecell"; + reg = <0x50094000 0x1000>; + clocks = <&rcc CK_DBG>; + clock-names = "apb_pclk"; + access-controllers = <&dbg_bus 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/cache/baikal,bt1-l2-ctl.yaml b/Documentation/devicetree/bindings/cache/baikal,bt1-l2-ctl.yaml deleted file mode 100644 index ec4f367bc0b4..000000000000 --- a/Documentation/devicetree/bindings/cache/baikal,bt1-l2-ctl.yaml +++ /dev/null @@ -1,63 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/cache/baikal,bt1-l2-ctl.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Baikal-T1 L2-cache Control Block - -maintainers: - - Serge Semin <fancer.lancer@gmail.com> - -description: | - By means of the System Controller Baikal-T1 SoC exposes a few settings to - tune the MIPS P5600 CM2 L2 cache performance up. In particular it's possible - to change the Tag, Data and Way-select RAM access latencies. Baikal-T1 - L2-cache controller block is responsible for the tuning. Its DT node is - supposed to be a child of the system controller. - -properties: - compatible: - const: baikal,bt1-l2-ctl - - reg: - maxItems: 1 - - baikal,l2-ws-latency: - $ref: /schemas/types.yaml#/definitions/uint32 - description: Cycles of latency for Way-select RAM accesses - default: 0 - minimum: 0 - maximum: 3 - - baikal,l2-tag-latency: - $ref: /schemas/types.yaml#/definitions/uint32 - description: Cycles of latency for Tag RAM accesses - default: 0 - minimum: 0 - maximum: 3 - - baikal,l2-data-latency: - $ref: /schemas/types.yaml#/definitions/uint32 - description: Cycles of latency for Data RAM accesses - default: 1 - minimum: 0 - maximum: 3 - -additionalProperties: false - -required: - - compatible - -examples: - - | - l2@1f04d028 { - compatible = "baikal,bt1-l2-ctl"; - reg = <0x1f04d028 0x004>; - - baikal,l2-ws-latency = <1>; - baikal,l2-tag-latency = <1>; - baikal,l2-data-latency = <2>; - }; -... diff --git a/Documentation/devicetree/bindings/cache/qcom,llcc.yaml b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml index 6671e461e34a..995d57815781 100644 --- a/Documentation/devicetree/bindings/cache/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/cache/qcom,llcc.yaml @@ -33,6 +33,7 @@ properties: - qcom,sc7280-llcc - qcom,sc8180x-llcc - qcom,sc8280xp-llcc + - qcom,sdm670-llcc - qcom,sdm845-llcc - qcom,sm6350-llcc - qcom,sm7150-llcc @@ -204,6 +205,7 @@ allOf: contains: enum: - qcom,sc7280-llcc + - qcom,sdm670-llcc then: properties: reg: diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml index 9f9816fbecbc..fd1a459879bd 100644 --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml @@ -8,17 +8,28 @@ title: Google Chrome OS EC(Embedded Controller) Type C port driver. maintainers: - Benson Leung <bleung@chromium.org> - - Prashant Malani <pmalani@chromium.org> + - Abhishek Pandit-Subedi <abhishekpandit@chromium.org> + - Andrei Kuchynski <akuchynski@chromium.org> + - Łukasz Bartosik <ukaszb@chromium.org> + - Jameson Thies <jthies@google.com> description: Chrome OS devices have an Embedded Controller(EC) which has access to Type C port state. This node is intended to allow the host to read and - control the Type C ports. The node for this device should be under a - cros-ec node like google,cros-ec-spi. + control the Type C ports. This binding is compatible with both the + cros-ec-typec and cros-ec-ucsi drivers. The cros-ec-typec driver + supports the host command interface used by the Chrome OS EC with a + built-in Type-C port manager and external Type-C Port Controller + (TCPC). The cros-ec-ucsi driver supports the USB Type-C Connector + System Software (UCSI) interface used by the Chrome OS EC when the + platform has a separate power delivery controller (PDC). The node for + this device should be under a cros-ec node like google,cros-ec-spi. properties: compatible: - const: google,cros-ec-typec + enum: + - google,cros-ec-typec + - google,cros-ec-ucsi '#address-cells': const: 1 diff --git a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml index a8471367175b..eb24a5687639 100644 --- a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml +++ b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml @@ -32,6 +32,7 @@ properties: - enum: - airoha,en7523-scu - airoha,en7581-scu + - econet,en751221-scu reg: items: @@ -67,7 +68,9 @@ allOf: - if: properties: compatible: - const: airoha,en7581-scu + enum: + - airoha,en7581-scu + - econet,en751221-scu then: properties: reg: @@ -98,3 +101,4 @@ examples: #reset-cells = <1>; }; }; + diff --git a/Documentation/devicetree/bindings/clock/axis,artpec9-clock.yaml b/Documentation/devicetree/bindings/clock/axis,artpec9-clock.yaml new file mode 100644 index 000000000000..63442b91e7ac --- /dev/null +++ b/Documentation/devicetree/bindings/clock/axis,artpec9-clock.yaml @@ -0,0 +1,232 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/axis,artpec9-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Axis ARTPEC-9 SoC clock controller + +maintainers: + - Jesper Nilsson <jesper.nilsson@axis.com> + +description: | + ARTPEC-9 clock controller is comprised of several CMU (Clock Management Unit) + units, generating clocks for different domains. Those CMU units are modeled + as separate device tree nodes, and might depend on each other. + The root clock in that root tree is an external clock: OSCCLK (25 MHz). + This external clock must be defined as a fixed-rate clock in dts. + + CMU_CMU is a top-level CMU, where all base clocks are prepared using PLLs and + dividers, all other clocks of function blocks (other CMUs) are usually + derived from CMU_CMU. + + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All clocks available for usage + in clock consumer nodes are defined as preprocessor macros in + 'include/dt-bindings/clock/axis,artpec9-clk.h' header. + +properties: + compatible: + enum: + - axis,artpec9-cmu-cmu + - axis,artpec9-cmu-bus + - axis,artpec9-cmu-core + - axis,artpec9-cmu-cpucl + - axis,artpec9-cmu-fsys0 + - axis,artpec9-cmu-fsys1 + - axis,artpec9-cmu-imem + - axis,artpec9-cmu-peri + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 5 + + clock-names: + minItems: 1 + maxItems: 5 + + "#clock-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - "#clock-cells" + +allOf: + - if: + properties: + compatible: + const: axis,artpec9-cmu-cmu + + then: + properties: + clocks: + items: + - description: External reference clock (25 MHz) + + clock-names: + items: + - const: fin_pll + + - if: + properties: + compatible: + const: axis,artpec9-cmu-bus + + then: + properties: + clocks: + items: + - description: External reference clock (25 MHz) + - description: CMU_BUS bus clock (from CMU_CMU) + + clock-names: + items: + - const: fin_pll + - const: bus + + - if: + properties: + compatible: + const: axis,artpec9-cmu-core + + then: + properties: + clocks: + items: + - description: External reference clock (25 MHz) + - description: CMU_CORE main clock (from CMU_CMU) + + clock-names: + items: + - const: fin_pll + - const: main + + - if: + properties: + compatible: + const: axis,artpec9-cmu-cpucl + + then: + properties: + clocks: + items: + - description: External reference clock (25 MHz) + - description: CMU_CPUCL switch clock (from CMU_CMU) + + clock-names: + items: + - const: fin_pll + - const: switch + + - if: + properties: + compatible: + const: axis,artpec9-cmu-fsys0 + + then: + properties: + clocks: + items: + - description: External reference clock (25 MHz) + - description: CMU_FSYS0 bus clock (from CMU_CMU) + - description: CMU_FSYS0 IP clock (from CMU_CMU) + + clock-names: + items: + - const: fin_pll + - const: bus + - const: ip + + - if: + properties: + compatible: + const: axis,artpec9-cmu-fsys1 + + then: + properties: + clocks: + items: + - description: External reference clock (25 MHz) + - description: CMU_FSYS1 scan0 clock (from CMU_CMU) + - description: CMU_FSYS1 scan1 clock (from CMU_CMU) + - description: CMU_FSYS1 bus clock (from CMU_CMU) + + clock-names: + items: + - const: fin_pll + - const: scan0 + - const: scan1 + - const: bus + + - if: + properties: + compatible: + const: axis,artpec9-cmu-imem + + then: + properties: + clocks: + items: + - description: External reference clock (25 MHz) + - description: CMU_IMEM ACLK clock (from CMU_CMU) + - description: CMU_IMEM CA5 clock (from CMU_CMU) + - description: CMU_IMEM JPEG clock (from CMU_CMU) + - description: CMU_IMEM SSS clock (from CMU_CMU) + + clock-names: + items: + - const: fin_pll + - const: aclk + - const: ca5 + - const: jpeg + - const: sss + + - if: + properties: + compatible: + const: axis,artpec9-cmu-peri + + then: + properties: + clocks: + items: + - description: External reference clock (25 MHz) + - description: CMU_PERI IP clock (from CMU_CMU) + - description: CMU_PERI DISP clock (from CMU_CMU) + + clock-names: + items: + - const: fin_pll + - const: ip + - const: disp + +additionalProperties: false + +examples: + # Clock controller node for CMU_FSYS1 + - | + #include <dt-bindings/clock/axis,artpec9-clk.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + cmu_fsys1: clock-controller@14c10000 { + compatible = "axis,artpec9-cmu-fsys1"; + reg = <0x0 0x14c10000 0x0 0x4000>; + #clock-cells = <1>; + clocks = <&fin_pll>, + <&cmu_cmu CLK_DOUT_CMU_FSYS1_SCAN0>, + <&cmu_cmu CLK_DOUT_CMU_FSYS1_SCAN1>, + <&cmu_cmu CLK_DOUT_CMU_FSYS1_BUS>; + clock-names = "fin_pll", "scan0", "scan1", "bus"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml deleted file mode 100644 index 30252c95700c..000000000000 --- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml +++ /dev/null @@ -1,196 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-div.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Baikal-T1 Clock Control Unit Dividers - -maintainers: - - Serge Semin <fancer.lancer@gmail.com> - -description: | - Clocks Control Unit is the core of Baikal-T1 SoC System Controller - responsible for the chip subsystems clocking and resetting. The CCU is - connected with an external fixed rate oscillator, which signal is transformed - into clocks of various frequencies and then propagated to either individual - IP-blocks or to groups of blocks (clock domains). The transformation is done - by means of an embedded into CCU PLLs and gateable/non-gateable dividers. The - later ones are described in this binding. Each clock domain can be also - individually reset by using the domain clocks divider configuration - registers. Baikal-T1 CCU is logically divided into the next components: - 1) External oscillator (normally XTAL's 25 MHz crystal oscillator, but - in general can provide any frequency supported by the CCU PLLs). - 2) PLLs clocks generators (PLLs). - 3) AXI-bus clock dividers (AXI) - described in this binding file. - 4) System devices reference clock dividers (SYS) - described in this binding - file. - which are connected with each other as shown on the next figure: - - +---------------+ - | Baikal-T1 CCU | - | +----+------|- MIPS P5600 cores - | +-|PLLs|------|- DDR controller - | | +----+ | - +----+ | | | | | - |XTAL|--|-+ | | +---+-| - +----+ | | | +-|AXI|-|- AXI-bus - | | | +---+-| - | | | | - | | +----+---+-|- APB-bus - | +-------|SYS|-|- Low-speed Devices - | +---+-|- High-speed Devices - +---------------+ - - Each sub-block is represented as a separate DT node and has an individual - driver to be bound with. - - In order to create signals of wide range frequencies the external oscillator - output is primarily connected to a set of CCU PLLs. Some of PLLs CLKOUT are - then passed over CCU dividers to create signals required for the target clock - domain (like AXI-bus or System Device consumers). The dividers have the - following structure: - - +--------------+ - CLKIN --|->+----+ 1|\ | - SETCLK--|--|/DIV|->| | | - CLKDIV--|--| | | |-|->CLKLOUT - LOCK----|--+----+ | | | - | |/ | - | | | - EN------|-----------+ | - RST-----|--------------|->RSTOUT - +--------------+ - - where CLKIN is the reference clock coming either from CCU PLLs or from an - external clock oscillator, SETCLK - a command to update the output clock in - accordance with a set divider, CLKDIV - clocks divider, LOCK - a signal of - the output clock stabilization, EN - enable/disable the divider block, - RST/RSTOUT - reset clocks domain signal. Depending on the consumer IP-core - peculiarities the dividers may lack of some functionality depicted on the - figure above (like EN, CLKDIV/LOCK/SETCLK). In this case the corresponding - clock provider just doesn't expose either switching functions, or the rate - configuration, or both of them. - - The clock dividers, which output clock is then consumed by the SoC individual - devices, are united into a single clocks provider called System Devices CCU. - Similarly the dividers with output clocks utilized as AXI-bus reference clocks - are called AXI-bus CCU. Both of them use the common clock bindings with no - custom properties. The list of exported clocks and reset signals can be found - in the files: 'include/dt-bindings/clock/bt1-ccu.h' and - 'include/dt-bindings/reset/bt1-ccu.h'. Since System Devices and AXI-bus CCU - are a part of the Baikal-T1 SoC System Controller their DT nodes are supposed - to be a children of later one. - -if: - properties: - compatible: - contains: - const: baikal,bt1-ccu-axi - -then: - properties: - clocks: - items: - - description: CCU SATA PLL output clock - - description: CCU PCIe PLL output clock - - description: CCU Ethernet PLL output clock - - clock-names: - items: - - const: sata_clk - - const: pcie_clk - - const: eth_clk - -else: - properties: - clocks: - items: - - description: External reference clock - - description: CCU SATA PLL output clock - - description: CCU PCIe PLL output clock - - description: CCU Ethernet PLL output clock - - clock-names: - items: - - const: ref_clk - - const: sata_clk - - const: pcie_clk - - const: eth_clk - -properties: - compatible: - enum: - - baikal,bt1-ccu-axi - - baikal,bt1-ccu-sys - - reg: - maxItems: 1 - - "#clock-cells": - const: 1 - - "#reset-cells": - const: 1 - - clocks: - minItems: 3 - maxItems: 4 - - clock-names: - minItems: 3 - maxItems: 4 - -additionalProperties: false - -required: - - compatible - - "#clock-cells" - - clocks - - clock-names - -examples: - # AXI-bus Clock Control Unit node: - - | - #include <dt-bindings/clock/bt1-ccu.h> - - clock-controller@1f04d030 { - compatible = "baikal,bt1-ccu-axi"; - reg = <0x1f04d030 0x030>; - #clock-cells = <1>; - #reset-cells = <1>; - - clocks = <&ccu_pll CCU_SATA_PLL>, - <&ccu_pll CCU_PCIE_PLL>, - <&ccu_pll CCU_ETH_PLL>; - clock-names = "sata_clk", "pcie_clk", "eth_clk"; - }; - # System Devices Clock Control Unit node: - - | - #include <dt-bindings/clock/bt1-ccu.h> - - clock-controller@1f04d060 { - compatible = "baikal,bt1-ccu-sys"; - reg = <0x1f04d060 0x0a0>; - #clock-cells = <1>; - #reset-cells = <1>; - - clocks = <&clk25m>, - <&ccu_pll CCU_SATA_PLL>, - <&ccu_pll CCU_PCIE_PLL>, - <&ccu_pll CCU_ETH_PLL>; - clock-names = "ref_clk", "sata_clk", "pcie_clk", - "eth_clk"; - }; - # Required Clock Control Unit PLL node: - - | - ccu_pll: clock-controller@1f04d000 { - compatible = "baikal,bt1-ccu-pll"; - reg = <0x1f04d000 0x028>; - #clock-cells = <1>; - - clocks = <&clk25m>; - clock-names = "ref_clk"; - }; -... diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml deleted file mode 100644 index 7f8d98226437..000000000000 --- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml +++ /dev/null @@ -1,131 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/clock/baikal,bt1-ccu-pll.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Baikal-T1 Clock Control Unit PLL - -maintainers: - - Serge Semin <fancer.lancer@gmail.com> - -description: | - Clocks Control Unit is the core of Baikal-T1 SoC System Controller - responsible for the chip subsystems clocking and resetting. The CCU is - connected with an external fixed rate oscillator, which signal is transformed - into clocks of various frequencies and then propagated to either individual - IP-blocks or to groups of blocks (clock domains). The transformation is done - by means of PLLs and gateable/non-gateable dividers embedded into the CCU. - It's logically divided into the next components: - 1) External oscillator (normally XTAL's 25 MHz crystal oscillator, but - in general can provide any frequency supported by the CCU PLLs). - 2) PLLs clocks generators (PLLs) - described in this binding file. - 3) AXI-bus clock dividers (AXI). - 4) System devices reference clock dividers (SYS). - which are connected with each other as shown on the next figure: - - +---------------+ - | Baikal-T1 CCU | - | +----+------|- MIPS P5600 cores - | +-|PLLs|------|- DDR controller - | | +----+ | - +----+ | | | | | - |XTAL|--|-+ | | +---+-| - +----+ | | | +-|AXI|-|- AXI-bus - | | | +---+-| - | | | | - | | +----+---+-|- APB-bus - | +-------|SYS|-|- Low-speed Devices - | +---+-|- High-speed Devices - +---------------+ - - Each CCU sub-block is represented as a separate dts-node and has an - individual driver to be bound with. - - In order to create signals of wide range frequencies the external oscillator - output is primarily connected to a set of CCU PLLs. There are five PLLs - to create a clock for the MIPS P5600 cores, the embedded DDR controller, - SATA, Ethernet and PCIe domains. The last three domains though named by the - biggest system interfaces in fact include nearly all of the rest SoC - peripherals. Each of the PLLs is based on True Circuits TSMC CLN28HPM core - with an interface wrapper (so called safe PLL' clocks switcher) to simplify - the PLL configuration procedure. The PLLs work as depicted on the next - diagram: - - +--------------------------+ - | | - +-->+---+ +---+ +---+ | +---+ 0|\ - CLKF--->|/NF|--->|PFD|...|VCO|-+->|/OD|--->| | - +---+ +->+---+ +---+ /->+---+ | |--->CLKOUT - CLKOD---------C----------------+ 1| | - +--------C--------------------------->|/ - | | ^ - Rclk-+->+---+ | | - CLKR--->|/NR|-+ | - +---+ | - BYPASS--------------------------------------+ - BWADJ---> - - where Rclk is the reference clock coming from XTAL, NR - reference clock - divider, NF - PLL clock multiplier, OD - VCO output clock divider, CLKOUT - - output clock, BWADJ is the PLL bandwidth adjustment parameter. At this moment - the binding supports the PLL dividers configuration in accordance with a - requested rate, while bypassing and bandwidth adjustment settings can be - added in future if it gets to be necessary. - - The PLLs CLKOUT is then either directly connected with the corresponding - clocks consumer (like P5600 cores or DDR controller) or passed over a CCU - divider to create a signal required for the clock domain. - - The CCU PLL dts-node uses the common clock bindings with no custom - parameters. The list of exported clocks can be found in - 'include/dt-bindings/clock/bt1-ccu.h'. Since CCU PLL is a part of the - Baikal-T1 SoC System Controller its DT node is supposed to be a child of - later one. - -properties: - compatible: - const: baikal,bt1-ccu-pll - - reg: - maxItems: 1 - - "#clock-cells": - const: 1 - - clocks: - description: External reference clock - maxItems: 1 - - clock-names: - const: ref_clk - -additionalProperties: false - -required: - - compatible - - "#clock-cells" - - clocks - - clock-names - -examples: - # Clock Control Unit PLL node: - - | - clock-controller@1f04d000 { - compatible = "baikal,bt1-ccu-pll"; - reg = <0x1f04d000 0x028>; - #clock-cells = <1>; - - clocks = <&clk25m>; - clock-names = "ref_clk"; - }; - # Required external oscillator: - - | - clk25m: clock-oscillator-25m { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <25000000>; - clock-output-names = "clk25m"; - }; -... diff --git a/Documentation/devicetree/bindings/clock/eswin,eic7700-clock.yaml b/Documentation/devicetree/bindings/clock/eswin,eic7700-clock.yaml new file mode 100644 index 000000000000..3125ae52bde6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/eswin,eic7700-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/eswin,eic7700-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Eswin EIC7700 SoC clock controller + +maintainers: + - Yifeng Huang <huangyifeng@eswincomputing.com> + - Xuyang Dong <dongxuyang@eswincomputing.com> + +description: + The clock controller generates and supplies clock to all the modules + for eic7700 SoC. + +properties: + compatible: + const: eswin,eic7700-clock + + reg: + maxItems: 1 + + clocks: + items: + - description: External 24MHz oscillator clock + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@51828000 { + compatible = "eswin,eic7700-clock"; + reg = <0x51828000 0x300>; + clocks = <&xtal24m>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml b/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml index 3bca9d11c148..041a63fa2d2b 100644 --- a/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml +++ b/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml @@ -10,10 +10,10 @@ maintainers: - Michael Walle <michael@walle.cc> description: | - It is possible to use the BCLK pin of a SAI module as a generic clock - output. Some SoC are very constrained in their pin multiplexer - configuration. Eg. pins can only be changed groups. For example, on the - LS1028A SoC you can only enable SAIs in pairs. If you use only one SAI, + It is possible to use the BCLK or MCLK pin of a SAI module as a generic + clock output. Some SoC are very constrained in their pin multiplexer + configuration. E.g. pins can only be changed in groups. For example, on + the LS1028A SoC you can only enable SAIs in pairs. If you use only one SAI, the second pins are wasted. Using this binding it is possible to use the clock of the second SAI as a MCLK clock for an audio codec, for example. @@ -21,16 +21,45 @@ description: | properties: compatible: - const: fsl,vf610-sai-clock + oneOf: + - items: + - enum: + - fsl,imx8mm-sai-clock + - fsl,imx8mn-sai-clock + - fsl,imx8mp-sai-clock + - const: fsl,imx8mq-sai-clock + - items: + - enum: + - fsl,imx8mq-sai-clock + - fsl,vf610-sai-clock reg: maxItems: 1 clocks: - maxItems: 1 + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + items: + - const: bus + - const: mclk1 '#clock-cells': - const: 0 + maximum: 1 + +allOf: + - if: + properties: + compatible: + contains: + const: fsl,vf610-sai-clock + then: + properties: + clocks: + maxItems: 1 + clock-names: false required: - compatible diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.yaml b/Documentation/devicetree/bindings/clock/imx6q-clock.yaml index cd3c04c883df..0e6febe1c875 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.yaml @@ -29,20 +29,24 @@ properties: const: 1 clocks: + minItems: 5 items: - description: 24m osc - description: 32k osc - description: ckih1 clock input - description: anaclk1 clock input - description: anaclk2 clock input + - description: clock input from enet ref pad clock-names: + minItems: 5 items: - const: osc - const: ckil - const: ckih1 - const: anaclk1 - const: anaclk2 + - const: enet_ref_pad fsl,pmic-stby-poweroff: $ref: /schemas/types.yaml#/definitions/flag diff --git a/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml b/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml index d57e18a210cc..035002721a3b 100644 --- a/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx6ul-clock.yaml @@ -29,18 +29,22 @@ properties: const: 1 clocks: + minItems: 4 items: - description: 32k osc - description: 24m osc - description: ipp_di0 clock input - description: ipp_di1 clock input + - description: clock input from enet1 ref pad clock-names: + minItems: 4 items: - const: ckil - const: osc - const: ipp_di0 - const: ipp_di1 + - const: enet1_ref_pad required: - compatible diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt deleted file mode 100644 index f7d347385b57..000000000000 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt +++ /dev/null @@ -1,155 +0,0 @@ -NVIDIA Tegra124 DFLL FCPU clocksource - -This binding uses the common clock binding: -Documentation/devicetree/bindings/clock/clock-bindings.txt - -The DFLL IP block on Tegra is a root clocksource designed for clocking -the fast CPU cluster. It consists of a free-running voltage controlled -oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop -control module that will automatically adjust the VDD_CPU voltage by -communicating with an off-chip PMIC either via an I2C bus or via PWM signals. - -Required properties: -- compatible : should be one of: - - "nvidia,tegra124-dfll": for Tegra124 - - "nvidia,tegra210-dfll": for Tegra210 -- reg : Defines the following set of registers, in the order listed: - - registers for the DFLL control logic. - - registers for the I2C output logic. - - registers for the integrated I2C master controller. - - look-up table RAM for voltage register values. -- interrupts: Should contain the DFLL block interrupt. -- clocks: Must contain an entry for each entry in clock-names. - See clock-bindings.txt for details. -- clock-names: Must include the following entries: - - soc: Clock source for the DFLL control logic. - - ref: The closed loop reference clock - - i2c: Clock source for the integrated I2C master. -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - dvco: Reset control for the DFLL DVCO. -- #clock-cells: Must be 0. -- clock-output-names: Name of the clock output. -- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL - hardware will start controlling. The regulator will be queried for - the I2C register, control values and supported voltages. - -Required properties for the control loop parameters: -- nvidia,sample-rate: Sample rate of the DFLL control loop. -- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM. -- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM. -- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM. -- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM. -- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM. - -Optional properties for the control loop parameters: -- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM. - -Optional properties for mode selection: -- nvidia,pwm-to-pmic: Use PWM to control regulator rather then I2C. - -Required properties for I2C mode: -- nvidia,i2c-fs-rate: I2C transfer rate, if using full speed mode. - -Required properties for PWM mode: -- nvidia,pwm-period-nanoseconds: period of PWM square wave in nanoseconds. -- nvidia,pwm-tristate-microvolts: Regulator voltage in micro volts when PWM - control is disabled and the PWM output is tristated. Note that this voltage is - configured in hardware, typically via a resistor divider. -- nvidia,pwm-min-microvolts: Regulator voltage in micro volts when PWM control - is enabled and PWM output is low. Hence, this is the minimum output voltage - that the regulator supports when PWM control is enabled. -- nvidia,pwm-voltage-step-microvolts: Voltage increase in micro volts - corresponding to a 1/33th increase in duty cycle. Eg the voltage for 2/33th - duty cycle would be: nvidia,pwm-min-microvolts + - nvidia,pwm-voltage-step-microvolts * 2. -- pinctrl-0: I/O pad configuration when PWM control is enabled. -- pinctrl-1: I/O pad configuration when PWM control is disabled. -- pinctrl-names: must include the following entries: - - dvfs_pwm_enable: I/O pad configuration when PWM control is enabled. - - dvfs_pwm_disable: I/O pad configuration when PWM control is disabled. - -Example for I2C: - -clock@70110000 { - compatible = "nvidia,tegra124-dfll"; - reg = <0 0x70110000 0 0x100>, /* DFLL control */ - <0 0x70110000 0 0x100>, /* I2C output control */ - <0 0x70110100 0 0x100>, /* Integrated I2C controller */ - <0 0x70110200 0 0x100>; /* Look-up table RAM */ - interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>, - <&tegra_car TEGRA124_CLK_DFLL_REF>, - <&tegra_car TEGRA124_CLK_I2C5>; - clock-names = "soc", "ref", "i2c"; - resets = <&tegra_car TEGRA124_RST_DFLL_DVCO>; - reset-names = "dvco"; - #clock-cells = <0>; - clock-output-names = "dfllCPU_out"; - vdd-cpu-supply = <&vdd_cpu>; - - nvidia,sample-rate = <12500>; - nvidia,droop-ctrl = <0x00000f00>; - nvidia,force-mode = <1>; - nvidia,cf = <10>; - nvidia,ci = <0>; - nvidia,cg = <2>; - - nvidia,i2c-fs-rate = <400000>; -}; - -Example for PWM: - -clock@70110000 { - compatible = "nvidia,tegra124-dfll"; - reg = <0 0x70110000 0 0x100>, /* DFLL control */ - <0 0x70110000 0 0x100>, /* I2C output control */ - <0 0x70110100 0 0x100>, /* Integrated I2C controller */ - <0 0x70110200 0 0x100>; /* Look-up table RAM */ - interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&tegra_car TEGRA210_CLK_DFLL_SOC>, - <&tegra_car TEGRA210_CLK_DFLL_REF>, - <&tegra_car TEGRA124_CLK_I2C5>;; - clock-names = "soc", "ref", "i2c"; - resets = <&tegra_car TEGRA124_RST_DFLL_DVCO>; - reset-names = "dvco"; - #clock-cells = <0>; - clock-output-names = "dfllCPU_out"; - - nvidia,sample-rate = <25000>; - nvidia,droop-ctrl = <0x00000f00>; - nvidia,force-mode = <1>; - nvidia,cf = <6>; - nvidia,ci = <0>; - nvidia,cg = <2>; - - nvidia,pwm-min-microvolts = <708000>; /* 708mV */ - nvidia,pwm-period-nanoseconds = <2500>; /* 2.5us */ - nvidia,pwm-to-pmic; - nvidia,pwm-tristate-microvolts = <1000000>; - nvidia,pwm-voltage-step-microvolts = <19200>; /* 19.2mV */ - - pinctrl-names = "dvfs_pwm_enable", "dvfs_pwm_disable"; - pinctrl-0 = <&dvfs_pwm_active_state>; - pinctrl-1 = <&dvfs_pwm_inactive_state>; -}; - -/* pinmux nodes added for completeness. Binding doc can be found in: - * Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.yaml - */ - -pinmux: pinmux@700008d4 { - dvfs_pwm_active_state: dvfs_pwm_active { - dvfs_pwm_pbb1 { - nvidia,pins = "dvfs_pwm_pbb1"; - nvidia,tristate = <TEGRA_PIN_DISABLE>; - }; - }; - dvfs_pwm_inactive_state: dvfs_pwm_inactive { - dvfs_pwm_pbb1 { - nvidia,pins = "dvfs_pwm_pbb1"; - nvidia,tristate = <TEGRA_PIN_ENABLE>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.yaml new file mode 100644 index 000000000000..5d689e48c438 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.yaml @@ -0,0 +1,290 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/nvidia,tegra124-dfll.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra124 (and later) DFLL FCPU clocksource + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: + The DFLL IP block on Tegra is a root clocksource designed for clocking + the fast CPU cluster. It consists of a free-running voltage controlled + oscillator connected to the CPU voltage rail (VDD_CPU), and a closed + loop control module that will automatically adjust the VDD_CPU voltage + by communicating with an off-chip PMIC either via an I2C bus or via + PWM signals. + +properties: + compatible: + enum: + - nvidia,tegra124-dfll + - nvidia,tegra210-dfll + + reg: + items: + - description: DFLL control logic + - description: I2C output logic + - description: Integrated I2C controller + - description: Look-up table RAM for voltage register values + + interrupts: + maxItems: 1 + + "#clock-cells": + const: 0 + + clocks: + items: + - description: Clock source for the DFLL control logic + - description: Closed loop reference clock + - description: Clock source for the integrated I2C controller + + clock-names: + items: + - const: soc + - const: ref + - const: i2c + + clock-output-names: + description: Name of the clock output + items: + - const: dfllCPU_out + + resets: + minItems: 1 + maxItems: 2 + + reset-names: + minItems: 1 + items: + - const: dvco + - const: dfll + + vdd-cpu-supply: + description: Regulator for the CPU voltage rail that the DFLL + hardware will start controlling. The regulator will be queried for + the I2C register, control values and supported voltages. + + nvidia,sample-rate: + description: Sample rate of the DFLL control loop + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 12500 + maximum: 25000 + + nvidia,droop-ctrl: + description: Droop control parameter (CL_DVFS_DROOP_CTRL) in the TRM + $ref: /schemas/types.yaml#/definitions/uint32 + + nvidia,force-mode: + description: See the field DFLL_PARAMS_FORCE_MODE in the TRM + $ref: /schemas/types.yaml#/definitions/uint32 + oneOf: + - description: disabled + const: 0 + - description: fixed delay mode + const: 1 + - description: auto mode + const: 2 + + nvidia,cf: + description: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 63 + + nvidia,ci: + description: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + + nvidia,cg: + description: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + + # optional properties + nvidia,cg-scale: + description: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM + $ref: /schemas/types.yaml#/definitions/flag + + nvidia,pwm-to-pmic: + description: Use PWM to control regulator rather than I2C + $ref: /schemas/types.yaml#/definitions/flag + + nvidia,i2c-fs-rate: + description: I2C transfer rate, if using full speed mode + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [100000, 400000] + + # required properties for PWM mode + nvidia,pwm-period-nanoseconds: + description: Period of PWM square wave in nanoseconds + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1000 + maximum: 1000000000 + + nvidia,pwm-tristate-microvolts: + description: Regulator voltage in microvolts when PWM control is disabled + and the PWM output is tristated. Note that this voltage is configured in + hardware, typically via a resistor divider. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3300000 + + nvidia,pwm-min-microvolts: + description: Regulator voltage in microvolts when PWM control is enabled + and PWM output is low. Hence, this is the minimum output voltage that + the regulator supports when PWM control is enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 3300000 + + nvidia,pwm-voltage-step-microvolts: + description: | + Voltage increase in micro volts corresponding to a 1/33th increase + in duty cycle. For example, the voltage for 2/33th duty cycle would be: + + nvidia,pwm-min-microvolts + nvidia,pwm-voltage-step-microvolts * 2 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 100000 + + pinctrl-0: + description: I/O pad configuration when PWM control is enabled + + pinctrl-1: + description: I/O pad configuration when PWM control is disabled + + pinctrl-names: + items: + - const: dvfs_pwm_enable + - const: dvfs_pwm_disable + +required: + - compatible + - reg + - interrupts + - "#clock-cells" + - clocks + - clock-names + - clock-output-names + - resets + - reset-names + - nvidia,sample-rate + - nvidia,droop-ctrl + - nvidia,force-mode + - nvidia,cf + - nvidia,ci + - nvidia,cg + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: nvidia,tegra124-dfll + then: + properties: + resets: + maxItems: 1 + + reset-names: + maxItems: 1 + else: + properties: + resets: + minItems: 2 + + reset-names: + minItems: 2 + + - if: + required: + - nvidia,pwm-to-pmic + then: + required: + - nvidia,pwm-min-microvolts + - nvidia,pwm-period-nanoseconds + - nvidia,pwm-tristate-microvolts + - nvidia,pwm-voltage-step-microvolts + else: + required: + - vdd-cpu-supply + +examples: + - | + #include <dt-bindings/clock/tegra124-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/reset/tegra124-car.h> + + clock@70110000 { + compatible = "nvidia,tegra124-dfll"; + reg = <0x70110000 0x100>, /* DFLL control */ + <0x70110000 0x100>, /* I2C output control */ + <0x70110100 0x100>, /* Integrated I2C controller */ + <0x70110200 0x100>; /* Look-up table RAM */ + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>, + <&tegra_car TEGRA124_CLK_DFLL_REF>, + <&tegra_car TEGRA124_CLK_I2C5>; + clock-names = "soc", "ref", "i2c"; + resets = <&tegra_car TEGRA124_RST_DFLL_DVCO>; + reset-names = "dvco"; + #clock-cells = <0>; + clock-output-names = "dfllCPU_out"; + vdd-cpu-supply = <&vdd_cpu>; + + nvidia,sample-rate = <12500>; + nvidia,droop-ctrl = <0x00000f00>; + nvidia,force-mode = <1>; + nvidia,cf = <10>; + nvidia,ci = <0>; + nvidia,cg = <2>; + + nvidia,i2c-fs-rate = <400000>; + }; + + - | + #include <dt-bindings/clock/tegra210-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/reset/tegra210-car.h> + + clock@70110000 { + compatible = "nvidia,tegra210-dfll"; + reg = <0x70110000 0x100>, /* DFLL control */ + <0x70110000 0x100>, /* I2C output control */ + <0x70110100 0x100>, /* Integrated I2C controller */ + <0x70110200 0x100>; /* Look-up table RAM */ + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA210_CLK_DFLL_SOC>, + <&tegra_car TEGRA210_CLK_DFLL_REF>, + <&tegra_car TEGRA210_CLK_I2C5>; + clock-names = "soc", "ref", "i2c"; + resets = <&tegra_car TEGRA210_RST_DFLL_DVCO>, + <&tegra_car 155>; + reset-names = "dvco", "dfll"; + #clock-cells = <0>; + clock-output-names = "dfllCPU_out"; + vdd-cpu-supply = <&vdd_cpu>; + + nvidia,sample-rate = <25000>; + nvidia,droop-ctrl = <0x00000f00>; + nvidia,force-mode = <1>; + nvidia,cf = <6>; + nvidia,ci = <0>; + nvidia,cg = <2>; + + nvidia,pwm-min-microvolts = <708000>; /* 708mV */ + nvidia,pwm-period-nanoseconds = <2500>; /* 2.5us */ + nvidia,pwm-to-pmic; + nvidia,pwm-tristate-microvolts = <1000000>; + nvidia,pwm-voltage-step-microvolts = <19200>; /* 19.2mV */ + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,eliza-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,eliza-dispcc.yaml new file mode 100644 index 000000000000..0935ec185dde --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,eliza-dispcc.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,eliza-dispcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Display Clock & Reset Controller for Qualcomm Eliza SoC + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + - Konrad Dybcio <konradybcio@kernel.org> + - Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> + +description: | + Display clock control module provides the clocks, resets and power + domains on Qualcomm Eliza SoC platform. + + See also: + - include/dt-bindings/clock/qcom,eliza-dispcc.h + +properties: + compatible: + enum: + - qcom,eliza-dispcc + + clocks: + items: + - description: Board XO source + - description: Board Always On XO source + - description: Display's AHB clock + - description: sleep clock + - description: Byte clock from DSI PHY0 + - description: Pixel clock from DSI PHY0 + - description: Byte clock from DSI PHY1 + - description: Pixel clock from DSI PHY1 + - description: Link clock from DP PHY0 + - description: VCO DIV clock from DP PHY0 + - description: Link clock from DP PHY1 + - description: VCO DIV clock from DP PHY1 + - description: Link clock from DP PHY2 + - description: VCO DIV clock from DP PHY2 + - description: Link clock from DP PHY3 + - description: VCO DIV clock from DP PHY3 + - description: HDMI link clock from HDMI PHY + + power-domains: + maxItems: 1 + + required-opps: + maxItems: 1 + +required: + - compatible + - clocks + - '#power-domain-cells' + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dsi-phy-28nm.h> + #include <dt-bindings/clock/qcom,eliza-gcc.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + clock-controller@af00000 { + compatible = "qcom,eliza-dispcc"; + reg = <0x0af00000 0x20000>; + clocks = <&bi_tcxo_div2>, + <&bi_tcxo_ao_div2>, + <&gcc GCC_DISP_AHB_CLK>, + <&sleep_clk>, + <&dsi0_phy DSI_BYTE_PLL_CLK>, + <&dsi0_phy DSI_PIXEL_PLL_CLK>, + <&dsi1_phy DSI_BYTE_PLL_CLK>, + <&dsi1_phy DSI_PIXEL_PLL_CLK>, + <&dp0_phy 0>, + <&dp0_phy 1>, + <&dp1_phy 0>, + <&dp1_phy 1>, + <&dp2_phy 0>, + <&dp2_phy 1>, + <&dp3_phy 0>, + <&dp3_phy 1>, + <&hdmi_phy>; + + #clock-cells = <1>; + #power-domain-cells = <1>; + #reset-cells = <1>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + required-opps = <&rpmhpd_opp_low_svs>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,glymur-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,glymur-dispcc.yaml index 45f027c70e03..9de4ba71f1d9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,glymur-dispcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,glymur-dispcc.yaml @@ -4,14 +4,14 @@ $id: http://devicetree.org/schemas/clock/qcom,glymur-dispcc.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Display Clock & Reset Controller on GLYMUR +title: Qualcomm Display Clock & Reset Controller on Glymur SoC maintainers: - Taniya Das <taniya.das@oss.qualcomm.com> description: | Qualcomm display clock control module which supports the clocks, resets and - power domains for the MDSS instances on GLYMUR SoC. + power domains for the MDSS instances on Glymur SoC. See also: include/dt-bindings/clock/qcom,dispcc-glymur.h diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5210-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5210-gcc.yaml new file mode 100644 index 000000000000..f1cc3fc19085 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,ipq5210-gcc.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,ipq5210-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on IPQ5210 + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + - Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on IPQ5210 + + See also: + include/dt-bindings/clock/qcom,ipq5210-gcc.h + include/dt-bindings/reset/qcom,ipq5210-gcc.h + +properties: + compatible: + const: qcom,ipq5210-gcc + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + - description: PCIE30 PHY0 pipe clock source + - description: PCIE30 PHY1 pipe clock source + - description: USB3 PHY pipe clock source + - description: NSS common clock source + + '#power-domain-cells': false + + '#interconnect-cells': + const: 1 + +required: + - compatible + - clocks + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + clock-controller@1800000 { + compatible = "qcom,ipq5210-gcc"; + reg = <0x01800000 0x40000>; + clocks = <&xo_board_clk>, + <&sleep_clk>, + <&pcie30_phy0_pipe_clk>, + <&pcie30_phy1_pipe_clk>, + <&usb3phy_0_cc_pipe_clk>, + <&nss_cmn_clk>; + #clock-cells = <1>; + #reset-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml index 817d51135fbf..de338c05190f 100644 --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml @@ -26,6 +26,8 @@ properties: enum: - qcom,ipq5018-cmn-pll - qcom,ipq5424-cmn-pll + - qcom,ipq6018-cmn-pll + - qcom,ipq8074-cmn-pll - qcom,ipq9574-cmn-pll reg: diff --git a/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml index 5490a975f3db..466c884aa2ba 100644 --- a/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml @@ -20,7 +20,9 @@ description: | properties: compatible: enum: + - qcom,glymur-gxclkctl - qcom,kaanapali-gxclkctl + - qcom,sm8750-gxclkctl power-domains: description: diff --git a/Documentation/devicetree/bindings/clock/qcom,milos-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,milos-gcc.yaml index cf244c155f9a..c65a6ad893d2 100644 --- a/Documentation/devicetree/bindings/clock/qcom,milos-gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,milos-gcc.yaml @@ -8,16 +8,21 @@ title: Qualcomm Global Clock & Reset Controller on Milos maintainers: - Luca Weiss <luca.weiss@fairphone.com> + - Taniya Das <taniya.das@oss.qualcomm.com> description: | Qualcomm global clock control module provides the clocks, resets and power domains on Milos. - See also: include/dt-bindings/clock/qcom,milos-gcc.h + See also: + - include/dt-bindings/clock/qcom,eliza-gcc.h + - include/dt-bindings/clock/qcom,milos-gcc.h properties: compatible: - const: qcom,milos-gcc + enum: + - qcom,eliza-gcc + - qcom,milos-gcc clocks: items: @@ -30,9 +35,14 @@ properties: - description: UFS Phy Tx symbol 0 clock source - description: USB3 Phy wrapper pipe clock source + power-domains: + items: + - description: CX domain + required: - compatible - clocks + - power-domains - '#power-domain-cells' allOf: @@ -43,6 +53,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom,rpmhpd.h> clock-controller@100000 { compatible = "qcom,milos-gcc"; reg = <0x00100000 0x1f4200>; @@ -54,6 +65,7 @@ examples: <&ufs_mem_phy 1>, <&ufs_mem_phy 2>, <&usb_1_qmpphy>; + power-domains = <&rpmhpd RPMHPD_CX>; #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/qcom,nord-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,nord-gcc.yaml new file mode 100644 index 000000000000..e35136722a93 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,nord-gcc.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,nord-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on Nord SoC + +maintainers: + - Taniya Das <taniya.das@oss.qualcomm.com> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on Nord SoC. + + See also: include/dt-bindings/clock/qcom,nord-gcc.h + +properties: + compatible: + const: qcom,nord-gcc + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + - description: PCIE A Pipe clock source + - description: PCIE B Pipe clock source + - description: PCIE C Pipe clock source + - description: PCIE D Pipe clock source + +required: + - compatible + - clocks + - '#power-domain-cells' + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@100000 { + compatible = "qcom,nord-gcc"; + reg = <0x00100000 0x1f4200>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&sleep_clk>, + <&pcie_a_pipe_clk>, + <&pcie_b_pipe_clk>, + <&pcie_c_pipe_clk>, + <&pcie_d_pipe_clk>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/qcom,nord-negcc.yaml b/Documentation/devicetree/bindings/clock/qcom,nord-negcc.yaml new file mode 100644 index 000000000000..749389f65ee1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,nord-negcc.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,nord-negcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global North East Clock & Reset Controller on Nord SoC + +maintainers: + - Taniya Das <taniya.das@oss.qualcomm.com> + +description: | + Qualcomm global clock control (NE) module provides the clocks, resets + and power domains on Nord SoC. + + See also: include/dt-bindings/clock/qcom,nord-negcc.h + +properties: + compatible: + const: qcom,nord-negcc + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + - description: UFS Phy Rx symbol 0 clock source + - description: UFS Phy Rx symbol 1 clock source + - description: UFS Phy Tx symbol 0 clock source + - description: USB3 Phy sec wrapper pipe clock source + - description: USB3 Phy wrapper pipe clock source + +required: + - compatible + - clocks + - '#power-domain-cells' + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@8900000 { + compatible = "qcom,nord-negcc"; + reg = <0x08900000 0xf4200>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&sleep_clk>, + <&ufs_phy_rx_symbol_0_clk>, + <&ufs_phy_rx_symbol_1_clk>, + <&ufs_phy_tx_symbol_0_clk>, + <&usb3_phy_sec_pipe_clk>, + <&usb3_phy_pipe_clk>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/qcom,nord-nwgcc.yaml b/Documentation/devicetree/bindings/clock/qcom,nord-nwgcc.yaml new file mode 100644 index 000000000000..ce33f966bdfd --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,nord-nwgcc.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,nord-nwgcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global North West and South East Clock & Reset Controller + on Nord SoC + +maintainers: + - Taniya Das <taniya.das@oss.qualcomm.com> + +description: | + Qualcomm global clock control (NW, SE) module provides the clocks, resets + and power domains on Nord SoC. + + See also: + include/dt-bindings/clock/qcom,nord-nwgcc.h + include/dt-bindings/clock/qcom,nord-segcc.h + +properties: + compatible: + enum: + - qcom,nord-nwgcc + - qcom,nord-segcc + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + +required: + - compatible + - clocks + - '#power-domain-cells' + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@8b00000 { + compatible = "qcom,nord-nwgcc"; + reg = <0x08b00000 0xf4200>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&sleep_clk>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index 3f5f1336262e..a2c404a57981 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -17,9 +17,11 @@ description: | properties: compatible: enum: + - qcom,eliza-rpmh-clk - qcom,glymur-rpmh-clk - qcom,kaanapali-rpmh-clk - qcom,milos-rpmh-clk + - qcom,nord-rpmh-clk - qcom,qcs615-rpmh-clk - qcom,qdu1000-rpmh-clk - qcom,sa8775p-rpmh-clk diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml index 6feaa32569f9..fdbdf605ee69 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml @@ -8,12 +8,14 @@ title: Qualcomm Graphics Clock & Reset Controller on SM8450 maintainers: - Konrad Dybcio <konradybcio@kernel.org> + - Taniya Das <taniya.das@oss.qualcomm.com> description: | Qualcomm graphics clock control module provides the clocks, resets and power domains on Qualcomm SoCs. - See also:: + See also: + include/dt-bindings/clock/qcom,glymur-gpucc.h include/dt-bindings/clock/qcom,kaanapali-gpucc.h include/dt-bindings/clock/qcom,milos-gpucc.h include/dt-bindings/clock/qcom,sar2130p-gpucc.h @@ -22,11 +24,13 @@ description: | include/dt-bindings/clock/qcom,sm8550-gpucc.h include/dt-bindings/reset/qcom,sm8450-gpucc.h include/dt-bindings/reset/qcom,sm8650-gpucc.h + include/dt-bindings/reset/qcom,sm8750-gpucc.h include/dt-bindings/reset/qcom,x1e80100-gpucc.h properties: compatible: enum: + - qcom,glymur-gpucc - qcom,kaanapali-gpucc - qcom,milos-gpucc - qcom,sar2130p-gpucc @@ -35,6 +39,7 @@ properties: - qcom,sm8475-gpucc - qcom,sm8550-gpucc - qcom,sm8650-gpucc + - qcom,sm8750-gpucc - qcom,x1e80100-gpucc - qcom,x1p42100-gpucc @@ -44,6 +49,16 @@ properties: - description: GPLL0 main branch source - description: GPLL0 div branch source + power-domains: + items: + - description: A phandle to the MX power-domain + - description: A phandle to the CX power-domain + + required-opps: + items: + - description: A phandle to an OPP node describing MX performance points + - description: A phandle to an OPP node describing CX performance points + required: - compatible - clocks @@ -51,6 +66,16 @@ required: allOf: - $ref: qcom,gcc.yaml# + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8750-gpucc + then: + required: + - power-domains + - required-opps unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml index e6beebd6a36e..7bbf120d928c 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml @@ -15,6 +15,7 @@ description: | domains on SM8450. See also: + include/dt-bindings/clock/qcom,glymur-videocc.h include/dt-bindings/clock/qcom,kaanapali-videocc.h include/dt-bindings/clock/qcom,sm8450-videocc.h include/dt-bindings/clock/qcom,sm8650-videocc.h @@ -23,6 +24,7 @@ description: | properties: compatible: enum: + - qcom,glymur-videocc - qcom,kaanapali-videocc - qcom,sm8450-videocc - qcom,sm8475-videocc @@ -63,6 +65,7 @@ allOf: compatible: contains: enum: + - qcom,glymur-videocc - qcom,kaanapali-videocc - qcom,sm8450-videocc - qcom,sm8550-videocc diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml index 784fef830681..1ccdf4b0f5dd 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml @@ -15,7 +15,9 @@ description: | power domains on SM8550 See also: + - include/dt-bindings/clock/qcom,eliza-tcsr.h - include/dt-bindings/clock/qcom,glymur-tcsr.h + - include/dt-bindings/clock/qcom,nord-tcsrcc.h - include/dt-bindings/clock/qcom,sm8550-tcsr.h - include/dt-bindings/clock/qcom,sm8650-tcsr.h - include/dt-bindings/clock/qcom,sm8750-tcsr.h @@ -24,9 +26,11 @@ properties: compatible: items: - enum: + - qcom,eliza-tcsr - qcom,glymur-tcsr - qcom,kaanapali-tcsr - qcom,milos-tcsr + - qcom,nord-tcsrcc - qcom,sar2130p-tcsr - qcom,sm8550-tcsr - qcom,sm8650-tcsr diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml index 8c18616e5c4d..c0ce687d83ee 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml @@ -28,19 +28,30 @@ properties: - renesas,r9a07g044-cpg # RZ/G2{L,LC} - renesas,r9a07g054-cpg # RZ/V2L - renesas,r9a08g045-cpg # RZ/G3S + - renesas,r9a08g046-cpg # RZ/G3L - renesas,r9a09g011-cpg # RZ/V2M reg: maxItems: 1 clocks: - maxItems: 1 + minItems: 1 + items: + - description: Clock source to CPG can be either from external clock + input (EXCLK) or crystal oscillator (XIN/XOUT). + - description: ETH0 TXC clock input + - description: ETH0 RXC clock input + - description: ETH1 TXC clock input + - description: ETH1 RXC clock input clock-names: - description: - Clock source to CPG can be either from external clock input (EXCLK) or - crystal oscillator (XIN/XOUT). - const: extal + minItems: 1 + items: + - const: extal + - const: eth0_txc_tx_clk + - const: eth0_rxc_rx_clk + - const: eth1_txc_tx_clk + - const: eth1_rxc_rx_clk '#clock-cells': description: | @@ -74,6 +85,25 @@ required: - '#power-domain-cells' - '#reset-cells' +allOf: + - if: + properties: + compatible: + contains: + const: renesas,r9a08g046-cpg + then: + properties: + clocks: + minItems: 5 + clock-names: + minItems: 5 + else: + properties: + clocks: + maxItems: 1 + clock-names: + maxItems: 1 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/clock/rockchip,rv1126b-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rv1126b-cru.yaml index 04b0a5c51e4e..b6d3a04be8f1 100644 --- a/Documentation/devicetree/bindings/clock/rockchip,rv1126b-cru.yaml +++ b/Documentation/devicetree/bindings/clock/rockchip,rv1126b-cru.yaml @@ -17,6 +17,7 @@ description: properties: compatible: enum: + - rockchip,rv1103b-cru - rockchip,rv1126b-cru reg: diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml index 1318720193b3..6b1fc61a2ff9 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml @@ -35,6 +35,7 @@ properties: - samsung,exynosautov920-cmu-cpucl0 - samsung,exynosautov920-cmu-cpucl1 - samsung,exynosautov920-cmu-cpucl2 + - samsung,exynosautov920-cmu-g3d - samsung,exynosautov920-cmu-hsi0 - samsung,exynosautov920-cmu-hsi1 - samsung,exynosautov920-cmu-hsi2 @@ -287,6 +288,26 @@ allOf: - const: oscclk - const: noc + - if: + properties: + compatible: + contains: + const: samsung,exynosautov920-cmu-g3d + + then: + properties: + clocks: + items: + - description: External reference clock (38.4 MHz) + - description: CMU_G3D SWITCH clock (from CMU_TOP) + - description: CMU_G3D NOCP clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: switch + - const: nocp + required: - compatible - "#clock-cells" diff --git a/Documentation/devicetree/bindings/clock/tenstorrent,atlantis-prcm-rcpu.yaml b/Documentation/devicetree/bindings/clock/tenstorrent,atlantis-prcm-rcpu.yaml new file mode 100644 index 000000000000..7fa16526efce --- /dev/null +++ b/Documentation/devicetree/bindings/clock/tenstorrent,atlantis-prcm-rcpu.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/tenstorrent,atlantis-prcm-rcpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tenstorrent Atlantis PRCM (Power, Reset, Clock Management) Module + +maintainers: + - Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> + +description: + Multifunctional register block found in Tenstorrent Atlantis SoC whose main + function is to control clocks and resets. This block is instantiated multiple + times in the SoC, each block controls clock and resets for a different + subsystem. RCPU prcm serves low speed IO interfaces. + +properties: + compatible: + enum: + - tenstorrent,atlantis-prcm-rcpu + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#clock-cells": + const: 1 + description: + See <dt-bindings/clock/tenstorrent,atlantis-prcm-rcpu.h> for valid indices. + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + clock-controller@a8000000 { + compatible = "tenstorrent,atlantis-prcm-rcpu"; + reg = <0xa8000000 0x10000>; + clocks = <&osc_24m>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml new file mode 100644 index 000000000000..f7859aa9b634 --- /dev/null +++ b/Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/connector/pcie-m2-e-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PCIe M.2 Mechanical Key E Connector + +maintainers: + - Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> + +description: + A PCIe M.2 E connector node represents a physical PCIe M.2 Mechanical Key E + connector. Mechanical Key E connectors are used to connect Wireless + Connectivity devices including combinations of Wi-Fi, BT, NFC to the host + machine over interfaces like PCIe/SDIO, USB/UART+PCM, and I2C. + +properties: + compatible: + const: pcie-m2-e-connector + + vpcie3v3-supply: + description: A phandle to the regulator for 3.3v supply. + + vpcie1v8-supply: + description: A phandle to the regulator for VIO 1.8v supply. + + i2c-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: I2C interface + + clocks: + description: 32.768 KHz Suspend Clock (SUSCLK) input from the host system to + the M.2 card. Refer, PCI Express M.2 Specification r4.0, sec 3.1.12.1 for + more details. + maxItems: 1 + + w-disable1-gpios: + description: GPIO output to W_DISABLE1# signal. This signal is used by the + host system to disable WiFi radio in the M.2 card. Refer, PCI Express M.2 + Specification r4.0, sec 3.1.12.3 for more details. + maxItems: 1 + + w-disable2-gpios: + description: GPIO output to W_DISABLE2# signal. This signal is used by the + host system to disable BT radio in the M.2 card. Refer, PCI Express M.2 + Specification r4.0, sec 3.1.12.3 for more details. + maxItems: 1 + + viocfg-gpios: + description: GPIO input to IO voltage configuration (VIO_CFG) signal. The + card drives this signal to indicate to the host system whether the card + supports an independent IO voltage domain for sideband signals. Refer, + PCI Express M.2 Specification r4.0, sec 3.1.15.1 for more details. + maxItems: 1 + + uart-wake-gpios: + description: GPIO input to UART_WAKE# signal. The card asserts this signal + to wake the host system and initiate UART interface communication. Refer, + PCI Express M.2 Specification r4.0, sec 3.1.8.1 for more details. + maxItems: 1 + + sdio-wake-gpios: + description: GPIO input to SDIO_WAKE# signal. The card asserts this signal + to wake the host system and initiate SDIO interface communication. Refer, + PCI Express M.2 Specification r4.0, sec 3.1.7 for more details. + maxItems: 1 + + sdio-reset-gpios: + description: GPIO output to SDIO_RESET# signal. This signal is used by the + host system to reset SDIO interface of the M.2 card. Refer, PCI Express + M.2 Specification r4.0, sec 3.1.7 for more details. + maxItems: 1 + + vendor-porta-gpios: + description: GPIO for the first vendor specific signal (VENDOR_PORTA). This + signal's functionality is defined by the card manufacturer and may be + used for proprietary features. Refer the card vendor's documentation for + details. + maxItems: 1 + + vendor-portb-gpios: + description: GPIO for the second vendor specific signal (VENDOR_PORTB). This + signal's functionality is defined by the card manufacturer and may be + used for proprietary features. Refer the card vendor's documentation for + details. + maxItems: 1 + + vendor-portc-gpios: + description: GPIO for the third vendor specific signal (VENDOR_PORTC). This + signal's functionality is defined by the card manufacturer and may be + used for proprietary features. Refer the card vendor's documentation for + details. + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: OF graph bindings modeling the interfaces exposed on the + connector. Since a single connector can have multiple interfaces, every + interface has an assigned OF graph port number as described below. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: PCIe interface for Wi-Fi + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: SDIO interface for Wi-Fi + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: USB 2.0 interface for BT + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: UART interface for BT + + port@4: + $ref: /schemas/graph.yaml#/properties/port + description: PCM/I2S interface + + anyOf: + - anyOf: + - required: + - port@0 + - required: + - port@1 + - anyOf: + - required: + - port@2 + - required: + - port@3 + +required: + - compatible + - vpcie3v3-supply + +additionalProperties: false + +examples: + # PCI M.2 Key E connector for Wi-Fi/BT with PCIe/UART interfaces + - | + #include <dt-bindings/gpio/gpio.h> + + connector { + compatible = "pcie-m2-e-connector"; + vpcie3v3-supply = <&vreg_wcn_3p3>; + vpcie1v8-supply = <&vreg_l15b_1p8>; + i2c-parent = <&i2c0>; + w-disable1-gpios = <&tlmm 115 GPIO_ACTIVE_LOW>; + w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>; + viocfg-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>; + uart-wake-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>; + sdio-wake-gpios = <&tlmm 119 GPIO_ACTIVE_LOW>; + sdio-reset-gpios = <&tlmm 120 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + endpoint@0 { + reg = <0>; + remote-endpoint = <&pcie4_port0_ep>; + }; + }; + + port@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + endpoint@0 { + reg = <0>; + remote-endpoint = <&uart14_ep>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 11e40d225b9f..8ca0292490a2 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -300,7 +300,42 @@ properties: $ref: /schemas/types.yaml#/definitions/uint8-array maxItems: 4 + sink-load-step: + description: Indicates the preferred load step slew rate in mA/usec for + the port (in sink mode). This property is defined in "6.5.13.7" of + "USB Power Delivery Specification Revision 3.1 Version 1.8". + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [150, 500] + default: 150 + + sink-load-characteristics: + description: Indicates the port's (in sink mode) preferred load + characteristics. Users can leverage SINK_LOAD_CHAR() defined in + dt-bindings/usb/pd.h to populate this field. This property is defined in + "6.5.13.8" of "USB Power Delivery Specification Revision 3.1 Version 1.8". + $ref: /schemas/types.yaml#/definitions/uint16 + + sink-compliance: + description: Represents the types of sources the sink device has been tested + and certified with. This property is defined in "6.5.13.9" of + "USB Power Delivery Specification Revision 3.1 Version 1.8" + Bit 0 when set indicates it has been tested on LPS compliant source + Bit 1 when set indicates it has been tested on PS1 compliant source + Bit 2 when set indicates it has been tested on PS2 compliant source + $ref: /schemas/types.yaml#/definitions/uint8 + maximum: 7 + + charging-adapter-pdp-milliwatt: + description: This corresponds to the Power Delivery Profile rating of the + charging adapter shipped or recommended for use with the connector port. + This property is a requirement to infer the USB PD property + "SPR Sink Operational PDP" given in "6.5.13.14" of + "USB Power Delivery Specification Revision 3.1 Version 1.8". + minimum: 0 + maximum: 100000 + dependencies: + pd-disable: [typec-power-opmode] sink-vdos-v1: [ sink-vdos ] sink-vdos: [ sink-vdos-v1 ] @@ -330,8 +365,9 @@ $defs: "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink Capabilities Message, the order of each entry(PDO) should follow the PD spec chapter 6.4.1. Required for power sink and power dual role. User - can specify the sink PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() defined - in dt-bindings/usb/pd.h. + can specify the sink PDO array via + PDO_FIXED/BATT/VAR/PPS_APDO/SPR_AVS_SNK_APDO() defined in + dt-bindings/usb/pd.h. minItems: 1 maxItems: 7 $ref: /schemas/types.yaml#/definitions/uint32-array diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml index 22eeaef14f55..98eb36bff172 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -35,6 +35,7 @@ properties: - description: v2 of CPUFREQ HW (EPSS) items: - enum: + - qcom,eliza-cpufreq-epss - qcom,milos-cpufreq-epss - qcom,qcs8300-cpufreq-epss - qcom,qdu1000-cpufreq-epss diff --git a/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml index 3dc6c5f89d32..a34d13e92c59 100644 --- a/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml +++ b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml @@ -18,6 +18,7 @@ properties: - items: - enum: - marvell,armada-3700-crypto + - mediatek,mt7981-crypto - mediatek,mt7986-crypto - const: inside-secure,safexcel-eip97ies - const: inside-secure,safexcel-eip197b @@ -80,7 +81,9 @@ allOf: compatible: not: contains: - const: mediatek,mt7986-crypto + enum: + - mediatek,mt7981-crypto + - mediatek,mt7986-crypto then: properties: interrupts: diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml index 061ff718b23d..876bf90ed96e 100644 --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml @@ -13,6 +13,7 @@ properties: compatible: items: - enum: + - qcom,eliza-inline-crypto-engine - qcom,kaanapali-inline-crypto-engine - qcom,milos-inline-crypto-engine - qcom,qcs8300-inline-crypto-engine @@ -31,6 +32,11 @@ properties: clocks: maxItems: 1 + operating-points-v2: true + + opp-table: + type: object + required: - compatible - reg @@ -47,5 +53,26 @@ examples: "qcom,inline-crypto-engine"; reg = <0x01d88000 0x8000>; clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>; + + operating-points-v2 = <&ice_opp_table>; + + ice_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-201500000 { + opp-hz = /bits/ 64 <201500000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-403000000 { + opp-hz = /bits/ 64 <403000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; }; ... diff --git a/Documentation/devicetree/bindings/display/arm,komeda.yaml b/Documentation/devicetree/bindings/display/arm,komeda.yaml index 3ad3eef89ca8..1afd254b6c2f 100644 --- a/Documentation/devicetree/bindings/display/arm,komeda.yaml +++ b/Documentation/devicetree/bindings/display/arm,komeda.yaml @@ -19,7 +19,9 @@ properties: compatible: oneOf: - items: - - const: arm,mali-d32 + - enum: + - arm,mali-d32 + - armchina,linlon-d6 - const: arm,mali-d71 - const: arm,mali-d71 diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index a1ed1004651b..6ad466952c02 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -85,6 +85,11 @@ properties: aux-bus: $ref: /schemas/display/dp-aux-bus.yaml# + connector: + type: object + $ref: /schemas/connector/usb-connector.yaml# + unevaluatedProperties: false + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -117,7 +122,6 @@ properties: required: - port@0 - - port@1 required: - compatible @@ -127,6 +131,28 @@ required: - vdd33-supply - ports +allOf: + - if: + required: + - aux-bus + - connector + then: + false + + - if: + required: + - connector + then: + properties: + ports: + properties: + port@1: false + else: + properties: + ports: + required: + - port@1 + additionalProperties: false examples: @@ -185,3 +211,73 @@ examples: }; }; }; + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + encoder@58 { + compatible = "analogix,anx7625"; + reg = <0x58>; + enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>; + reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>; + vdd10-supply = <&pp1000_mipibrdg>; + vdd18-supply = <&pp1800_mipibrdg>; + vdd33-supply = <&pp3300_mipibrdg>; + analogix,audio-enable; + analogix,lane0-swing = /bits/ 8 <0x14 0x54 0x64 0x74>; + analogix,lane1-swing = /bits/ 8 <0x14 0x54 0x64 0x74>; + + connector { + compatible = "usb-c-connector"; + power-role = "dual"; + data-role = "dual"; + vbus-supply = <&vbus_reg>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + endpoint { + remote-endpoint = <&usb_hs>; + }; + }; + + port@1 { + reg = <1>; + + endpoint { + remote-endpoint = <&usb_ss>; + }; + }; + + port@2 { + reg = <2>; + + endpoint { + remote-endpoint = <&usb_sbu>; + }; + }; + }; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&mipi_dsi>; + bus-type = <7>; + data-lanes = <0 1 2 3>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml index 49664101a353..7f380879fffd 100644 --- a/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml +++ b/Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml @@ -35,6 +35,15 @@ properties: - const: ldb - const: lvds + nxp,enable-termination-resistor: + type: boolean + description: + Indicates that the built-in 100 Ohm termination resistor on the LVDS + output is enabled. This property is optional and controlled via the + HS_EN bit in the LVDS_CTRL register. Enabling it can improve signal + quality and prevent visual artifacts on some boards, but increases + power consumption. + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -84,6 +93,15 @@ allOf: required: - reg-names + - if: + properties: + compatible: + contains: + const: fsl,imx6sx-ldb + then: + properties: + nxp,enable-termination-resistor: false + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8713sx.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8713sx.yaml new file mode 100644 index 000000000000..a5ba4db11a7c --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8713sx.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/lontium,lt8713sx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lontium LT8713SX Type-C/DP1.4 to Type-C/DP1.4/HDMI2.0/DP++ bridge-hub + +maintainers: + - Vishnu Saini <vishnu.saini@oss.qualcomm.com> + +description: + The Lontium LT8713SX is a Type-C/DP1.4 to Type-C/DP1.4/HDMI2.0 converter + that integrates one DP input and up to three configurable output interfaces + (DP1.4 / HDMI2.0 / DP++), with SST/MST functionality and audio support. + +properties: + compatible: + enum: + - lontium,lt8713sx + + reg: + maxItems: 1 + + vcc-supply: + description: Regulator for 3.3V vcc. + + vdd-supply: + description: Regulator for 1.1V vdd. + + reset-gpios: + description: GPIO connected to active low RESET pin. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + DP port for DP input from soc to bridge chip + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + DP port for DP output from bridge + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: + Additional DP port for DP output from bridge + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: + Additional DP port for DP output from bridge + + required: + - port@0 + +required: + - compatible + - reg + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + bridge@4f { + compatible = "lontium,lt8713sx"; + reg = <0x4f>; + reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + lt8713sx_dp_in: endpoint { + remote-endpoint = <&mdss_dp0_out>; + }; + }; + + port@1 { + reg = <1>; + lt8713sx_dp0_out: endpoint { + remote-endpoint = <&dp0_connector_in>; + }; + }; + + port@2 { + reg = <2>; + lt8713sx_dp1_out: endpoint { + remote-endpoint = <&dp1_connector_in>; + }; + }; + + port@3 { + reg = <3>; + lt8713sx_dp2_out: endpoint { + remote-endpoint = <&dp2_connector_in>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml index 63f000ebc9c5..988351f3cd01 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml @@ -39,9 +39,6 @@ properties: $ref: /schemas/media/video-interfaces.yaml# unevaluatedProperties: false - properties: - data-lanes: true - required: - data-lanes diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml index 655db8cfdc25..429a06057ae8 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml @@ -44,21 +44,28 @@ properties: port@0: $ref: /schemas/graph.yaml#/properties/port description: - Primary MIPI port-1 for MIPI input + DSI Port A input. directly drives the display, or works in + combination with Port B for higher resolution displays. port@1: $ref: /schemas/graph.yaml#/properties/port description: - Additional MIPI port-2 for MIPI input, used in combination - with primary MIPI port-1 to drive higher resolution displays + DSI Port B input. Can be used alone if DSI is physically + connected to Port B, or in combination with Port A for higher + resolution displays. port@2: $ref: /schemas/graph.yaml#/properties/port description: HDMI port for HDMI output + anyOf: + - required: + - port@0 + - required: + - port@1 + required: - - port@0 - port@2 required: diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 4f52e35d0253..7586d681bcc6 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -33,6 +33,7 @@ properties: oneOf: - items: - enum: + - doestek,dtc34lm85am # For the Doestek DTC34LM85AM Flat Panel Display (FPD) Transmitter - onnn,fin3385 # OnSemi FIN3385 - ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer - ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer diff --git a/Documentation/devicetree/bindings/display/bridge/thead,th1520-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/thead,th1520-dw-hdmi.yaml new file mode 100644 index 000000000000..68fff885ce15 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/thead,th1520-dw-hdmi.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/thead,th1520-dw-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: T-Head TH1520 DesignWare HDMI TX Encoder + +maintainers: + - Icenowy Zheng <uwu@icenowy.me> + +description: + The HDMI transmitter is a Synopsys DesignWare HDMI TX controller + paired with a DesignWare HDMI Gen2 TX PHY. + +allOf: + - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml# + +properties: + compatible: + enum: + - thead,th1520-dw-hdmi + + reg-io-width: + const: 4 + + clocks: + maxItems: 4 + + clock-names: + items: + - const: iahb + - const: isfr + - const: cec + - const: pix + + resets: + items: + - description: Main reset + - description: Configuration APB reset + + reset-names: + items: + - const: main + - const: apb + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input port connected to DC8200 DPU "DP" output + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: HDMI output port + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - reg-io-width + - clocks + - clock-names + - resets + - reset-names + - interrupts + - ports + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/thead,th1520-clk-ap.h> + #include <dt-bindings/reset/thead,th1520-reset.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + hdmi@ffef540000 { + compatible = "thead,th1520-dw-hdmi"; + reg = <0xff 0xef540000 0x0 0x40000>; + reg-io-width = <4>; + interrupts = <111 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk_vo CLK_HDMI_PCLK>, + <&clk_vo CLK_HDMI_SFR>, + <&clk_vo CLK_HDMI_CEC>, + <&clk_vo CLK_HDMI_PIXCLK>; + clock-names = "iahb", "isfr", "cec", "pix"; + resets = <&rst_vo TH1520_RESET_ID_HDMI>, + <&rst_vo TH1520_RESET_ID_HDMI_APB>; + reset-names = "main", "apb"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + + hdmi_in: endpoint { + remote-endpoint = <&dpu_out_dp1>; + }; + }; + + port@1 { + reg = <1>; + + hdmi_out_conn: endpoint { + remote-endpoint = <&hdmi_conn_in>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml b/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml index 5e8498c8303d..3820dd7e11af 100644 --- a/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml @@ -40,9 +40,12 @@ properties: properties: data-lanes: description: array of physical DSI data lane indexes. + minItems: 1 items: - const: 1 - const: 2 + - const: 3 + - const: 4 required: - data-lanes diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index daf90ebb39bf..4bbea72b292a 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -33,6 +33,7 @@ properties: - enum: - mediatek,mt2712-disp-aal - mediatek,mt6795-disp-aal + - mediatek,mt8167-disp-aal - const: mediatek,mt8173-disp-aal - items: - enum: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index fca8e7bb0cbc..5c5068128d0c 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -25,7 +25,9 @@ properties: - mediatek,mt8183-disp-ccorr - mediatek,mt8192-disp-ccorr - items: - - const: mediatek,mt8365-disp-ccorr + - enum: + - mediatek,mt8167-disp-ccorr + - mediatek,mt8365-disp-ccorr - const: mediatek,mt8183-disp-ccorr - items: - enum: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index abaf27916d13..891c95be15b9 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt8183-disp-dither - items: - enum: + - mediatek,mt8167-disp-dither - mediatek,mt8186-disp-dither - mediatek,mt8188-disp-dither - mediatek,mt8192-disp-dither diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index 48542dc7e784..ec1054bb06d4 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -28,6 +28,7 @@ properties: - items: - enum: - mediatek,mt6795-disp-gamma + - mediatek,mt8167-disp-gamma - const: mediatek,mt8173-disp-gamma - items: - enum: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index 4f110635afb6..679f731f0f15 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -23,6 +23,7 @@ properties: oneOf: - enum: - mediatek,mt2701-disp-ovl + - mediatek,mt8167-disp-ovl - mediatek,mt8173-disp-ovl - mediatek,mt8183-disp-ovl - mediatek,mt8192-disp-ovl diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml index 878f676b581f..cb187a95c11e 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml @@ -36,6 +36,7 @@ properties: - enum: - mediatek,mt7623-disp-rdma - mediatek,mt2712-disp-rdma + - mediatek,mt8167-disp-rdma - const: mediatek,mt2701-disp-rdma - items: - enum: diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml index a3a2b71a4523..816841a96133 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml @@ -24,7 +24,9 @@ properties: - enum: - mediatek,mt8173-disp-wdma - items: - - const: mediatek,mt6795-disp-wdma + - enum: + - mediatek,mt6795-disp-wdma + - mediatek,mt8167-disp-wdma - const: mediatek,mt8173-disp-wdma reg: diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 02ddfaab5f56..8239adb7f7d3 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -67,6 +67,7 @@ properties: - items: - enum: + - qcom,eliza-dp - qcom,sm8750-dp - const: qcom,sm8650-dp diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index eb6d38dabb08..a24fcb914418 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -49,8 +49,13 @@ properties: - items: - enum: - qcom,qcs8300-dsi-ctrl + - qcom,sc8280xp-dsi-ctrl - const: qcom,sa8775p-dsi-ctrl - const: qcom,mdss-dsi-ctrl + - items: + - const: qcom,eliza-dsi-ctrl + - const: qcom,sm8750-dsi-ctrl + - const: qcom,mdss-dsi-ctrl - enum: - qcom,dsi-ctrl-6g-qcm2290 - qcom,mdss-dsi-ctrl # This should always come with an SoC-specific compatible diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml index e32056ae0f5d..93e5e6e19754 100644 --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml @@ -91,6 +91,7 @@ allOf: compatible: contains: enum: + - qcom,adreno-gmu-615.0 - qcom,adreno-gmu-618.0 - qcom,adreno-gmu-630.2 then: diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml index ec84b64d4c00..04b2328903ca 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml @@ -440,13 +440,6 @@ allOf: clocks: false clock-names: false - reg-names: - minItems: 1 - items: - - const: kgsl_3d0_reg_memory - - const: cx_mem - - const: cx_dbgc - examples: - | diff --git a/Documentation/devicetree/bindings/display/msm/qcom,eliza-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,eliza-mdss.yaml new file mode 100644 index 000000000000..47938d13d1ca --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,eliza-mdss.yaml @@ -0,0 +1,494 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,eliza-mdss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Eliza SoC Display MDSS + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +description: + Eliza SoC Mobile Display Subsystem (MDSS) encapsulates sub-blocks like DPU + display controller, DSI and DP interfaces etc. + +$ref: /schemas/display/msm/mdss-common.yaml# + +properties: + compatible: + const: qcom,eliza-mdss + + clocks: + items: + - description: Display AHB + - description: Display hf AXI + - description: Display core + + iommus: + maxItems: 1 + + interconnects: + items: + - description: Interconnect path from mdp0 port to the data bus + - description: Interconnect path from CPU to the reg bus + + interconnect-names: + items: + - const: mdp0-mem + - const: cpu-cfg + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + contains: + const: qcom,eliza-dpu + + "^displayport-controller@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + contains: + const: qcom,eliza-dp + + "^dsi@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + contains: + const: qcom,eliza-dsi-ctrl + + "^phy@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + contains: + const: qcom,eliza-dsi-phy-4nm + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dsi-phy-28nm.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interconnect/qcom,icc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/phy/phy-qcom-qmp.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + + display-subsystem@ae00000 { + compatible = "qcom,eliza-mdss"; + reg = <0x0ae00000 0x1000>; + reg-names = "mdss"; + ranges; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&disp_cc_mdss_ahb_clk>, + <&gcc_disp_hf_axi_clk>, + <&disp_cc_mdss_mdp_clk>; + + resets = <&disp_cc_mdss_core_bcr>; + + interconnects = <&mmss_noc_master_mdp QCOM_ICC_TAG_ALWAYS + &mc_virt_slave_ebi1 QCOM_ICC_TAG_ALWAYS>, + <&gem_noc_master_appss_proc QCOM_ICC_TAG_ACTIVE_ONLY + &config_noc_slave_display_cfg QCOM_ICC_TAG_ACTIVE_ONLY>; + interconnect-names = "mdp0-mem", + "cpu-cfg"; + + power-domains = <&mdss_gdsc>; + + iommus = <&apps_smmu 0x800 0x2>; + + interrupt-controller; + #interrupt-cells = <1>; + + #address-cells = <1>; + #size-cells = <1>; + + mdss_mdp: display-controller@ae01000 { + compatible = "qcom,eliza-dpu"; + reg = <0x0ae01000 0x93000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", + "vbif"; + + interrupts-extended = <&mdss 0>; + + clocks = <&gcc_disp_hf_axi_clk>, + <&disp_cc_mdss_ahb_clk>, + <&disp_cc_mdss_mdp_lut_clk>, + <&disp_cc_mdss_mdp_clk>, + <&disp_cc_mdss_vsync_clk>; + clock-names = "nrt_bus", + "iface", + "lut", + "core", + "vsync"; + + assigned-clocks = <&disp_cc_mdss_vsync_clk>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + dpu_intf1_out: endpoint { + remote-endpoint = <&mdss_dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + + dpu_intf2_out: endpoint { + remote-endpoint = <&mdss_dsi1_in>; + }; + }; + + port@2 { + reg = <2>; + + dpu_intf0_out: endpoint { + remote-endpoint = <&mdss_dp0_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-150000000 { + opp-hz = /bits/ 64 <150000000>; + required-opps = <&rpmhpd_opp_low_svs_d1>; + }; + + opp-207000000 { + opp-hz = /bits/ 64 <207000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-342000000 { + opp-hz = /bits/ 64 <342000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-417000000 { + opp-hz = /bits/ 64 <417000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-532000000 { + opp-hz = /bits/ 64 <532000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + required-opps = <&rpmhpd_opp_nom_l1>; + }; + + opp-660000000 { + opp-hz = /bits/ 64 <660000000>; + required-opps = <&rpmhpd_opp_turbo>; + }; + }; + }; + + dsi@ae94000 { + compatible = "qcom,eliza-dsi-ctrl", "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x0ae94000 0x400>; + reg-names = "dsi_ctrl"; + + interrupts-extended = <&mdss 4>; + + clocks = <&disp_cc_mdss_byte0_clk>, + <&disp_cc_mdss_byte0_intf_clk>, + <&disp_cc_mdss_pclk0_clk>, + <&disp_cc_mdss_esc0_clk>, + <&disp_cc_mdss_ahb_clk>, + <&gcc_disp_hf_axi_clk>, + <&mdss_dsi0_phy DSI_PIXEL_PLL_CLK>, + <&mdss_dsi0_phy DSI_BYTE_PLL_CLK>, + <&disp_cc_esync0_clk>, + <&disp_cc_osc_clk>, + <&disp_cc_mdss_byte0_clk_src>, + <&disp_cc_mdss_pclk0_clk_src>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus", + "dsi_pll_pixel", + "dsi_pll_byte", + "esync", + "osc", + "byte_src", + "pixel_src"; + + operating-points-v2 = <&mdss_dsi_opp_table>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + + phys = <&mdss_dsi0_phy>; + phy-names = "dsi"; + + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mdss_dsi0_in: endpoint { + remote-endpoint = <&dpu_intf1_out>; + }; + }; + + port@1 { + reg = <1>; + + mdss_dsi0_out: endpoint { + remote-endpoint = <&panel0_in>; + data-lanes = <0 1 2 3>; + }; + }; + }; + + mdss_dsi_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-140630000 { + opp-hz = /bits/ 64 <140630000>; + required-opps = <&rpmhpd_opp_low_svs_d1>; + }; + + opp-187500000 { + opp-hz = /bits/ 64 <187500000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-300000000 { + opp-hz = /bits/ 64 <300000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-358000000 { + opp-hz = /bits/ 64 <358000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + }; + }; + + mdss_dsi0_phy: phy@ae95000 { + compatible = "qcom,eliza-dsi-phy-4nm", "qcom,sm8650-dsi-phy-4nm"; + reg = <0x0ae95000 0x200>, + <0x0ae95200 0x280>, + <0x0ae95500 0x400>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + clocks = <&disp_cc_mdss_ahb_clk>, + <&bi_tcxo_div2>; + clock-names = "iface", + "ref"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vdds-supply = <&vreg_l2b>; + }; + + dsi@ae96000 { + compatible = "qcom,eliza-dsi-ctrl", "qcom,sm8750-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x0ae96000 0x400>; + reg-names = "dsi_ctrl"; + + interrupts-extended = <&mdss 5>; + + clocks = <&disp_cc_mdss_byte1_clk>, + <&disp_cc_mdss_byte1_intf_clk>, + <&disp_cc_mdss_pclk1_clk>, + <&disp_cc_mdss_esc1_clk>, + <&disp_cc_mdss_ahb_clk>, + <&gcc_disp_hf_axi_clk>, + <&mdss_dsi1_phy DSI_PIXEL_PLL_CLK>, + <&mdss_dsi1_phy DSI_BYTE_PLL_CLK>, + <&disp_cc_esync1_clk>, + <&disp_cc_osc_clk>, + <&disp_cc_mdss_byte1_clk_src>, + <&disp_cc_mdss_pclk1_clk_src>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus", + "dsi_pll_pixel", + "dsi_pll_byte", + "esync", + "osc", + "byte_src", + "pixel_src"; + + operating-points-v2 = <&mdss_dsi_opp_table>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + + phys = <&mdss_dsi1_phy>; + phy-names = "dsi"; + + vdda-supply = <&vreg_l4b>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mdss_dsi1_in: endpoint { + remote-endpoint = <&dpu_intf2_out>; + }; + }; + + port@1 { + reg = <1>; + + mdss_dsi1_out: endpoint { + remote-endpoint = <&panel1_in>; + data-lanes = <0 1 2 3>; + }; + }; + }; + }; + + mdss_dsi1_phy: phy@ae97000 { + compatible = "qcom,eliza-dsi-phy-4nm", "qcom,sm8650-dsi-phy-4nm"; + reg = <0x0ae97000 0x200>, + <0x0ae97200 0x280>, + <0x0ae97500 0x400>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + clocks = <&disp_cc_mdss_ahb_clk>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", + "ref"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vdds-supply = <&vreg_l2b>; + }; + + displayport-controller@af54000 { + compatible = "qcom,eliza-dp", "qcom,sm8650-dp"; + reg = <0xaf54000 0x104>, + <0xaf54200 0xc0>, + <0xaf55000 0x770>, + <0xaf56000 0x9c>, + <0xaf57000 0x9c>; + + interrupts-extended = <&mdss 12>; + + clocks = <&disp_cc_mdss_ahb_clk>, + <&disp_cc_mdss_dptx0_aux_clk>, + <&disp_cc_mdss_dptx0_link_clk>, + <&disp_cc_mdss_dptx0_link_intf_clk>, + <&disp_cc_mdss_dptx0_pixel0_clk>, + <&disp_cc_mdss_dptx0_pixel1_clk>; + clock-names = "core_iface", + "core_aux", + "ctrl_link", + "ctrl_link_iface", + "stream_pixel", + "stream_1_pixel"; + + assigned-clocks = <&disp_cc_mdss_dptx0_link_clk_src>, + <&disp_cc_mdss_dptx0_pixel0_clk_src>, + <&disp_cc_mdss_dptx0_pixel1_clk_src>; + assigned-clock-parents = <&usb_dp_qmpphy QMP_USB43DP_DP_LINK_CLK>, + <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>, + <&usb_dp_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>; + + operating-points-v2 = <&dp_opp_table>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + + phys = <&usb_dp_qmpphy QMP_USB43DP_DP_PHY>; + phy-names = "dp"; + + #sound-dai-cells = <0>; + + dp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-192000000 { + opp-hz = /bits/ 64 <192000000>; + required-opps = <&rpmhpd_opp_low_svs_d1>; + }; + + opp-270000000 { + opp-hz = /bits/ 64 <270000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-540000000 { + opp-hz = /bits/ 64 <540000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-810000000 { + opp-hz = /bits/ 64 <810000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mdss_dp0_in: endpoint { + remote-endpoint = <&dpu_intf0_out>; + }; + }; + + port@1 { + reg = <1>; + + mdss_dp0_out: endpoint { + data-lanes = <0 1 2 3>; + remote-endpoint = <&usb_dp_qmpphy_dp_in>; + link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml index f0cdb5422688..bb09ecd1a5b4 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml @@ -33,7 +33,7 @@ properties: - const: core iommus: - maxItems: 2 + maxItems: 1 interconnects: items: @@ -107,8 +107,7 @@ examples: interconnect-names = "mdp0-mem", "cpu-cfg"; - iommus = <&apps_smmu 0x420 0x2>, - <&apps_smmu 0x421 0x0>; + iommus = <&apps_smmu 0x420 0x2>; ranges; display-controller@5e01000 { diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml index af79406e1604..a710cc84ec57 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc8280xp-mdss.yaml @@ -50,6 +50,22 @@ patternProperties: - qcom,sc8280xp-dp - qcom,sc8280xp-edp + "^dsi@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + contains: + const: qcom,sc8280xp-dsi-ctrl + + "^phy@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + contains: + const: qcom,sc8280xp-dsi-phy-5nm + unevaluatedProperties: false examples: @@ -129,6 +145,20 @@ examples: }; }; + port@1 { + reg = <1>; + dpu_intf1_out: endpoint { + remote-endpoint = <&mdss0_dsi0_in>; + }; + }; + + port@2 { + reg = <2>; + dpu_intf2_out: endpoint { + remote-endpoint = <&mdss0_dsi1_in>; + }; + }; + port@4 { reg = <4>; endpoint { diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml index e29c4687c3a2..dccac525d202 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml @@ -15,6 +15,7 @@ properties: compatible: oneOf: - enum: + - qcom,eliza-dpu - qcom,glymur-dpu - qcom,kaanapali-dpu - qcom,sa8775p-dpu diff --git a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml index 0aa2d3fbadaa..72cbb9ee5eae 100644 --- a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml +++ b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml @@ -20,11 +20,6 @@ properties: reg: maxItems: 1 - backlight: true - port: true - power-supply: true - reset-gpios: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml index f6fea9085aab..76b48836ddf6 100644 --- a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml @@ -41,8 +41,6 @@ properties: panel-timing: true port: true -additionalProperties: false - required: - compatible - data-mapping @@ -51,6 +49,8 @@ required: - panel-timing - port +additionalProperties: false + examples: - |+ panel { diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml index 05ca3b2385f8..c9b066e69e2f 100644 --- a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml @@ -56,8 +56,6 @@ properties: - port@0 - port@1 -additionalProperties: false - required: - compatible - width-mm @@ -65,6 +63,8 @@ required: - data-mapping - panel-timing +additionalProperties: false + examples: - |+ panel-lvds { diff --git a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml index bbf127fb28f7..46e7cff5b2fa 100644 --- a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml +++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml @@ -22,10 +22,10 @@ properties: enable-gpios: true port: true -additionalProperties: false - required: - compatible - power-supply +additionalProperties: false + ... diff --git a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml index 287e2feb6533..9a2c532dbc92 100644 --- a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml +++ b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml @@ -22,10 +22,10 @@ properties: backlight: true port: true -additionalProperties: false - required: - compatible - power-supply +additionalProperties: false + ... diff --git a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml index 92df69e80a82..f288fa2390c9 100644 --- a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml +++ b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml @@ -28,7 +28,6 @@ properties: port: true reset-gpios: true - backlight: true required: diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml index e4c1aa5deab9..66404b425af3 100644 --- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml @@ -20,6 +20,8 @@ properties: - boe,nv110wum-l60 # CSOT pna957qt1-1 10.95" WUXGA TFT LCD panel - csot,pna957qt1-1 + # Holitech HTF065H045 6.517" 720x1600 TFT LCD panel + - holitech,htf065h045 # IVO t109nw41 11.0" WUXGA TFT LCD panel - ivo,t109nw41 # KINGDISPLAY KD110N11-51IE 10.95" WUXGA TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml index 56bcd152f43c..2c60d0cd704e 100644 --- a/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml @@ -33,8 +33,6 @@ properties: vsp-supply: description: Negative source voltage rail - port: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83121a.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83121a.yaml new file mode 100644 index 000000000000..e067a2f6d0b2 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83121a.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/himax,hx83121a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Himax HX83121A based DSI display Panels + +maintainers: + - Pengyu Luo <mitltlatltl@gmail.com> + +description: + The Himax HX83121A is a generic DSI Panel IC used to drive dsi + panels. Support video mode panels from China Star Optoelectronics + Technology (CSOT) and BOE Technology. + +allOf: + - $ref: panel-common-dual.yaml# + +properties: + compatible: + items: + - enum: + - boe,ppc357db1-4 + - csot,ppc357db1-4 + - const: himax,hx83121a + + reg: + maxItems: 1 + + reset-gpios: + maxItems: 1 + + avdd-supply: + description: analog positive supply for IC + + avee-supply: + description: analog negative supply for IC + + vddi-supply: + description: power supply for IC + + backlight: true + ports: true + +required: + - compatible + - reg + - vddi-supply + - reset-gpios + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "csot,ppc357db1-4", "himax,hx83121a"; + reg = <0>; + + vddi-supply = <&vreg_l2b>; + reset-gpios = <&tlmm 38 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + panel_in_0: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1{ + reg = <1>; + panel_in_1: endpoint { + remote-endpoint = <&dsi1_out>; + }; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml index 5725a587e35c..84e840e0224f 100644 --- a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml +++ b/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml @@ -33,11 +33,8 @@ properties: maxItems: 1 reset-gpios: true - backlight: true - rotation: true - port: true vcc-supply: @@ -54,8 +51,6 @@ required: - vcc-supply - iovcc-supply -additionalProperties: false - allOf: - $ref: panel-common.yaml# - if: @@ -68,6 +63,8 @@ allOf: required: - reset-gpios +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml index ef5a2240b684..cc80d0e90f1a 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml @@ -34,10 +34,6 @@ properties: maxItems: 1 description: Display data/command selection (D/CX) - backlight: true - reset-gpios: true - rotation: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml index 4bdc33d12306..c97bfd0f2ebc 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml @@ -29,9 +29,6 @@ properties: reg: maxItems: 1 - reset-gpios: true - port: true - vcc-supply: description: Core voltage supply diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml index 5f41758c96d5..aeb7cb26c058 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml @@ -40,8 +40,6 @@ properties: spi-max-frequency: const: 10000000 - port: true - vci-supply: description: Analog voltage supply (2.5 .. 3.3V) @@ -51,8 +49,6 @@ properties: vddi-led-supply: description: Voltage supply for the LED driver (1.65 .. 3.3 V) -unevaluatedProperties: false - required: - compatible - reg @@ -68,6 +64,8 @@ then: required: - port +unevaluatedProperties: false + examples: - |+ #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9806e.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9806e.yaml index f80307579485..2080d9e0ffac 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9806e.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9806e.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/display/panel/ilitek,ili9806e.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Ilitek ILI9806E based MIPI-DSI panels +title: Ilitek ILI9806E based panels maintainers: - Michael Walle <mwalle@kernel.org> @@ -18,6 +18,7 @@ properties: - enum: - densitron,dmt028vghmcmi-1d - ortustech,com35h3p70ulc + - rocktech,rk050hr345-ct106a - const: ilitek,ili9806e reg: @@ -30,11 +31,24 @@ required: - compatible - reg - vdd-supply - - vccio-supply - reset-gpios - backlight - port +if: + properties: + compatible: + contains: + enum: + - rocktech,rk050hr345-ct106a +then: + $ref: /schemas/spi/spi-peripheral-props.yaml# + required: + - spi-max-frequency +else: + required: + - vccio-supply + unevaluatedProperties: false examples: @@ -60,5 +74,25 @@ examples: }; }; }; + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "rocktech,rk050hr345-ct106a", "ilitek,ili9806e"; + reg = <0>; + vdd-supply = <®_vdd_panel>; + spi-max-frequency = <10000000>; + reset-gpios = <&gpiob 6 GPIO_ACTIVE_LOW>; + backlight = <&backlight>; + port { + panel_in_rgb: endpoint { + remote-endpoint = <<dc_out_rgb>; + }; + }; + }; + }; ... diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml index c7df9a7f6589..59cc7edb22bb 100644 --- a/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml +++ b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml @@ -20,11 +20,6 @@ properties: reg: maxItems: 1 - backlight: true - port: true - power-supply: true - reset-gpios: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml index 4164e3f7061d..7c75e01797f6 100644 --- a/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml +++ b/Documentation/devicetree/bindings/display/panel/innolux,p097pfg.yaml @@ -10,7 +10,7 @@ maintainers: - Lin Huang <hl@rock-chips.com> allOf: - - $ref: panel-common.yaml# + - $ref: panel-common-dual.yaml# properties: compatible: @@ -28,6 +28,9 @@ properties: avee-supply: description: The regulator that provides negative voltage + port: true + ports: true + required: - compatible - reg @@ -52,6 +55,27 @@ examples: avee-supply = <&avee>; backlight = <&backlight>; enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; + + port@1 { + reg = <1>; + + mipi1_in_panel: endpoint { + remote-endpoint = <&mipi1_out_panel>; + }; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml index 5802fb3c9ffe..e39efb44ed42 100644 --- a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml +++ b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml @@ -23,6 +23,7 @@ properties: - melfas,lmfbx101117480 - radxa,display-10hd-ad001 - radxa,display-8hd-ad002 + - taiguanck,xti05101-01a - const: jadard,jd9365da-h3 reg: @@ -35,9 +36,8 @@ properties: description: supply regulator for VCCIO, usually 1.8V reset-gpios: true - backlight: true - + rotation: true port: true required: diff --git a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml index d86c916f7b55..fe7ad266e1b0 100644 --- a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml +++ b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml @@ -20,11 +20,6 @@ properties: reg: maxItems: 1 - backlight: true - port: true - power-supply: true - reset-gpios: true - spi-3wire: true required: diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml index 5fcea62fd58f..2f49a6bbf3d7 100644 --- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml @@ -25,6 +25,7 @@ properties: backlight: true port: true reset-gpios: true + iovcc-supply: description: regulator that supplies the iovcc voltage vci-supply: diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml index b0e2c82232d3..3f56047f4469 100644 --- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml @@ -24,6 +24,7 @@ properties: backlight: true port: true reset-gpios: true + iovcc-supply: description: regulator that supplies the iovcc voltage vcc-supply: diff --git a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml index 3de17fd8513b..3c8c65c6a869 100644 --- a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml +++ b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml @@ -20,10 +20,6 @@ properties: reg: maxItems: 1 - label: true - enable-gpios: true - port: true - spi-cpha: true spi-cpol: true diff --git a/Documentation/devicetree/bindings/display/panel/lxd,m9189a.yaml b/Documentation/devicetree/bindings/display/panel/lxd,m9189a.yaml new file mode 100644 index 000000000000..226974a4077f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lxd,m9189a.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/lxd,m9189a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LXD M9189A DSI Display Panel + +maintainers: + - Michael Tretter <m.tretter@pengutronix.de> + +allOf: + - $ref: panel-common.yaml + +properties: + compatible: + const: lxd,m9189a + + reg: + maxItems: 1 + + standby-gpios: + description: GPIO used for the standby pin + maxItems: 1 + + reset-gpios: true + power-supply: true + backlight: true + port: true + +required: + - compatible + - reg + - standby-gpios + - reset-gpios + - power-supply + - backlight + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "lxd,m9189a"; + reg = <0>; + backlight = <&backlight>; + reset-gpios = <&gpio3 25 GPIO_ACTIVE_LOW>; + standby-gpios = <&gpio5 22 GPIO_ACTIVE_LOW>; + power-supply = <®_display_3v3>; + + port { + mipi_panel_in: endpoint { + remote-endpoint = <&mipi_dsi_out>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml index 74ff772973d6..b8b153a6e6cc 100644 --- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml +++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml @@ -22,7 +22,6 @@ properties: - mantix,mlaf057we51-x - ys,ys57pss36bh5gq - port: true reg: maxItems: 1 description: DSI virtual channel @@ -36,13 +35,13 @@ properties: vddi-supply: description: 1.8V I/O voltage supply - reset-gpios: true - mantix,tp-rstn-gpios: maxItems: 1 description: second reset line that triggers DSI config load backlight: true + port: true + reset-gpios: true required: - compatible diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml index 96621b89ae9e..43e98bb07c38 100644 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml @@ -47,8 +47,6 @@ properties: panel-timing: true port: true -additionalProperties: false - required: - compatible - data-mapping @@ -57,6 +55,8 @@ required: - panel-timing - port +additionalProperties: false + examples: - |+ diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml index 37f01d847aac..2af993d73619 100644 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml @@ -44,8 +44,6 @@ properties: panel-timing: true port: true -additionalProperties: false - required: - compatible - vcc-supply @@ -55,6 +53,8 @@ required: - panel-timing - port +additionalProperties: false + examples: - |+ panel { diff --git a/Documentation/devicetree/bindings/display/panel/motorola,mot-panel.yaml b/Documentation/devicetree/bindings/display/panel/motorola,mot-panel.yaml new file mode 100644 index 000000000000..99fa1b3ed426 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/motorola,mot-panel.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/motorola,mot-panel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atrix 4G and Droid X2 DSI Display Panel + +maintainers: + - Svyatoslav Ryhel <clamor95@gmail.com> + +description: + Atrix 4G and Droid X2 use the same 540x960 DSI video mode panel. Exact + panel vendor and model are unknown hence generic compatible based on the + board name "Mot" is used. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - const: motorola,mot-panel + + reg: + maxItems: 1 + + vdd-supply: + description: Regulator for main power supply. + + vddio-supply: + description: Regulator for 1.8V IO power supply. + + backlight: true + reset-gpios: true + port: true + +required: + - compatible + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "motorola,mot-panel"; + reg = <0>; + + reset-gpios = <&gpio 35 GPIO_ACTIVE_LOW>; + + vdd-supply = <&vdd_5v0_panel>; + vddio-supply = <&vdd_1v8_vio>; + + backlight = <&backlight>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml index 1cffe4d6d498..eb9eeba92359 100644 --- a/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml +++ b/Documentation/devicetree/bindings/display/panel/nec,nl8048hl11.yaml @@ -24,10 +24,6 @@ properties: reg: maxItems: 1 - label: true - port: true - reset-gpios: true - spi-max-frequency: maximum: 10000000 diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml index b39fd0c5a48a..43d134daf0ac 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml @@ -28,13 +28,14 @@ properties: reg: maxItems: 1 - reset-gpios: true vdd-supply: description: regulator that supplies the vdd voltage vddi-supply: description: regulator that supplies the vddi voltage + backlight: true port: true + reset-gpios: true required: - compatible diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml index c4bae4f77085..b9300a1f2646 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml @@ -37,9 +37,6 @@ properties: vddio-supply: description: regulator that supplies the I/O voltage - rotation: true - backlight: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml index 800a2f0a4dad..5d16d8511725 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml @@ -47,9 +47,6 @@ properties: vddneg-supply: description: phandle of the negative boost supply regulator - port: true - backlight: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml index 1e4f140f48b8..1f697dab832b 100644 --- a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml +++ b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml @@ -31,12 +31,12 @@ properties: reset-gpios: maxItems: 1 -additionalProperties: false - required: - compatible - reg +additionalProperties: false + examples: - | dsi { diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml b/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml index b308047c1edf..afe7dc54ebf4 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-edp-legacy.yaml @@ -44,6 +44,8 @@ properties: - boe,nv133fhm-n62 # BOE NV140FHM-N49 14.0" FHD a-Si FT panel - boe,nv140fhmn49 + # FriendlyELEC HD702E 800x1280 LCD panel + - friendlyarm,hd702e # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel - innolux,n116bca-ea1 # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml index dbc01e640895..b31c67babaa8 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -58,6 +58,10 @@ properties: - hydis,hv070wx2-1e0 # Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel - jenson,bl-jt60050-01a + # Samsung LTN070NL01 7.0" WSVGA (1024x600) TFT LCD LVDS panel + - samsung,ltn070nl01 + # Samsung LTN101AL03 10.1" WXGA (800x1280) TFT LCD LVDS panel + - samsung,ltn101al03 - tbs,a711-panel # Winstar WF70A8SYJHLNGA 7" WSVGA (1024x600) color TFT LCD LVDS panel - winstar,wf70a8syjhlnga diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index 2f90c887b7b8..cc8d795df732 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -49,6 +49,8 @@ properties: - lg,lh500wx1-sd03 # Lincoln LCD197 5" 1080x1920 LCD panel - lincolntech,lcd197 + # Novatek NT37700F 1080x2160 AMOLED panel + - novatek,nt37700f # One Stop Displays OSD101T2587-53TS 10.1" 1920x1200 panel - osddisplays,osd101t2587-53ts # Panasonic 10" WUXGA TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml index 548f5ac14500..8a2f6feafd37 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml @@ -40,8 +40,12 @@ properties: - auo,g185han01 # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel - auo,g190ean01 + # AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel + - auo,t215hvn01 # BOE AV123Z7M-N17 12.3" (1920x720) LVDS TFT LCD panel - boe,av123z7m-n17 + # InnoLux 15.6" FHD (1920x1080) TFT LCD panel + - innolux,g156hce-l01 # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel - koe,tx26d202vm0bwa # Lincoln Technology Solutions, LCD185-101CT 10.1" TFT 1920x1200 diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 868edb04989a..3e41ed0ef5d5 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -61,8 +61,6 @@ properties: - auo,p238han01 # AU Optronics Corporation 31.5" FHD (1920x1080) TFT LCD panel - auo,p320hvn03 - # AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel - - auo,t215hvn01 # Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel - avic,tm070ddh03 # BOE AV101HDT-a10 10.1" 1280x720 LVDS panel @@ -103,6 +101,8 @@ properties: - dlc,dlc1010gig # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel - edt,et035012dm6 + # Emerging Display Technology Corp. 5.7" 24-bit VGA TFT LCD panel + - edt,et057023udba # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel - edt,et057090dhu - edt,et070080dh6 @@ -144,8 +144,6 @@ properties: - foxlink,fl500wvr00-a0t # Frida FRD350H54004 3.5" QVGA TFT LCD panel - frida,frd350h54004 - # FriendlyELEC HD702E 800x1280 LCD panel - - friendlyarm,hd702e # GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel - giantplus,gpg48273qs5 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel @@ -180,14 +178,14 @@ properties: - innolux,g121xce-l01 # InnoLux 15.0" G150XGE-L05 XGA (1024x768) TFT LCD panel - innolux,g150xge-l05 - # InnoLux 15.6" FHD (1920x1080) TFT LCD panel - - innolux,g156hce-l01 # InnoLux 13.3" FHD (1920x1080) TFT LCD panel - innolux,n133hse-ea1 # InnoLux 15.6" WXGA TFT LCD panel - innolux,n156bge-l21 # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel - innolux,zj070na-01p + # JuTouch Technology Co.. 7" JT070TM041 WSVGA (1024 x 600) LVDS panel + - jutouch,jt070tm041 # JuTouch Technology Co.. 10" JT101TM023 WXGA (1280 x 800) LVDS panel - jutouch,jt101tm023 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel @@ -202,6 +200,8 @@ properties: - lemaker,bl035-rgb-002 # LG 7" (800x480 pixels) TFT LCD panel - lg,lb070wv8 + # LG 6.1" (1440x3120) IPS LCD panel + - lg,sw49410 # Logic Technologies LT161010-2NHC 7" WVGA TFT Cap Touch Module - logictechno,lt161010-2nhc # Logic Technologies LT161010-2NHR 7" WVGA TFT Resistive Touch Module @@ -268,6 +268,8 @@ properties: - powertip,ph128800t006-zhc01 # POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel - powertip,ph800480t013-idf02 + # POWERTIP PH800480T032-ZHC19 7.0" WVGA TFT LCD panel + - powertip,ph800480t032-zhc19 # PrimeView PM070WL4 7.0" 800x480 TFT LCD panel - primeview,pm070wl4 # QiaoDian XianShi Corporation 4"3 TFT LCD panel @@ -308,6 +310,8 @@ properties: - team-source-display,tst043015cmhx # Tianma Micro-electronics P0700WXF1MBAA 7.0" WXGA (1280x800) LVDS TFT LCD panel - tianma,p0700wxf1mbaa + # Tianma Micro-electronics TM050RDH03 5.0" WVGA TFT LCD panel + - tianma,tm050rdh03 # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel - tianma,tm070jdhg30 # Tianma Micro-electronics TM070JDHG34-00 7.0" WXGA (1280x800) LVDS TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml index ccd3623b4955..871e4c2d9824 100644 --- a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml +++ b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml @@ -21,11 +21,11 @@ properties: backlight: true port: true -additionalProperties: false - required: - compatible - power-supply - backlight +additionalProperties: false + ... diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml index 46fe1014ebc4..8fb7c013dfb8 100644 --- a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml @@ -33,13 +33,13 @@ properties: reset-gpios: maxItems: 1 -additionalProperties: false - required: - compatible - power-supply - reg +additionalProperties: false + examples: - | dsi { diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm692e5.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm692e5.yaml index 7ad223f98253..616a5f3ec9fc 100644 --- a/Documentation/devicetree/bindings/display/panel/raydium,rm692e5.yaml +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm692e5.yaml @@ -34,8 +34,6 @@ properties: vddio-supply: description: I/O voltage rail - port: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/renesas,r61307.yaml b/Documentation/devicetree/bindings/display/panel/renesas,r61307.yaml index 90cce221c0d1..3d7761717b74 100644 --- a/Documentation/devicetree/bindings/display/panel/renesas,r61307.yaml +++ b/Documentation/devicetree/bindings/display/panel/renesas,r61307.yaml @@ -33,8 +33,6 @@ properties: iovcc-supply: description: Regulator for 1.8V IO power supply. - backlight: true - renesas,gamma: $ref: /schemas/types.yaml#/definitions/uint32 description: @@ -51,6 +49,7 @@ properties: type: boolean description: digital contrast adjustment + backlight: true reset-gpios: true port: true diff --git a/Documentation/devicetree/bindings/display/panel/renesas,r69328.yaml b/Documentation/devicetree/bindings/display/panel/renesas,r69328.yaml index 1cd219b510ee..740185f778a1 100644 --- a/Documentation/devicetree/bindings/display/panel/renesas,r69328.yaml +++ b/Documentation/devicetree/bindings/display/panel/renesas,r69328.yaml @@ -33,7 +33,6 @@ properties: description: Regulator for 1.8V IO power supply. backlight: true - reset-gpios: true port: true diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml index 4ae152cc55e0..ebfc825b8346 100644 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml @@ -33,7 +33,6 @@ properties: # Xingbangda XBD599 5.99" 720x1440 TFT LCD panel - xingbangda,xbd599 - port: true reg: maxItems: 1 description: DSI virtual channel @@ -44,9 +43,9 @@ properties: iovcc-supply: description: I/O voltage supply - reset-gpios: true - backlight: true + port: true + reset-gpios: true rotation: true required: diff --git a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml index f1723e910252..1bbe0da3997c 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml @@ -43,13 +43,13 @@ properties: no-hpd: true hpd-gpios: true -additionalProperties: false - required: - compatible - enable-gpios - power-supply +additionalProperties: false + examples: - | #include <dt-bindings/clock/qcom,rpmh.h> diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml index bc92b16c95b9..2e64fba472cc 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml @@ -20,10 +20,6 @@ properties: reg: maxItems: 1 - display-timings: true - port: true - reset-gpios: true - vdd3-supply: description: core voltage supply diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml index 74c2a617c2ff..828b7d7ba17f 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml @@ -31,8 +31,6 @@ properties: configuration. maxItems: 1 - reset-gpios: true - vci-supply: description: regulator that supplies the VCI analog voltage usually around 3.0 V @@ -41,8 +39,6 @@ properties: description: regulator that supplies the VCCIO voltage usually around 1.8 V - backlight: true - spi-cpha: true spi-cpol: true @@ -50,8 +46,6 @@ properties: spi-max-frequency: maximum: 1200000 - port: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml index 4cecf502a150..c04d47e59f24 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml @@ -23,8 +23,6 @@ properties: reg: maxItems: 1 - reset-gpios: true - vci-supply: description: regulator that supplies the VCI analog voltage usually around 3.0 V @@ -33,8 +31,6 @@ properties: description: regulator that supplies the VCCIO voltage usually around 1.8 V - backlight: true - spi-cpha: true spi-cpol: true @@ -44,8 +40,6 @@ properties: maximum 300 ns minimum cycle which gives around 3 MHz max frequency maximum: 3000000 - port: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml index d74904164719..0d57f97e8a76 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6d27a1.yaml @@ -30,8 +30,6 @@ properties: configuration. maxItems: 1 - reset-gpios: true - vci-supply: description: regulator that supplies the VCI analog voltage usually around 3.0 V @@ -40,8 +38,6 @@ properties: description: regulator that supplies the VCCIO voltage usually around 1.8 V - backlight: true - spi-cpha: true spi-cpol: true @@ -49,8 +45,6 @@ properties: spi-max-frequency: maximum: 1200000 - port: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml index 939da65114bf..1f753b706911 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6d7aa0.yaml @@ -44,6 +44,8 @@ properties: vmipi-supply: description: VMIPI supply, usually 1.8v. + port: true + required: - compatible - reg @@ -65,6 +67,12 @@ examples: power-supply = <&display_3v3_supply>; reset-gpios = <&gpf0 4 GPIO_ACTIVE_LOW>; backlight = <&backlight>; + + port { + panel_in: endpoint { + remote-endpoint = <&mdss_dsi0_out>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml index 05a78429aaea..00ce5a4e1c6b 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha8.yaml @@ -22,10 +22,6 @@ properties: reg: maxItems: 1 - reset-gpios: true - - port: true - vdd3-supply: description: VDD regulator diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml index c47e2a1a30e5..b65f0688bdf0 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml @@ -21,8 +21,6 @@ properties: reg: maxItems: 1 - reset-gpios: true - port: true default-brightness: true max-brightness: true diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa5x01-ams561ra01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa5x01-ams561ra01.yaml index eccfc66d7fe2..b271de575e15 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa5x01-ams561ra01.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa5x01-ams561ra01.yaml @@ -8,13 +8,16 @@ title: Samsung AMS561RA01 panel with S6E8AA5X01 controller maintainers: - Kaustabh Chakraborty <kauschluss@disroot.org> + - Yedaya Katsman <yedaya.ka@gmail.com> allOf: - $ref: panel-common.yaml# properties: compatible: - const: samsung,s6e8aa5x01-ams561ra01 + enum: + - samsung,s6e8aa5x01-ams561ra01 + - samsung,s6e8fc0-m1906f9 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml index e32d9188a3e0..1beb4ba92248 100644 --- a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml +++ b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml @@ -41,8 +41,6 @@ properties: panel-timing: true port: true -additionalProperties: false - required: - compatible - port @@ -51,6 +49,8 @@ required: - height-mm - panel-timing +additionalProperties: false + examples: - |+ panel { diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml index 1e434240ea3f..044b84d8638d 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml @@ -49,12 +49,6 @@ properties: If not set, the controller is in 3-line SPI mode. Disallowed for DSI. - port: true - reset-gpios: true - rotation: true - - backlight: true - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml index c35d4f2ab9a4..e4fa05163d2d 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml @@ -24,12 +24,6 @@ properties: reg: maxItems: 1 - reset-gpios: true - power-supply: true - backlight: true - port: true - rotation: true - spi-cpha: true spi-cpol: true diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml index 5a8260224b74..12e5ad504001 100644 --- a/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml +++ b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml @@ -20,10 +20,6 @@ properties: reg: maxItems: 1 - label: true - reset-gpios: true - port: true - required: - compatible - port diff --git a/Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml b/Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml index a58a31349757..85c5dee65383 100644 --- a/Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml +++ b/Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml @@ -31,9 +31,7 @@ properties: description: Negative 5V supply reset-gpios: true - enable-gpios: true - port: true required: diff --git a/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml index d817f998cddc..7fd9364fa385 100644 --- a/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml +++ b/Documentation/devicetree/bindings/display/panel/startek,kd070fhfid015.yaml @@ -16,8 +16,6 @@ properties: compatible: const: startek,kd070fhfid015 - enable-gpios: true - iovcc-supply: description: Reference to the regulator powering the panel IO pins. @@ -25,13 +23,10 @@ properties: maxItems: 1 description: DSI virtual channel - reset-gpios: true - + enable-gpios: true port: true - power-supply: true - -additionalProperties: false + reset-gpios: true required: - compatible @@ -42,6 +37,8 @@ required: - port - power-supply +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml index 7edd29df4bbb..855911588d73 100644 --- a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml +++ b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml @@ -25,11 +25,6 @@ properties: reg: maxItems: 1 - label: true - reset-gpios: true - backlight: true - port: true - spi-cpha: true spi-cpol: true diff --git a/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml index 187840bb76c7..49ef45c03593 100644 --- a/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml +++ b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml @@ -25,8 +25,6 @@ properties: port: true reset-gpios: true -additionalProperties: false - required: - compatible - reg @@ -35,6 +33,8 @@ required: - reset-gpios - port +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml index f0a82f0ff790..f61a528c0413 100644 --- a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml +++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml @@ -36,8 +36,6 @@ properties: port: true reset-gpios: true -additionalProperties: false - required: - compatible - reg @@ -46,6 +44,8 @@ required: - reset-gpios - port +additionalProperties: false + examples: - | dsi { diff --git a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml index d5a8295106c1..c99f4146f1bb 100644 --- a/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml +++ b/Documentation/devicetree/bindings/display/panel/visionox,vtdr6130.yaml @@ -26,8 +26,6 @@ properties: port: true reset-gpios: true -additionalProperties: false - required: - compatible - reg @@ -37,6 +35,8 @@ required: - reset-gpios - port +additionalProperties: false + examples: - | #include <dt-bindings/gpio/gpio.h> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml index 6345f0132d43..2b0d9e23e943 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml @@ -27,12 +27,10 @@ description: | * Pixel clock up to 594MHz * I2S, SPDIF audio interface -allOf: - - $ref: /schemas/sound/dai-common.yaml# - properties: compatible: enum: + - rockchip,rk3576-dp - rockchip,rk3588-dp reg: @@ -42,6 +40,7 @@ properties: maxItems: 1 clocks: + minItems: 3 items: - description: Peripheral/APB bus clock - description: DisplayPort AUX clock @@ -50,6 +49,7 @@ properties: - description: SPDIF interfce clock clock-names: + minItems: 3 items: - const: apb - const: aux @@ -95,6 +95,27 @@ required: - ports - resets +allOf: + - $ref: /schemas/sound/dai-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - rockchip,rk3588-dp + then: + properties: + clocks: + minItems: 5 + clock-names: + minItems: 5 + else: + properties: + clocks: + maxItems: 3 + clock-names: + maxItems: 3 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml index f77197e4869f..b4bf2662780b 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml @@ -82,6 +82,10 @@ properties: description: phandle of a display panel $ref: /schemas/types.yaml#/definitions/phandle + port: + description: HDMI output port for connection to HDMI connector or bridge + $ref: /schemas/graph.yaml#/properties/port + "#sound-dai-cells": const: 0 @@ -97,8 +101,13 @@ required: - reset-names - pll-supply - vdd-supply - - nvidia,ddc-i2c-bus - - nvidia,hpd-gpio + +anyOf: + - required: + - nvidia,ddc-i2c-bus + - nvidia,hpd-gpio + - required: + - port examples: - | diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index 38fcee91211e..49a007cbcd3a 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -36,34 +36,50 @@ properties: reg: description: Addresses to each DSS memory region described in the SoC's TRM. - items: - - description: common DSS register area - - description: VIDL1 light video plane - - description: VID video plane - - description: OVR1 overlay manager for vp1 - - description: OVR2 overlay manager for vp2 - - description: VP1 video port 1 - - description: VP2 video port 2 - - description: common1 DSS register area + oneOf: + - items: + - description: common DSS register area + - description: VIDL1 light video plane + - description: VID video plane + - description: OVR1 overlay manager for vp1 + - description: OVR2 overlay manager for vp2 + - description: VP1 video port 1 + - description: VP2 video port 2 + - description: common1 DSS register area + - items: + - description: common DSS register area + - description: VIDL1 light video plane + - description: OVR1 overlay manager for vp1 + - description: VP1 video port 1 + - description: common1 DSS register area reg-names: - items: - - const: common - - const: vidl1 - - const: vid - - const: ovr1 - - const: ovr2 - - const: vp1 - - const: vp2 - - const: common1 + oneOf: + - items: + - const: common + - const: vidl1 + - const: vid + - const: ovr1 + - const: ovr2 + - const: vp1 + - const: vp2 + - const: common1 + - items: + - const: common + - const: vidl1 + - const: ovr1 + - const: vp1 + - const: common1 clocks: + minItems: 2 items: - description: fck DSS functional clock - description: vp1 Video Port 1 pixel clock - description: vp2 Video Port 2 pixel clock clock-names: + minItems: 2 items: - const: fck - const: vp1 @@ -179,6 +195,24 @@ allOf: ports: properties: port@1: false + reg: + maxItems: 5 + reg-names: + maxItems: 5 + clocks: + maxItems: 2 + clock-names: + maxItems: 2 + else: + properties: + reg: + minItems: 8 + reg-names: + minItems: 8 + clocks: + minItems: 3 + clock-names: + minItems: 3 - if: properties: diff --git a/Documentation/devicetree/bindings/display/tilcdc/panel.txt b/Documentation/devicetree/bindings/display/tilcdc/panel.txt index 808216310ea2..b973174d704e 100644 --- a/Documentation/devicetree/bindings/display/tilcdc/panel.txt +++ b/Documentation/devicetree/bindings/display/tilcdc/panel.txt @@ -1,4 +1,5 @@ Device-Tree bindings for tilcdc DRM generic panel output driver +This binding is deprecated and should not be used. Required properties: - compatible: value should be "ti,tilcdc,panel". diff --git a/Documentation/devicetree/bindings/display/tilcdc/ti,am33xx-tilcdc.yaml b/Documentation/devicetree/bindings/display/tilcdc/ti,am33xx-tilcdc.yaml new file mode 100644 index 000000000000..eb0ebb678fa8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tilcdc/ti,am33xx-tilcdc.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2025 Bootlin +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/tilcdc/ti,am33xx-tilcdc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI LCD Controller, found on AM335x, DA850, AM18x and OMAP-L138 + +maintainers: + - Kory Maincent <kory.maincent@bootlin.com> + +properties: + compatible: + enum: + - ti,am33xx-tilcdc + - ti,da850-tilcdc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + description: + Name of the hwmod associated to the LCDC + + max-bandwidth: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The maximum pixels per second that the memory interface / lcd + controller combination can sustain + # maximum: 2048*2048*60 + maximum: 251658240 + + max-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The maximum horizontal pixel width supported by the lcd controller. + maximum: 2048 + + max-pixelclock: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + The maximum pixel clock that can be supported by the lcd controller + in KHz. + + blue-and-red-wiring: + enum: [straight, crossed] + description: + This property deals with the LCDC revision 2 (found on AM335x) + color errata [1]. + - "straight" indicates normal wiring that supports RGB565, + BGR888, and XBGR8888 color formats. + - "crossed" indicates wiring that has blue and red wires + crossed. This setup supports BGR565, RGB888 and XRGB8888 + formats. + - If the property is not present or its value is not recognized + the legacy mode is assumed. This configuration supports RGB565, + RGB888 and XRGB8888 formats. However, depending on wiring, the red + and blue colors are swapped in either 16 or 24-bit color modes. + + [1] There is an errata about AM335x color wiring. For 16-bit color + mode the wires work as they should (LCD_DATA[0:4] is for Blue[3:7]), + but for 24 bit color modes the wiring of blue and red components is + crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is + for Blue[3-7]. For more details see section 3.1.1 in AM335x + Silicon Errata + https://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360 + +required: + - compatible + - interrupts + - reg + - port + +additionalProperties: false + +examples: + - | + display-controller@4830e000 { + compatible = "ti,am33xx-tilcdc"; + reg = <0x4830e000 0x1000>; + interrupt-parent = <&intc>; + interrupts = <36>; + ti,hwmods = "lcdc"; + + blue-and-red-wiring = "crossed"; + + port { + endpoint { + remote-endpoint = <&hdmi_0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt deleted file mode 100644 index 3b3d0bbfcfff..000000000000 --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt +++ /dev/null @@ -1,82 +0,0 @@ -Device-Tree bindings for tilcdc DRM driver - -Required properties: - - compatible: value should be one of the following: - - "ti,am33xx-tilcdc" for AM335x based boards - - "ti,da850-tilcdc" for DA850/AM18x/OMAP-L138 based boards - - interrupts: the interrupt number - - reg: base address and size of the LCDC device - -Recommended properties: - - ti,hwmods: Name of the hwmod associated to the LCDC - -Optional properties: - - max-bandwidth: The maximum pixels per second that the memory - interface / lcd controller combination can sustain - - max-width: The maximum horizontal pixel width supported by - the lcd controller. - - max-pixelclock: The maximum pixel clock that can be supported - by the lcd controller in KHz. - - blue-and-red-wiring: Recognized values "straight" or "crossed". - This property deals with the LCDC revision 2 (found on AM335x) - color errata [1]. - - "straight" indicates normal wiring that supports RGB565, - BGR888, and XBGR8888 color formats. - - "crossed" indicates wiring that has blue and red wires - crossed. This setup supports BGR565, RGB888 and XRGB8888 - formats. - - If the property is not present or its value is not recognized - the legacy mode is assumed. This configuration supports RGB565, - RGB888 and XRGB8888 formats. However, depending on wiring, the red - and blue colors are swapped in either 16 or 24-bit color modes. - -Optional nodes: - - - port/ports: to describe a connection to an external encoder. The - binding follows Documentation/devicetree/bindings/graph.txt and - supports a single port with a single endpoint. - - - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and - Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml for connecting - tfp410 DVI encoder or lcd panel to lcdc - -[1] There is an errata about AM335x color wiring. For 16-bit color mode - the wires work as they should (LCD_DATA[0:4] is for Blue[3:7]), - but for 24 bit color modes the wiring of blue and red components is - crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is - for Blue[3-7]. For more details see section 3.1.1 in AM335x - Silicon Errata: - https://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360 - -Example: - - fb: fb@4830e000 { - compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc"; - reg = <0x4830e000 0x1000>; - interrupt-parent = <&intc>; - interrupts = <36>; - ti,hwmods = "lcdc"; - - blue-and-red-wiring = "crossed"; - - port { - lcdc_0: endpoint { - remote-endpoint = <&hdmi_0>; - }; - }; - }; - - tda19988: tda19988 { - compatible = "nxp,tda998x"; - reg = <0x70>; - - pinctrl-names = "default", "off"; - pinctrl-0 = <&nxp_hdmi_bonelt_pins>; - pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>; - - port { - hdmi_0: endpoint { - remote-endpoint = <&lcdc_0>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml new file mode 100644 index 000000000000..9dc35ab973f2 --- /dev/null +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/verisilicon,dc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Verisilicon DC-series display controllers + +maintainers: + - Icenowy Zheng <uwu@icenowy.me> + +properties: + $nodename: + pattern: "^display@[0-9a-f]+$" + + compatible: + items: + - enum: + - thead,th1520-dc8200 + - const: verisilicon,dc # DC IPs have discoverable ID/revision registers + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: DC Core clock + - description: DMA AXI bus clock + - description: Configuration AHB bus clock + - description: Pixel clock of output 0 + - description: Pixel clock of output 1 + + clock-names: + items: + - const: core + - const: axi + - const: ahb + - const: pix0 + - const: pix1 + + resets: + items: + - description: DC Core reset + - description: DMA AXI bus reset + - description: Configuration AHB bus reset + + reset-names: + items: + - const: core + - const: axi + - const: ahb + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: The first output channel , endpoint 0 should be + used for DPI format output and endpoint 1 should be used + for DP format output. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: The second output channel if the DC variant + supports. Follow the same endpoint addressing rule with + the first port. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/thead,th1520-clk-ap.h> + #include <dt-bindings/reset/thead,th1520-reset.h> + soc { + #address-cells = <2>; + #size-cells = <2>; + + display@ffef600000 { + compatible = "thead,th1520-dc8200", "verisilicon,dc"; + reg = <0xff 0xef600000 0x0 0x100000>; + interrupts = <93 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk_vo CLK_DPU_CCLK>, + <&clk_vo CLK_DPU_ACLK>, + <&clk_vo CLK_DPU_HCLK>, + <&clk_vo CLK_DPU_PIXELCLK0>, + <&clk_vo CLK_DPU_PIXELCLK1>; + clock-names = "core", "axi", "ahb", "pix0", "pix1"; + resets = <&rst TH1520_RESET_ID_DPU_CORE>, + <&rst TH1520_RESET_ID_DPU_AXI>, + <&rst TH1520_RESET_ID_DPU_AHB>; + reset-names = "core", "axi", "ahb"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + dpu_out_dp1: endpoint@1 { + reg = <1>; + remote-endpoint = <&hdmi_in>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/dma/loongson,ls2k0300-dma.yaml b/Documentation/devicetree/bindings/dma/loongson,ls2k0300-dma.yaml new file mode 100644 index 000000000000..8095214ccaf7 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/loongson,ls2k0300-dma.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/loongson,ls2k0300-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson-2 Multi-Channel DMA controller + +description: + The Loongson-2 Multi-Channel DMA controller is used for transferring data + between system memory and the peripherals on the APB bus. + +maintainers: + - Binbin Zhou <zhoubinbin@loongson.cn> + +allOf: + - $ref: dma-controller.yaml# + +properties: + compatible: + enum: + - loongson,ls2k0300-dma + - loongson,ls2k3000-dma + + reg: + maxItems: 1 + + interrupts: + description: + Should contain all of the per-channel DMA interrupts in ascending order + with respect to the DMA channel index. + minItems: 4 + maxItems: 8 + + clocks: + maxItems: 1 + + '#dma-cells': + const: 2 + description: | + DMA request from clients consists of 2 cells: + 1. Channel index + 2. Transfer request factor number, If no transfer factor, use 0. + The number is SoC-specific, and this should be specified with + relation to the device to use the DMA controller. + + dma-channels: + enum: [4, 8] + +required: + - compatible + - reg + - interrupts + - clocks + - '#dma-cells' + - dma-channels + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/loongson,ls2k-clk.h> + + dma-controller@1612c000 { + compatible = "loongson,ls2k0300-dma"; + reg = <0x1612c000 0xff>; + interrupt-parent = <&liointc0>; + interrupts = <23 IRQ_TYPE_LEVEL_HIGH>, + <24 IRQ_TYPE_LEVEL_HIGH>, + <25 IRQ_TYPE_LEVEL_HIGH>, + <26 IRQ_TYPE_LEVEL_HIGH>, + <27 IRQ_TYPE_LEVEL_HIGH>, + <28 IRQ_TYPE_LEVEL_HIGH>, + <29 IRQ_TYPE_LEVEL_HIGH>, + <30 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk LS2K0300_CLK_APB_GATE>; + #dma-cells = <2>; + dma-channels = <8>; + }; +... diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml index d137b9cbaee9..0155a15e200b 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml @@ -19,6 +19,7 @@ properties: - renesas,r9a07g044-dmac # RZ/G2{L,LC} - renesas,r9a07g054-dmac # RZ/V2L - renesas,r9a08g045-dmac # RZ/G3S + - renesas,r9a08g046-dmac # RZ/G3L - const: renesas,rz-dmac - items: @@ -29,6 +30,13 @@ properties: - const: renesas,r9a09g057-dmac # RZ/V2H(P) + - const: renesas,r9a09g077-dmac # RZ/T2H + + - items: + - enum: + - renesas,r9a09g087-dmac # RZ/N2H + - const: renesas,r9a09g077-dmac + reg: items: - description: Control and channel register block @@ -36,27 +44,12 @@ properties: minItems: 1 interrupts: + minItems: 16 maxItems: 17 interrupt-names: - items: - - const: error - - const: ch0 - - const: ch1 - - const: ch2 - - const: ch3 - - const: ch4 - - const: ch5 - - const: ch6 - - const: ch7 - - const: ch8 - - const: ch9 - - const: ch10 - - const: ch11 - - const: ch12 - - const: ch13 - - const: ch14 - - const: ch15 + minItems: 16 + maxItems: 17 clocks: items: @@ -127,10 +120,40 @@ allOf: compatible: contains: enum: + - renesas,rz-dmac + - renesas,r9a09g057-dmac + then: + properties: + interrupt-names: + items: + - const: error + - const: ch0 + - const: ch1 + - const: ch2 + - const: ch3 + - const: ch4 + - const: ch5 + - const: ch6 + - const: ch7 + - const: ch8 + - const: ch9 + - const: ch10 + - const: ch11 + - const: ch12 + - const: ch13 + - const: ch14 + - const: ch15 + + - if: + properties: + compatible: + contains: + enum: - renesas,r9a07g043-dmac - renesas,r9a07g044-dmac - renesas,r9a07g054-dmac - renesas,r9a08g045-dmac + - renesas,r9a08g046-dmac then: properties: reg: @@ -189,6 +212,49 @@ allOf: - renesas,icu - resets + - if: + properties: + compatible: + contains: + const: renesas,r9a09g077-dmac + then: + properties: + reg: + maxItems: 1 + clocks: + maxItems: 1 + + clock-names: false + resets: false + reset-names: false + + interrupts: + maxItems: 16 + + interrupt-names: + items: + - const: ch0 + - const: ch1 + - const: ch2 + - const: ch3 + - const: ch4 + - const: ch5 + - const: ch6 + - const: ch7 + - const: ch8 + - const: ch9 + - const: ch10 + - const: ch11 + - const: ch12 + - const: ch13 + - const: ch14 + - const: ch15 + + required: + - clocks + - power-domains + - renesas,icu + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml index 216cda21c538..804514732dbe 100644 --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml @@ -21,6 +21,7 @@ properties: - enum: - snps,axi-dma-1.01a - intel,kmb-axi-dma + - sophgo,cv1800b-axi-dma - starfive,jh7110-axi-dma - starfive,jh8100-axi-dma - items: @@ -68,6 +69,8 @@ properties: dma-noncoherent: true + dma-coherent: true + resets: minItems: 1 maxItems: 2 diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt deleted file mode 100644 index b567107270cb..000000000000 --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt +++ /dev/null @@ -1,111 +0,0 @@ -Xilinx AXI VDMA engine, it does transfers between memory and video devices. -It can be configured to have one channel or two channels. If configured -as two channels, one is to transmit to the video device and another is -to receive from the video device. - -Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream -target devices. It can be configured to have one channel or two channels. -If configured as two channels, one is to transmit to the device and another -is to receive from the device. - -Xilinx AXI CDMA engine, it does transfers between memory-mapped source -address and a memory-mapped destination address. - -Xilinx AXI MCDMA engine, it does transfer between memory and AXI4 stream -target devices. It can be configured to have up to 16 independent transmit -and receive channels. - -Required properties: -- compatible: Should be one of- - "xlnx,axi-vdma-1.00.a" - "xlnx,axi-dma-1.00.a" - "xlnx,axi-cdma-1.00.a" - "xlnx,axi-mcdma-1.00.a" -- #dma-cells: Should be <1>, see "dmas" property below -- reg: Should contain VDMA registers location and length. -- xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits). -- dma-ranges: Should be as the following <dma_addr cpu_addr max_len>. -- dma-channel child node: Should have at least one channel and can have up to - two channels per device. This node specifies the properties of each - DMA channel (see child node properties below). -- clocks: Input clock specifier. Refer to common clock bindings. -- clock-names: List of input clocks - For VDMA: - Required elements: "s_axi_lite_aclk" - Optional elements: "m_axi_mm2s_aclk" "m_axi_s2mm_aclk", - "m_axis_mm2s_aclk", "s_axis_s2mm_aclk" - For CDMA: - Required elements: "s_axi_lite_aclk", "m_axi_aclk" - For AXIDMA and MCDMA: - Required elements: "s_axi_lite_aclk" - Optional elements: "m_axi_mm2s_aclk", "m_axi_s2mm_aclk", - "m_axi_sg_aclk" - -Required properties for VDMA: -- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w. - -Optional properties for AXI DMA and MCDMA: -- xlnx,sg-length-width: Should be set to the width in bits of the length - register as configured in h/w. Takes values {8...26}. If the property - is missing or invalid then the default value 23 is used. This is the - maximum value that is supported by all IP versions. - -Optional properties for AXI DMA: -- xlnx,axistream-connected: Tells whether DMA is connected to AXI stream IP. -- xlnx,irq-delay: Tells the interrupt delay timeout value. Valid range is from - 0-255. Setting this value to zero disables the delay timer interrupt. - 1 timeout interval = 125 * clock period of SG clock. -Optional properties for VDMA: -- xlnx,flush-fsync: Tells which channel to Flush on Frame sync. - It takes following values: - {1}, flush both channels - {2}, flush mm2s channel - {3}, flush s2mm channel - -Required child node properties: -- compatible: - For VDMA: It should be either "xlnx,axi-vdma-mm2s-channel" or - "xlnx,axi-vdma-s2mm-channel". - For CDMA: It should be "xlnx,axi-cdma-channel". - For AXIDMA and MCDMA: It should be either "xlnx,axi-dma-mm2s-channel" - or "xlnx,axi-dma-s2mm-channel". -- interrupts: Should contain per channel VDMA interrupts. -- xlnx,datawidth: Should contain the stream data width, take values - {32,64...1024}. - -Optional child node properties: -- xlnx,include-dre: Tells hardware is configured for Data - Realignment Engine. -Optional child node properties for VDMA: -- xlnx,genlock-mode: Tells Genlock synchronization is - enabled/disabled in hardware. -- xlnx,enable-vert-flip: Tells vertical flip is - enabled/disabled in hardware(S2MM path). -Optional child node properties for MCDMA: -- dma-channels: Number of dma channels in child node. - -Example: -++++++++ - -axi_vdma_0: axivdma@40030000 { - compatible = "xlnx,axi-vdma-1.00.a"; - #dma_cells = <1>; - reg = < 0x40030000 0x10000 >; - dma-ranges = <0x00000000 0x00000000 0x40000000>; - xlnx,num-fstores = <0x8>; - xlnx,flush-fsync = <0x1>; - xlnx,addrwidth = <0x20>; - clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>; - clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk", - "m_axis_mm2s_aclk", "s_axis_s2mm_aclk"; - dma-channel@40030000 { - compatible = "xlnx,axi-vdma-mm2s-channel"; - interrupts = < 0 54 4 >; - xlnx,datawidth = <0x40>; - } ; - dma-channel@40030030 { - compatible = "xlnx,axi-vdma-s2mm-channel"; - interrupts = < 0 53 4 >; - xlnx,datawidth = <0x40>; - } ; -} ; diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml new file mode 100644 index 000000000000..340ae9e91cb0 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml @@ -0,0 +1,299 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/xilinx/xlnx,axi-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx AXI VDMA, DMA, CDMA and MCDMA IP + +maintainers: + - Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> + - Abin Joseph <abin.joseph@amd.com> + +description: > + Xilinx AXI VDMA engine, it does transfers between memory and video devices. + It can be configured to have one channel or two channels. If configured + as two channels, one is to transmit to the video device and another is + to receive from the video device. + + Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream + target devices. It can be configured to have one channel or two channels. + If configured as two channels, one is to transmit to the device and another + is to receive from the device. + + Xilinx AXI CDMA engine, it does transfers between memory-mapped source + address and a memory-mapped destination address. + + Xilinx AXI MCDMA engine, it does transfer between memory and AXI4 stream + target devices. It can be configured to have up to 16 independent transmit + and receive channels. + +properties: + compatible: + enum: + - xlnx,axi-cdma-1.00.a + - xlnx,axi-dma-1.00.a + - xlnx,axi-mcdma-1.00.a + - xlnx,axi-vdma-1.00.a + + reg: + maxItems: 1 + + "#dma-cells": + const: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + interrupts: + items: + - description: Interrupt for single channel (MM2S or S2MM) + - description: Interrupt for dual channel configuration + minItems: 1 + description: + Interrupt lines for the DMA controller. Only used when + xlnx,axistream-connected is present (DMA connected to AXI Stream + IP). When child dma-channel nodes are present, interrupts are + specified in the child nodes instead. + + clocks: + minItems: 1 + maxItems: 5 + + clock-names: + minItems: 1 + maxItems: 5 + + dma-ranges: true + + xlnx,addrwidth: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [32, 64] + description: The DMA addressing size in bits. + + xlnx,num-fstores: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 32 + description: Should be the number of framebuffers as configured in h/w. + + xlnx,flush-fsync: + type: boolean + description: Tells which channel to Flush on Frame sync. + + xlnx,sg-length-width: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 8 + maximum: 26 + default: 23 + description: + Width in bits of the length register as configured in hardware. + + xlnx,irq-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: + Tells the interrupt delay timeout value. Valid range is from 0-255. + Setting this value to zero disables the delay timer interrupt. + 1 timeout interval = 125 * clock period of SG clock. + + xlnx,axistream-connected: + type: boolean + description: Tells whether DMA is connected to AXI stream IP. + +patternProperties: + "^dma-channel(-mm2s|-s2mm)?$": + type: object + description: + Should have at least one channel and can have up to two channels per + device. This node specifies the properties of each DMA channel. + + properties: + compatible: + enum: + - xlnx,axi-vdma-mm2s-channel + - xlnx,axi-vdma-s2mm-channel + - xlnx,axi-cdma-channel + - xlnx,axi-dma-mm2s-channel + - xlnx,axi-dma-s2mm-channel + + interrupts: + maxItems: 1 + + xlnx,datawidth: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [32, 64, 128, 256, 512, 1024] + description: Should contain the stream data width, take values {32,64...1024}. + + xlnx,include-dre: + type: boolean + description: Tells hardware is configured for Data Realignment Engine. + + xlnx,genlock-mode: + type: boolean + description: Tells Genlock synchronization is enabled/disabled in hardware. + + xlnx,enable-vert-flip: + type: boolean + description: + Tells vertical flip is enabled/disabled in hardware(S2MM path). + + dma-channels: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of dma channels in child node. + + required: + - compatible + - interrupts + - xlnx,datawidth + + additionalProperties: false + +allOf: + - $ref: ../dma-controller.yaml# + + - if: + properties: + compatible: + contains: + const: xlnx,axi-vdma-1.00.a + then: + properties: + clock-names: + items: + - const: s_axi_lite_aclk + - const: m_axi_mm2s_aclk + - const: m_axi_s2mm_aclk + - const: m_axis_mm2s_aclk + - const: s_axis_s2mm_aclk + minItems: 1 + interrupts: false + patternProperties: + "^dma-channel(-mm2s|-s2mm)?$": + properties: + compatible: + enum: + - xlnx,axi-vdma-mm2s-channel + - xlnx,axi-vdma-s2mm-channel + required: + - xlnx,num-fstores + + - if: + properties: + compatible: + contains: + const: xlnx,axi-cdma-1.00.a + then: + properties: + clock-names: + items: + - const: s_axi_lite_aclk + - const: m_axi_aclk + interrupts: false + patternProperties: + "^dma-channel(-mm2s|-s2mm)?$": + properties: + compatible: + enum: + - xlnx,axi-cdma-channel + + - if: + properties: + compatible: + contains: + enum: + - xlnx,axi-dma-1.00.a + - xlnx,axi-mcdma-1.00.a + then: + properties: + clock-names: + items: + - const: s_axi_lite_aclk + - const: m_axi_mm2s_aclk + - const: m_axi_s2mm_aclk + - const: m_axi_sg_aclk + minItems: 1 + patternProperties: + "^dma-channel(-mm2s|-s2mm)?(@[0-9a-f]+)?$": + properties: + compatible: + enum: + - xlnx,axi-dma-mm2s-channel + - xlnx,axi-dma-s2mm-channel + +required: + - "#dma-cells" + - reg + - xlnx,addrwidth + - dma-ranges + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + dma-controller@40030000 { + compatible = "xlnx,axi-vdma-1.00.a"; + reg = <0x40030000 0x10000>; + #dma-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + dma-ranges = <0x0 0x0 0x40000000>; + clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>; + clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", + "m_axi_s2mm_aclk", "m_axis_mm2s_aclk", + "s_axis_s2mm_aclk"; + xlnx,num-fstores = <8>; + xlnx,flush-fsync; + xlnx,addrwidth = <32>; + + dma-channel-mm2s { + compatible = "xlnx,axi-vdma-mm2s-channel"; + interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>; + xlnx,datawidth = <64>; + }; + + dma-channel-s2mm { + compatible = "xlnx,axi-vdma-s2mm-channel"; + interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; + xlnx,datawidth = <64>; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + dma-controller@a4030000 { + compatible = "xlnx,axi-dma-1.00.a"; + reg = <0xa4030000 0x10000>; + #dma-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + dma-ranges = <0x0 0x0 0x40000000>; + clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>; + clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", + "m_axi_s2mm_aclk", "m_axi_sg_aclk"; + xlnx,addrwidth = <32>; + xlnx,sg-length-width = <14>; + + dma-channel-mm2s { + compatible = "xlnx,axi-dma-mm2s-channel"; + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>; + xlnx,datawidth = <64>; + xlnx,include-dre; + }; + + dma-channel-s2mm { + compatible = "xlnx,axi-dma-s2mm-channel"; + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>; + xlnx,datawidth = <64>; + xlnx,include-dre; + }; + }; diff --git a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml index 51db93b77306..1287a472f08f 100644 --- a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml +++ b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml @@ -36,6 +36,19 @@ properties: description: String exposed as the pin board label $ref: /schemas/types.yaml#/definitions/string + ref-sync-sources: + description: | + List of phandles to input pins that can serve as the sync source + in a Reference-Sync pair with this pin acting as the clock source. + A Ref-Sync pair consists of a clock reference and a low-frequency + sync signal. The DPLL locks to the clock reference but + phase-aligns to the sync reference. + Only valid for input pins. Each referenced pin must be a + different input pin on the same device. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 + supported-frequencies-hz: description: List of supported frequencies for this pin, expressed in Hz. diff --git a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml index 17747f754b84..fa5a8f8e390c 100644 --- a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml +++ b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml @@ -52,11 +52,19 @@ examples: #address-cells = <1>; #size-cells = <0>; - pin@0 { /* REF0P */ + sync0: pin@0 { /* REF0P - 1 PPS sync source */ reg = <0>; connection-type = "ext"; - label = "Input 0"; - supported-frequencies-hz = /bits/ 64 <1 1000>; + label = "SMA1"; + supported-frequencies-hz = /bits/ 64 <1>; + }; + + pin@1 { /* REF0N - clock source, can pair with sync0 */ + reg = <1>; + connection-type = "ext"; + label = "SMA2"; + supported-frequencies-hz = /bits/ 64 <10000 10000000>; + ref-sync-sources = <&sync0>; }; }; @@ -90,11 +98,19 @@ examples: #address-cells = <1>; #size-cells = <0>; - pin@0 { /* REF0P */ + sync1: pin@0 { /* REF0P - 1 PPS sync source */ reg = <0>; - connection-type = "ext"; - label = "Input 0"; - supported-frequencies-hz = /bits/ 64 <1 1000>; + connection-type = "gnss"; + label = "GNSS_1PPS_IN"; + supported-frequencies-hz = /bits/ 64 <1>; + }; + + pin@1 { /* REF0N - clock source */ + reg = <1>; + connection-type = "gnss"; + label = "GNSS_10M_IN"; + supported-frequencies-hz = /bits/ 64 <10000000>; + ref-sync-sources = <&sync1>; }; }; diff --git a/Documentation/devicetree/bindings/embedded-controller/kontron,sl28cpld.yaml b/Documentation/devicetree/bindings/embedded-controller/kontron,sl28cpld.yaml index a77e67f6cb82..0b752f3baaa9 100644 --- a/Documentation/devicetree/bindings/embedded-controller/kontron,sl28cpld.yaml +++ b/Documentation/devicetree/bindings/embedded-controller/kontron,sl28cpld.yaml @@ -16,12 +16,7 @@ description: | properties: compatible: - oneOf: - - items: - - enum: - - kontron,sa67mcu - - const: kontron,sl28cpld - - const: kontron,sl28cpld + const: kontron,sl28cpld reg: description: diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index be817fd9cc34..d06cca9273c4 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -146,6 +146,13 @@ properties: this platform. If set, the value should be non-zero. minimum: 1 + arm,no-completion-irq: + type: boolean + description: + This optional property is intended for hardware that does not generate + completion interrupts and can be used to unconditionally enable forced + polling mode of operation. + arm,smc-id: $ref: /schemas/types.yaml#/definitions/uint32 description: @@ -379,6 +386,9 @@ then: - shmem else: + properties: + arm,no-completion-irq: false + if: properties: compatible: diff --git a/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml b/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml index 4a1e3e3c0505..e68f9c3ca5e2 100644 --- a/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml +++ b/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml @@ -37,6 +37,7 @@ properties: maxItems: 1 pmic: + deprecated: true description: Child node describing the main PMIC. type: object additionalProperties: true @@ -45,6 +46,24 @@ properties: compatible: const: samsung,s2mpg10-pmic + pmic-1: + description: Child node describing the main PMIC. + type: object + additionalProperties: true + + properties: + compatible: + const: samsung,s2mpg10-pmic + + pmic-2: + description: Child node describing the sub PMIC. + type: object + additionalProperties: true + + properties: + compatible: + const: samsung,s2mpg11-pmic + shmem: description: List of phandle pointing to the shared memory (SHM) area. The memory @@ -62,7 +81,9 @@ additionalProperties: false examples: - | + #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/regulator/samsung,s2mpg10-regulator.h> power-management { compatible = "google,gs101-acpm-ipc"; @@ -70,10 +91,12 @@ examples: mboxes = <&ap2apm_mailbox>; shmem = <&apm_sram>; - pmic { + pmic-1 { compatible = "samsung,s2mpg10-pmic"; interrupts-extended = <&gpa0 6 IRQ_TYPE_LEVEL_LOW>; + vinl3m-supply = <&buck8m>; + regulators { ldo1m { regulator-name = "vdd_ldo1"; @@ -82,7 +105,13 @@ examples: regulator-always-on; }; - // ... + ldo20m { + regulator-name = "vdd_dmics"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + samsung,ext-control = <S2MPG10_EXTCTRL_LDO20M_EN2>; + }; buck8m { regulator-name = "vdd_mif"; @@ -93,4 +122,21 @@ examples: }; }; }; + + pmic-2 { + compatible = "samsung,s2mpg11-pmic"; + interrupts-extended = <&gpa0 7 IRQ_TYPE_LEVEL_LOW>; + + vinl1s-supply = <&buck8m>; + vinl2s-supply = <&buck6s>; + + regulators { + buckd { + regulator-name = "vcc_ufs"; + regulator-ramp-delay = <6250>; + enable-gpios = <&gpp0 1 GPIO_ACTIVE_HIGH>; + samsung,ext-control = <S2MPG11_EXTCTRL_UFS_EN>; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml index d66459f1d84e..7918d31f58b4 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml @@ -23,15 +23,18 @@ properties: - enum: - qcom,scm-apq8064 - qcom,scm-apq8084 + - qcom,scm-eliza - qcom,scm-glymur - qcom,scm-ipq4019 - qcom,scm-ipq5018 + - qcom,scm-ipq5210 - qcom,scm-ipq5332 - qcom,scm-ipq5424 - qcom,scm-ipq6018 - qcom,scm-ipq806x - qcom,scm-ipq8074 - qcom,scm-ipq9574 + - qcom,scm-ipq9650 - qcom,scm-kaanapali - qcom,scm-mdm9607 - qcom,scm-milos @@ -204,6 +207,7 @@ allOf: compatible: contains: enum: + - qcom,scm-eliza - qcom,scm-kaanapali - qcom,scm-milos - qcom,scm-sm8450 diff --git a/Documentation/devicetree/bindings/gpio/gpio-delay.yaml b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml index 1cebc4058e27..b99ceff6c5f6 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-delay.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: GPIO delay controller maintainers: - - Alexander Stein <linux@ew.tq-group.com> + - Alexander Stein <alexander.stein@ew.tq-group.com> description: | This binding describes an electrical setup where setting an GPIO output diff --git a/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt b/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt deleted file mode 100644 index 3f883ae29d11..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt +++ /dev/null @@ -1,27 +0,0 @@ -Cavium ThunderX/OCTEON-TX GPIO controller bindings - -Required Properties: -- reg: The controller bus address. -- gpio-controller: Marks the device node as a GPIO controller. -- #gpio-cells: Must be 2. - - First cell is the GPIO pin number relative to the controller. - - Second cell is a standard generic flag bitfield as described in gpio.txt. - -Optional Properties: -- compatible: "cavium,thunder-8890-gpio", unused as PCI driver binding is used. -- interrupt-controller: Marks the device node as an interrupt controller. -- #interrupt-cells: Must be present and have value of 2 if - "interrupt-controller" is present. - - First cell is the GPIO pin number relative to the controller. - - Second cell is triggering flags as defined in interrupts.txt. - -Example: - -gpio_6_0: gpio@6,0 { - compatible = "cavium,thunder-8890-gpio"; - reg = <0x3000 0 0 0 0>; /* DEVFN = 0x30 (6:0) */ - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; -}; diff --git a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml index 184432d24ea1..3da2cbcb652e 100644 --- a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml @@ -33,11 +33,14 @@ properties: clocks: maxItems: 1 + resets: + maxItems: 1 + "#gpio-cells": const: 2 "#interrupt-cells": - const: 1 + const: 2 ngpios: description: @@ -62,6 +65,11 @@ allOf: contains: const: microchip,mpfs-gpio then: + properties: + ngpios: + enum: [14, 24, 32] + interrupts: + minItems: 14 required: - interrupts - "#interrupt-cells" @@ -82,18 +90,19 @@ examples: compatible = "microchip,mpfs-gpio"; reg = <0x20122000 0x1000>; clocks = <&clkcfg 25>; - interrupt-parent = <&plic>; + interrupt-parent = <&irqmux>; gpio-controller; #gpio-cells = <2>; + ngpios = <32>; interrupt-controller; - #interrupt-cells = <1>; - interrupts = <53>, <53>, <53>, <53>, - <53>, <53>, <53>, <53>, - <53>, <53>, <53>, <53>, - <53>, <53>, <53>, <53>, - <53>, <53>, <53>, <53>, - <53>, <53>, <53>, <53>, - <53>, <53>, <53>, <53>, - <53>, <53>, <53>, <53>; + #interrupt-cells = <2>; + interrupts = <64>, <65>, <66>, <67>, + <68>, <69>, <70>, <71>, + <72>, <73>, <74>, <75>, + <76>, <77>, <78>, <79>, + <80>, <81>, <82>, <83>, + <84>, <85>, <86>, <87>, + <88>, <89>, <90>, <91>, + <92>, <93>, <94>, <95>; }; ... diff --git a/Documentation/devicetree/bindings/gpio/pin-control-gpio.yaml b/Documentation/devicetree/bindings/gpio/pin-control-gpio.yaml new file mode 100644 index 000000000000..a05cd339253a --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/pin-control-gpio.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/pin-control-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Pin control based generic GPIO controller + +description: + The pin control-based GPIO will facilitate a pin controller's ability + to drive electric lines high/low and other generic properties of a + pin controller to perform general-purpose one-bit binary I/O. + +maintainers: + - Dan Carpenter <dan.carpenter@linaro.org> + +properties: + compatible: + const: scmi-pinctrl-gpio + + gpio-controller: true + + "#gpio-cells": + const: 2 + + gpio-line-names: true + + gpio-ranges: true + + ngpios: true + +patternProperties: + "^.+-hog(-[0-9]+)?$": + type: object + + required: + - gpio-hog + +required: + - compatible + - gpio-controller + - "#gpio-cells" + - gpio-ranges + - ngpios + +additionalProperties: false + +examples: + - | + gpio { + compatible = "scmi-pinctrl-gpio"; + gpio-controller; + #gpio-cells = <2>; + ngpios = <4>; + gpio-line-names = "gpio_5_17", "gpio_5_20", "gpio_5_22", "gpio_2_1"; + gpio-ranges = <&scmi_pinctrl 0 30 4>; + pinctrl-names = "default"; + pinctrl-0 = <&keys_pins>; + }; diff --git a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml index 728099c65824..b18f8f0ca0ae 100644 --- a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml @@ -30,6 +30,7 @@ properties: - realtek,rtl8390-gpio - realtek,rtl9300-gpio - realtek,rtl9310-gpio + - realtek,rtl9607-gpio - const: realtek,otto-gpio reg: true diff --git a/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml b/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml index 3f4bbd57fc52..fe9b14a72d69 100644 --- a/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml @@ -27,7 +27,6 @@ properties: - gateworks,pld-gpio - ibm,ppc4xx-gpio - loongson,ls1x-gpio - - maxim,max77620 - nintendo,hollywood-gpio - nxp,pca9570 - nxp,pca9571 @@ -86,7 +85,6 @@ allOf: compatible: contains: enum: - - maxim,max77620 - rockchip,rk3328-grf-gpio - ti,lp3943-gpio - ti,palmas-gpio diff --git a/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml b/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml deleted file mode 100644 index 5d3ce641fcde..000000000000 --- a/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml +++ /dev/null @@ -1,105 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/hwmon/baikal,bt1-pvt.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Baikal-T1 PVT Sensor - -maintainers: - - Serge Semin <fancer.lancer@gmail.com> - -description: | - Baikal-T1 SoC provides an embedded process, voltage and temperature - sensor to monitor an internal SoC environment (chip temperature, supply - voltage and process monitor) and on time detect critical situations, - which may cause the system instability and even damages. The IP-block - is based on the Analog Bits PVT sensor, but is equipped with a dedicated - control wrapper, which provides a MMIO registers-based access to the - sensor core functionality (APB3-bus based) and exposes an additional - functions like thresholds/data ready interrupts, its status and masks, - measurements timeout. Its internal structure is depicted on the next - diagram: - - Analog Bits core Bakal-T1 PVT control block - +--------------------+ +------------------------+ - | Temperature sensor |-+ +------| Sensors control | - |--------------------| |<---En---| |------------------------| - | Voltage sensor |-|<--Mode--| +--->| Sampled data | - |--------------------| |<--Trim--+ | |------------------------| - | Low-Vt sensor |-| | +--| Thresholds comparator | - |--------------------| |---Data----| | |------------------------| - | High-Vt sensor |-| | +->| Interrupts status | - |--------------------| |--Valid--+-+ | |------------------------| - | Standard-Vt sensor |-+ +---+--| Interrupts mask | - +--------------------+ |------------------------| - ^ | Interrupts timeout | - | +------------------------+ - | ^ ^ - Rclk-----+----------------------------------------+ | - APB3-------------------------------------------------+ - - This bindings describes the external Baikal-T1 PVT control interfaces - like MMIO registers space, interrupt request number and clocks source. - These are then used by the corresponding hwmon device driver to - implement the sysfs files-based access to the sensors functionality. - -properties: - compatible: - const: baikal,bt1-pvt - - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - - clocks: - items: - - description: PVT reference clock - - description: APB3 interface clock - - clock-names: - items: - - const: ref - - const: pclk - - "#thermal-sensor-cells": - description: Baikal-T1 can be referenced as the CPU thermal-sensor - const: 0 - - baikal,pvt-temp-offset-millicelsius: - description: | - Temperature sensor trimming factor. It can be used to manually adjust the - temperature measurements within 7.130 degrees Celsius. - default: 0 - minimum: 0 - maximum: 7130 - -additionalProperties: false - -required: - - compatible - - reg - - interrupts - - clocks - - clock-names - -examples: - - | - #include <dt-bindings/interrupt-controller/mips-gic.h> - - pvt@1f200000 { - compatible = "baikal,bt1-pvt"; - reg = <0x1f200000 0x1000>; - #thermal-sensor-cells = <0>; - - interrupts = <GIC_SHARED 31 IRQ_TYPE_LEVEL_HIGH>; - - baikal,pvt-temp-offset-millicelsius = <1000>; - - clocks = <&ccu_sys>, <&ccu_sys>; - clock-names = "ref", "pclk"; - }; -... diff --git a/Documentation/devicetree/bindings/hwmon/microchip,mcp9982.yaml b/Documentation/devicetree/bindings/hwmon/microchip,mcp9982.yaml new file mode 100644 index 000000000000..83dd2bf37e27 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/microchip,mcp9982.yaml @@ -0,0 +1,237 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/microchip,mcp9982.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MCP998X/33 and MCP998XD/33D Temperature Monitor + +maintainers: + - Victor Duicu <victor.duicu@microchip.com> + +description: | + The MCP998X/33 and MCP998XD/33D family is a high-accuracy 2-wire + multichannel automotive temperature monitor. + The datasheet can be found here: + https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/MCP998X-Family-Data-Sheet-DS20006827.pdf + +properties: + compatible: + enum: + - microchip,mcp9933 + - microchip,mcp9933d + - microchip,mcp9982 + - microchip,mcp9982d + - microchip,mcp9983 + - microchip,mcp9983d + - microchip,mcp9984 + - microchip,mcp9984d + - microchip,mcp9985 + - microchip,mcp9985d + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + description: + The chip family has three different interrupt pins divided among them. + The chips without "D" have alert-therm and therm-addr. + The chips with "D" have alert-therm and sys-shtdwn. + minItems: 1 + items: + - enum: [alert-therm, therm-addr, sys-shtdwn] + - enum: [therm-addr, sys-shtdwn] + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + microchip,enable-anti-parallel: + description: + Enable anti-parallel diode mode operation. + MCP9984/84D/85/85D and MCP9933/33D support reading two external diodes + in anti-parallel connection on the same set of pins. + type: boolean + + microchip,parasitic-res-on-channel1-2: + description: + Indicates that the chip and the diodes/transistors are sufficiently far + apart that a parasitic resistance is added to the wires, which can affect + the measurements. Due to the anti-parallel diode connections, channels + 1 and 2 are affected together. + type: boolean + + microchip,parasitic-res-on-channel3-4: + description: + Indicates that the chip and the diodes/transistors are sufficiently far + apart that a parasitic resistance is added to the wires, which can affect + the measurements. Due to the anti-parallel diode connections, channels + 3 and 4 are affected together. + type: boolean + + microchip,power-state: + description: + The chip can be set in Run state or Standby state. In Run state the ADC + is converting on all channels at the programmed conversion rate. + In Standby state the host must initiate a conversion cycle by writing + to the One-Shot register. + True value sets Run state. + Chips with "D" in the name can only be set in Run mode. + type: boolean + + vdd-supply: true + +patternProperties: + "^channel@[1-4]$": + description: + Represents the external temperature channels to which + a remote diode is connected. + type: object + + properties: + reg: + items: + maxItems: 1 + + label: + description: Unique name to identify which channel this is. + + required: + - reg + + additionalProperties: false + +required: + - compatible + - reg + - vdd-supply + +allOf: + - if: + properties: + compatible: + contains: + enum: + - microchip,mcp9982d + - microchip,mcp9983d + - microchip,mcp9984d + - microchip,mcp9985d + - microchip,mcp9933d + then: + properties: + interrupt-names: + items: + enum: + - alert-therm + - sys-shtdwn + required: + - microchip,power-state + - microchip,parasitic-res-on-channel1-2 + else: + properties: + microchip,power-state: true + interrupt-names: + items: + enum: + - alert-therm + - therm-addr + + - if: + properties: + compatible: + contains: + enum: + - microchip,mcp9983d + - microchip,mcp9984d + - microchip,mcp9985d + then: + required: + - microchip,parasitic-res-on-channel3-4 + + - if: + properties: + compatible: + contains: + enum: + - microchip,mcp9982 + - microchip,mcp9982d + then: + properties: + microchip,enable-anti-parallel: false + patternProperties: + "^channel@[2-4]$": false + + - if: + properties: + compatible: + contains: + enum: + - microchip,mcp9983 + - microchip,mcp9983d + then: + properties: + microchip,enable-anti-parallel: false + patternProperties: + "^channel@[3-4]$": false + + - if: + properties: + compatible: + contains: + enum: + - microchip,mcp9933 + - microchip,mcp9933d + then: + patternProperties: + "^channel@[3-4]$": false + + - if: + properties: + compatible: + contains: + enum: + - microchip,mcp9984 + - microchip,mcp9984d + then: + properties: + channel@4: false + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + temperature-sensor@4c { + compatible = "microchip,mcp9985"; + reg = <0x4c>; + + #address-cells = <1>; + #size-cells = <0>; + + microchip,enable-anti-parallel; + microchip,parasitic-res-on-channel1-2; + microchip,parasitic-res-on-channel3-4; + vdd-supply = <&vdd>; + + channel@1 { + reg = <1>; + label = "Room Temperature"; + }; + + channel@2 { + reg = <2>; + label = "GPU Temperature"; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml index 56db2292f062..7d57c2934a8a 100644 --- a/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml +++ b/Documentation/devicetree/bindings/hwmon/moortec,mr75203.yaml @@ -105,7 +105,7 @@ properties: G coefficient for temperature equation. Default for series 5 = 60000 Default for series 6 = 57400 - multipleOf: 100 + multipleOf: 10 minimum: 1000 $ref: /schemas/types.yaml#/definitions/uint32 @@ -131,7 +131,7 @@ properties: J coefficient for temperature equation. Default for series 5 = -100 Default for series 6 = 0 - multipleOf: 100 + multipleOf: 10 maximum: 0 $ref: /schemas/types.yaml#/definitions/int32 diff --git a/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt deleted file mode 100644 index 18095ba87a5a..000000000000 --- a/Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt +++ /dev/null @@ -1,88 +0,0 @@ -Nuvoton NPCM PWM and Fan Tacho controller device - -The Nuvoton BMC NPCM7XX supports 8 Pulse-width modulation (PWM) -controller outputs and 16 Fan tachometer controller inputs. - -The Nuvoton BMC NPCM8XX supports 12 Pulse-width modulation (PWM) -controller outputs and 16 Fan tachometer controller inputs. - -Required properties for pwm-fan node -- #address-cells : should be 1. -- #size-cells : should be 0. -- compatible : "nuvoton,npcm750-pwm-fan" for Poleg NPCM7XX. - : "nuvoton,npcm845-pwm-fan" for Arbel NPCM8XX. -- reg : specifies physical base address and size of the registers. -- reg-names : must contain: - * "pwm" for the PWM registers. - * "fan" for the Fan registers. -- clocks : phandle of reference clocks. -- clock-names : must contain - * "pwm" for PWM controller operating clock. - * "fan" for Fan controller operating clock. -- interrupts : contain the Fan interrupts with flags for falling edge. -- pinctrl-names : a pinctrl state named "default" must be defined. -- pinctrl-0 : phandle referencing pin configuration of the PWM and Fan - controller ports. - -fan subnode format: -=================== -Under fan subnode can be upto 8 child nodes, each child node representing a fan. -Each fan subnode must have one PWM channel and at least one Fan tach channel. - -For PWM channel can be configured cooling-levels to create cooling device. -Cooling device could be bound to a thermal zone for the thermal control. - -Required properties for each child node: -- reg : specify the PWM output channel. - integer value in the range 0 through 7, that represent - the PWM channel number that used. - -- fan-tach-ch : specify the Fan tach input channel. - integer value in the range 0 through 15, that represent - the fan tach channel number that used. - - At least one Fan tach input channel is required - -Optional property for each child node: -- cooling-levels: PWM duty cycle values in a range from 0 to 255 - which correspond to thermal cooling states. - -Examples: - -pwm_fan:pwm-fan-controller@103000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "nuvoton,npcm750-pwm-fan"; - reg = <0x103000 0x2000>, - <0x180000 0x8000>; - reg-names = "pwm", "fan"; - clocks = <&clk NPCM7XX_CLK_APB3>, - <&clk NPCM7XX_CLK_APB4>; - clock-names = "pwm","fan"; - interrupts = <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>, - <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>; - pinctrl-names = "default"; - pinctrl-0 = <&pwm0_pins &pwm1_pins &pwm2_pins - &fanin0_pins &fanin1_pins &fanin2_pins - &fanin3_pins &fanin4_pins>; - fan@0 { - reg = <0x00>; - fan-tach-ch = /bits/ 8 <0x00 0x01>; - cooling-levels = <127 255>; - }; - fan@1 { - reg = <0x01>; - fan-tach-ch = /bits/ 8 <0x02 0x03>; - }; - fan@2 { - reg = <0x02>; - fan-tach-ch = /bits/ 8 <0x04>; - }; - -}; diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,npcm750-pwm-fan.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,npcm750-pwm-fan.yaml new file mode 100644 index 000000000000..73464af3078e --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/nuvoton,npcm750-pwm-fan.yaml @@ -0,0 +1,139 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/nuvoton,npcm750-pwm-fan.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton NPCM7xx/NPCM8xx PWM and Fan Tach Controller + +maintainers: + - Tomer Maimon <tmaimon77@gmail.com> + +description: + The NPCM7xx/NPCM8xx family includes a PWM and Fan Tachometer controller. + The controller provides up to 8 (NPCM7xx) or 12 (NPCM8xx) PWM channels and up + to 16 tachometer inputs. It is used for fan speed control and monitoring. + +properties: + compatible: + enum: + - nuvoton,npcm750-pwm-fan + - nuvoton,npcm845-pwm-fan + + reg: + maxItems: 2 + description: Register addresses for PWM and Fan Tach units. + + reg-names: + items: + - const: pwm + - const: fan + + clocks: + maxItems: 2 + description: Clocks for the PWM and Fan Tach modules. + + clock-names: + items: + - const: pwm + - const: fan + + interrupts: + description: + Contains the Fan interrupts with flags for falling edge. + For NPCM7XX, 8 interrupt lines are expected (one per PWM channel). + For NPCM8XX, 12 interrupt lines are expected (one per PWM channel). + + minItems: 8 + maxItems: 12 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^fan@[0-9a-f]+$": + type: object + $ref: fan-common.yaml# + unevaluatedProperties: false + + properties: + reg: + description: + Specify the PWM output channel. Integer value in the range 0-7 for + NPCM7XX or 0-11 for NPCM8XX, representing the PWM channel number. + + maximum: 11 + + fan-tach-ch: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: + The tach channel(s) used for the fan. + Integer values in the range 0-15. + + items: + maximum: 15 + + cooling-levels: + description: + PWM duty cycle values in a range from 0 to 255 which + correspond to thermal cooling states. This property enables + thermal zone integration for automatic fan speed control + based on temperature. + + items: + maximum: 255 + + required: + - reg + - fan-tach-ch + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/nuvoton,npcm7xx-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + pwm_fan: pwm-fan@103000 { + compatible = "nuvoton,npcm750-pwm-fan"; + #address-cells = <1>; + #size-cells = <0>; + + reg = <0x103000 0x2000>, <0x180000 0x8000>; + reg-names = "pwm", "fan"; + + clocks = <&clk NPCM7XX_CLK_APB3>, <&clk NPCM7XX_CLK_APB4>; + clock-names = "pwm", "fan"; + + interrupts = <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>, + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&pwm0_pins &fanin0_pins>; + + fan@0 { + reg = <0>; + fan-tach-ch = <0 1>; + cooling-levels = <64 128 192 255>; + }; + + fan@1 { + reg = <1>; + fan-tach-ch = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml new file mode 100644 index 000000000000..72bc3a5e7139 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,xdp720.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Infineon XDP720 Digital eFuse Controller + +maintainers: + - Ashish Yadav <ashish.yadav@infineon.com> + +description: | + The XDP720 is an eFuse with integrated current sensor and digital + controller. It provides accurate system telemetry (V, I, P, T) and + reports analog current at the IMON pin for post-processing. + + Datasheet: + https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf + +properties: + compatible: + enum: + - infineon,xdp720 + + reg: + maxItems: 1 + + infineon,rimon-micro-ohms: + description: + The value of the RIMON resistor, in micro ohms, required to enable + the system overcurrent protection. + + vdd-vin-supply: + description: + Supply for the VDD_VIN pin (pin 9), the IC controller power supply. + Typically connected to the input bus (VIN) through a 100 ohm / 100 nF + RC filter. + +required: + - compatible + - reg + - vdd-vin-supply + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + hwmon@11 { + compatible = "infineon,xdp720"; + reg = <0x11>; + vdd-vin-supply = <&vdd_vin>; + infineon,rimon-micro-ohms = <1098000000>; /* 1.098k ohm */ + }; + }; diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml index ae23a05375cb..8216cdf758d8 100644 --- a/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml +++ b/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml @@ -16,49 +16,56 @@ description: | properties: compatible: - enum: - - isil,isl68137 - - renesas,isl68220 - - renesas,isl68221 - - renesas,isl68222 - - renesas,isl68223 - - renesas,isl68224 - - renesas,isl68225 - - renesas,isl68226 - - renesas,isl68227 - - renesas,isl68229 - - renesas,isl68233 - - renesas,isl68239 - - renesas,isl69222 - - renesas,isl69223 - - renesas,isl69224 - - renesas,isl69225 - - renesas,isl69227 - - renesas,isl69228 - - renesas,isl69234 - - renesas,isl69236 - - renesas,isl69239 - - renesas,isl69242 - - renesas,isl69243 - - renesas,isl69247 - - renesas,isl69248 - - renesas,isl69254 - - renesas,isl69255 - - renesas,isl69256 - - renesas,isl69259 - - isil,isl69260 - - renesas,isl69268 - - isil,isl69269 - - renesas,isl69298 - - renesas,raa228000 - - renesas,raa228004 - - renesas,raa228006 - - renesas,raa228228 - - renesas,raa228244 - - renesas,raa228246 - - renesas,raa229001 - - renesas,raa229004 - - renesas,raa229621 + oneOf: + - enum: + - isil,isl68137 + - renesas,isl68220 + - renesas,isl68221 + - renesas,isl68222 + - renesas,isl68223 + - renesas,isl68224 + - renesas,isl68225 + - renesas,isl68226 + - renesas,isl68227 + - renesas,isl68229 + - renesas,isl68233 + - renesas,isl68239 + - renesas,isl69222 + - renesas,isl69223 + - renesas,isl69224 + - renesas,isl69225 + - renesas,isl69227 + - renesas,isl69228 + - renesas,isl69234 + - renesas,isl69236 + - renesas,isl69239 + - renesas,isl69242 + - renesas,isl69243 + - renesas,isl69247 + - renesas,isl69248 + - renesas,isl69254 + - renesas,isl69255 + - renesas,isl69256 + - renesas,isl69259 + - isil,isl69260 + - renesas,isl69268 + - isil,isl69269 + - renesas,isl69298 + - renesas,raa228000 + - renesas,raa228004 + - renesas,raa228006 + - renesas,raa228228 + - renesas,raa228244 + - renesas,raa228246 + - renesas,raa229001 + - renesas,raa229004 + - renesas,raa229621 + + - items: + - enum: + - renesas,raa228942 + - renesas,raa228943 + - const: renesas,raa228244 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml index d3cde8936686..009d78b30859 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml @@ -29,6 +29,7 @@ properties: - ti,ina230 - ti,ina231 - ti,ina233 + - ti,ina234 - ti,ina237 - ti,ina238 - ti,ina260 @@ -113,6 +114,7 @@ allOf: - ti,ina228 - ti,ina230 - ti,ina231 + - ti,ina234 - ti,ina237 - ti,ina238 - ti,ina260 @@ -134,6 +136,7 @@ allOf: - ti,ina226 - ti,ina230 - ti,ina231 + - ti,ina234 - ti,ina260 - ti,ina700 - ti,ina780 diff --git a/Documentation/devicetree/bindings/i2c/i2c-iop3xx.txt b/Documentation/devicetree/bindings/i2c/i2c-iop3xx.txt deleted file mode 100644 index dcc8390e0d24..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-iop3xx.txt +++ /dev/null @@ -1,20 +0,0 @@ -i2c Controller on XScale platforms such as IOP3xx and IXP4xx - -Required properties: -- compatible : Must be one of - "intel,iop3xx-i2c" - "intel,ixp4xx-i2c"; -- reg -- #address-cells = <1>; -- #size-cells = <0>; - -Optional properties: -- Child nodes conforming to i2c bus binding - -Example: - -i2c@c8011000 { - compatible = "intel,ixp4xx-i2c"; - reg = <0xc8011000 0x18>; - interrupts = <33 IRQ_TYPE_LEVEL_LOW>; -}; diff --git a/Documentation/devicetree/bindings/i2c/intel,ixp4xx-i2c.yaml b/Documentation/devicetree/bindings/i2c/intel,ixp4xx-i2c.yaml new file mode 100644 index 000000000000..15ef510f6fd8 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/intel,ixp4xx-i2c.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/intel,ixp4xx-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: I2c Controller on XScale platforms such as IOP3xx and IXP4xx + +maintainers: + - Andi Shyti <andi.shyti@kernel.org> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + enum: + - intel,iop3xx-i2c + - intel,ixp4xx-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c@c8011000 { + compatible = "intel,ixp4xx-i2c"; + reg = <0xc8011000 0x18>; + interrupts = <33 IRQ_TYPE_LEVEL_LOW>; + }; diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml index 399a09409e07..7c497a358e1d 100644 --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml @@ -27,6 +27,7 @@ properties: - items: - enum: - qcom,kaanapali-cci + - qcom,milos-cci - qcom,qcm2290-cci - qcom,qcs8300-cci - qcom,sa8775p-cci @@ -34,6 +35,7 @@ properties: - qcom,sc8280xp-cci - qcom,sdm670-cci - qcom,sdm845-cci + - qcom,sm6150-cci - qcom,sm6350-cci - qcom,sm8250-cci - qcom,sm8450-cci @@ -251,6 +253,7 @@ allOf: contains: enum: - qcom,sa8775p-cci + - qcom,sm6150-cci - qcom,sm8550-cci - qcom,sm8650-cci - qcom,x1e80100-cci @@ -265,6 +268,23 @@ allOf: - const: cpas_ahb - const: cci + - if: + properties: + compatible: + contains: + enum: + - qcom,milos-cci + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: soc_ahb + - const: cpas_ahb + - const: cci + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml b/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml index f9a449fee2b0..5873cfdc5b3e 100644 --- a/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml @@ -15,6 +15,8 @@ description: assigned to either I2C controller. RTL9310 SoCs have equal capabilities but support 12 common SDA lines which can be assigned to either I2C controller. + RTL9607C SoCs have equal capabilities but each controller only supports 1 + SCL/SDA line. properties: compatible: @@ -34,6 +36,7 @@ properties: - enum: - realtek,rtl9301-i2c - realtek,rtl9310-i2c + - realtek,rtl9607-i2c reg: items: @@ -51,6 +54,9 @@ properties: The SCL line number of this I2C controller. enum: [ 0, 1 ] + clocks: + maxItems: 1 + patternProperties: '^i2c@[0-9ab]$': $ref: /schemas/i2c/i2c-controller.yaml @@ -81,6 +87,15 @@ allOf: then: patternProperties: '^i2c@[89ab]$': false + - if: + properties: + compatible: + contains: + const: realtek,rtl9607-i2c + then: + required: + - realtek,scl + - clocks required: - compatible diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml index 6876eade431b..ae1f71eadc66 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -25,6 +25,7 @@ properties: - items: - enum: - renesas,riic-r9a08g045 # RZ/G3S + - renesas,riic-r9a08g046 # RZ/G3L - renesas,riic-r9a09g047 # RZ/G3E - renesas,riic-r9a09g056 # RZ/V2N - const: renesas,riic-r9a09g057 # RZ/V2H(P) diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml index 082fdc2e69ea..467bdcbb8538 100644 --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml @@ -32,8 +32,6 @@ properties: - const: renesas,r9a06g032-i2c # RZ/N1D - const: renesas,rzn1-i2c # RZ/N1 - const: snps,designware-i2c - - description: Baikal-T1 SoC System I2C controller - const: baikal,bt1-sys-i2c - description: Mobileye EyeQ DesignWare I2C controller items: - enum: diff --git a/Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml b/Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml index 5896fb120501..8c04c675b25e 100644 --- a/Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml @@ -14,7 +14,11 @@ allOf: properties: compatible: - const: spacemit,k1-i2c + oneOf: + - items: + - const: spacemit,k3-i2c + - const: spacemit,k1-i2c + - const: spacemit,k1-i2c reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl,imx25-tcq.yaml b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx25-tcq.yaml new file mode 100644 index 000000000000..94452ac423d0 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl,imx25-tcq.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/fsl,imx25-tcq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale mx25 TS conversion queue module + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +description: + mx25 touchscreen conversion queue module which controls the ADC unit of the + mx25 for attached touchscreens. + +properties: + compatible: + const: fsl,imx25-tcq + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + fsl,wires: + description: touch wires number. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [4, 5] + + fsl,pen-debounce-ns: + description: + Pen debounce time in nanoseconds. + + fsl,pen-threshold: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Pen-down threshold for the touchscreen. This is a value + between 1 and 4096. It is the ratio between the internal reference voltage + and the measured voltage after the plate was precharged. Resistance between + plates and therefore the voltage decreases with pressure so that a smaller + value is equivalent to a higher pressure. + + fsl,settling-time-ns: + description: + Settling time in nanoseconds. The settling time is before + the actual touch detection to wait for an even charge distribution in the + plate. + +allOf: + - $ref: touchscreen.yaml + +required: + - compatible + - reg + - interrupts + - fsl,wires + +unevaluatedProperties: false + +examples: + - | + touchscreen@50030400 { + compatible = "fsl,imx25-tcq"; + reg = <0x50030400 0x60>; + interrupt-parent = <&tscadc>; + interrupts = <0>; + fsl,wires = <4>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt deleted file mode 100644 index 99d6f9d25335..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt +++ /dev/null @@ -1,34 +0,0 @@ -Freescale mx25 TS conversion queue module - -mx25 touchscreen conversion queue module which controls the ADC unit of the -mx25 for attached touchscreens. - -Required properties: - - compatible: Should be "fsl,imx25-tcq". - - reg: Memory range of the device. - - interrupts: Should be the interrupt number associated with this module within - the tscadc unit (<0>). - - fsl,wires: Should be '<4>' or '<5>' - -Optional properties: - - fsl,pen-debounce-ns: Pen debounce time in nanoseconds. - - fsl,pen-threshold: Pen-down threshold for the touchscreen. This is a value - between 1 and 4096. It is the ratio between the internal reference voltage - and the measured voltage after the plate was precharged. Resistance between - plates and therefore the voltage decreases with pressure so that a smaller - value is equivalent to a higher pressure. - - fsl,settling-time-ns: Settling time in nanoseconds. The settling time is before - the actual touch detection to wait for an even charge distribution in the - plate. - -This device includes two conversion queues which can be added as subnodes. -The first queue is for the touchscreen, the second for general purpose ADC. - -Example: - tsc: tcq@50030400 { - compatible = "fsl,imx25-tcq"; - reg = <0x50030400 0x60>; - interrupt-parent = <&tscadc>; - interrupts = <0>; - fsl,wires = <4>; - }; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,eliza-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,eliza-rpmh.yaml new file mode 100644 index 000000000000..9a926a97e7bf --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/qcom,eliza-rpmh.yaml @@ -0,0 +1,142 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/qcom,eliza-rpmh.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm RPMh Network-On-Chip Interconnect on Eliza SoC + +maintainers: + - Odelu Kukatla <odelu.kukatla@oss.qualcomm.com> + +description: | + RPMh interconnect providers support system bandwidth requirements through + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is + able to communicate with the BCM through the Resource State Coordinator (RSC) + associated with each execution environment. Provider nodes must point to at + least one RPMh device child node pertaining to their RSC and each provider + can map to multiple RPMh resources. + + See also: include/dt-bindings/interconnect/qcom,eliza-rpmh.h + +properties: + compatible: + enum: + - qcom,eliza-aggre1-noc + - qcom,eliza-aggre2-noc + - qcom,eliza-clk-virt + - qcom,eliza-cnoc-cfg + - qcom,eliza-cnoc-main + - qcom,eliza-gem-noc + - qcom,eliza-lpass-ag-noc + - qcom,eliza-lpass-lpiaon-noc + - qcom,eliza-lpass-lpicx-noc + - qcom,eliza-mc-virt + - qcom,eliza-mmss-noc + - qcom,eliza-nsp-noc + - qcom,eliza-pcie-anoc + - qcom,eliza-system-noc + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + +required: + - compatible + +allOf: + - $ref: qcom,rpmh-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - qcom,eliza-clk-virt + - qcom,eliza-mc-virt + then: + properties: + reg: false + else: + required: + - reg + + - if: + properties: + compatible: + contains: + enum: + - qcom,eliza-aggre1-noc + then: + properties: + clocks: + items: + - description: aggre UFS PHY AXI clock + - description: aggre USB3 PRIM AXI clock + + - if: + properties: + compatible: + contains: + enum: + - qcom,eliza-aggre2-noc + then: + properties: + clocks: + items: + - description: RPMH CC IPA clock + + - if: + properties: + compatible: + contains: + enum: + - qcom,eliza-pcie-anoc + then: + properties: + clocks: + items: + - description: aggre-NOC PCIe AXI clock + - description: cfg-NOC PCIe a-NOC AHB clock + + - if: + properties: + compatible: + contains: + enum: + - qcom,eliza-aggre1-noc + - qcom,eliza-aggre2-noc + - qcom,eliza-pcie-anoc + then: + required: + - clocks + else: + properties: + clocks: false + +unevaluatedProperties: false + +examples: + - | + gem_noc: interconnect@24100000 { + compatible = "qcom,eliza-gem-noc"; + reg = <0x24100000 0x163080>; + #interconnect-cells = <2>; + qcom,bcm-voters = <&apps_bcm_voter>; + }; + + mc_virt: interconnect-2 { + compatible = "qcom,eliza-mc-virt"; + #interconnect-cells = <2>; + qcom,bcm-voters = <&apps_bcm_voter>; + }; + + aggre1_noc: interconnect@16e0000 { + compatible = "qcom,eliza-aggre1-noc"; + reg = <0x16e0000 0x16400>; + #interconnect-cells = <2>; + clocks = <&gcc_phy_axi_clk>, <&gcc_prim_axi_clk>; + qcom,bcm-voters = <&apps_bcm_voter>; + }; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index 4b9b98fbe8f2..6182599eb3c1 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -28,6 +28,7 @@ properties: - const: qcom,osm-l3 - items: - enum: + - qcom,eliza-epss-l3 - qcom,sa8775p-epss-l3 - qcom,sc7280-epss-l3 - qcom,sc8280xp-epss-l3 diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml index ee5a0dfff437..d0d9a90e96e7 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml @@ -4,10 +4,10 @@ $id: http://devicetree.org/schemas/interrupt-controller/apple,aic2.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Apple Interrupt Controller 2 +title: Apple Interrupt Controller 2 and 3 maintainers: - - Hector Martin <marcan@marcan.st> + - Janne Grunau <j@jannau.net> description: | The Apple Interrupt Controller 2 is a simple interrupt controller present on @@ -28,14 +28,24 @@ description: | which do not go through a discrete interrupt controller. It also handles FIQ-based Fast IPIs. + The Apple Interrupt Controller 3 is in its base functionality very similar to + the Apple Interrupt Controller 2 and uses the same device tree bindings. It is + found on Apple ARM SoCs platforms starting with t8122 (M3). + properties: compatible: - items: - - enum: - - apple,t8112-aic - - apple,t6000-aic - - apple,t6020-aic - - const: apple,aic2 + oneOf: + - items: + - enum: + - apple,t6000-aic + - apple,t6020-aic + - apple,t8112-aic + - const: apple,aic2 + - items: + - enum: + - apple,t6030-aic3 + - const: apple,t8122-aic3 + - const: apple,t8122-aic3 interrupt-controller: true @@ -117,7 +127,9 @@ allOf: properties: compatible: contains: - const: apple,t8112-aic + enum: + - apple,t8112-aic + - apple,t8122-aic3 then: properties: '#interrupt-cells': diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index bfd30aae682b..360a0643a0b5 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml @@ -50,7 +50,7 @@ properties: The 2nd cell contains the interrupt number for the interrupt type. SPI interrupts are in the range [0-987]. PPI interrupts are in the range [0-15]. Extended SPI interrupts are in the range [0-1023]. - Extended PPI interrupts are in the range [0-127]. + Extended PPI interrupts are in the range [0-63]. The 3rd cell is the flags, encoded as follows: bits[3:0] trigger type and level flags. diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml index 5c768c1e159c..13cd37bf48e4 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml @@ -12,7 +12,9 @@ maintainers: properties: compatible: oneOf: - - const: fsl,imx-irqsteer + - enum: + - fsl,imx-irqsteer + - nxp,s32n79-irqsteer - items: - enum: - fsl,imx8m-irqsteer diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-lpc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-lpc.yaml new file mode 100644 index 000000000000..ff2a425b6f0b --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,pch-lpc.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/loongson,pch-lpc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson PCH LPC Controller + +maintainers: + - Jiaxun Yang <jiaxun.yang@flygoat.com> + +description: + This interrupt controller is found in the Loongson LS7A family of PCH for + accepting interrupts sent by LPC-connected peripherals and signalling PIC + via a single interrupt line when interrupts are available. + +properties: + compatible: + const: loongson,ls7a-lpc + + reg: + maxItems: 1 + + interrupt-controller: true + + interrupts: + maxItems: 1 + + '#interrupt-cells': + const: 2 + +required: + - compatible + - reg + - interrupt-controller + - interrupts + - '#interrupt-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + lpc: interrupt-controller@10002000 { + compatible = "loongson,ls7a-lpc"; + reg = <0x10002000 0x400>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&pic>; + interrupts = <19 IRQ_TYPE_LEVEL_HIGH>; + }; +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml index 074a873880e5..d0c039d14ad2 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/nvidia,tegra20-ictlr.yaml @@ -35,11 +35,12 @@ properties: - enum: - nvidia,tegra20-ictlr - nvidia,tegra30-ictlr + - nvidia,tegra210-ictlr reg: description: Each entry is a block of 32 interrupts minItems: 4 - maxItems: 5 + maxItems: 6 interrupt-controller: true @@ -64,10 +65,28 @@ allOf: properties: reg: maxItems: 4 - else: + + - if: + properties: + compatible: + contains: + const: nvidia,tegra30-ictlr + then: properties: reg: minItems: 5 + maxItems: 5 + + - if: + properties: + compatible: + contains: + const: nvidia,tegra210-ictlr + then: + properties: + reg: + minItems: 6 + maxItems: 6 examples: - | diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml index f9321366cae4..b4942881b9c9 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml @@ -26,7 +26,9 @@ properties: compatible: items: - enum: + - qcom,eliza-pdc - qcom,glymur-pdc + - qcom,hawi-pdc - qcom,kaanapali-pdc - qcom,milos-pdc - qcom,qcs615-pdc diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml index 44b6ae5fc802..3a221e1800a0 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzg2l-irqc.yaml @@ -30,7 +30,9 @@ properties: - renesas,r9a08g045-irqc # RZ/G3S - const: renesas,rzg2l-irqc - - const: renesas,r9a07g043f-irqc # RZ/Five + - enum: + - renesas,r9a07g043f-irqc # RZ/Five + - renesas,r9a08g046-irqc # RZ/G3L '#interrupt-cells': description: The first cell should contain a macro RZG2L_{NMI,IRQX} included in the @@ -48,107 +50,35 @@ properties: interrupts: minItems: 45 - items: - - description: NMI interrupt - - description: IRQ0 interrupt - - description: IRQ1 interrupt - - description: IRQ2 interrupt - - description: IRQ3 interrupt - - description: IRQ4 interrupt - - description: IRQ5 interrupt - - description: IRQ6 interrupt - - description: IRQ7 interrupt - - description: GPIO interrupt, TINT0 - - description: GPIO interrupt, TINT1 - - description: GPIO interrupt, TINT2 - - description: GPIO interrupt, TINT3 - - description: GPIO interrupt, TINT4 - - description: GPIO interrupt, TINT5 - - description: GPIO interrupt, TINT6 - - description: GPIO interrupt, TINT7 - - description: GPIO interrupt, TINT8 - - description: GPIO interrupt, TINT9 - - description: GPIO interrupt, TINT10 - - description: GPIO interrupt, TINT11 - - description: GPIO interrupt, TINT12 - - description: GPIO interrupt, TINT13 - - description: GPIO interrupt, TINT14 - - description: GPIO interrupt, TINT15 - - description: GPIO interrupt, TINT16 - - description: GPIO interrupt, TINT17 - - description: GPIO interrupt, TINT18 - - description: GPIO interrupt, TINT19 - - description: GPIO interrupt, TINT20 - - description: GPIO interrupt, TINT21 - - description: GPIO interrupt, TINT22 - - description: GPIO interrupt, TINT23 - - description: GPIO interrupt, TINT24 - - description: GPIO interrupt, TINT25 - - description: GPIO interrupt, TINT26 - - description: GPIO interrupt, TINT27 - - description: GPIO interrupt, TINT28 - - description: GPIO interrupt, TINT29 - - description: GPIO interrupt, TINT30 - - description: GPIO interrupt, TINT31 - - description: Bus error interrupt - - description: ECCRAM0 or combined ECCRAM0/1 1bit error interrupt - - description: ECCRAM0 or combined ECCRAM0/1 2bit error interrupt - - description: ECCRAM0 or combined ECCRAM0/1 error overflow interrupt - - description: ECCRAM1 1bit error interrupt - - description: ECCRAM1 2bit error interrupt - - description: ECCRAM1 error overflow interrupt + maxItems: 61 interrupt-names: minItems: 45 + maxItems: 61 items: - - const: nmi - - const: irq0 - - const: irq1 - - const: irq2 - - const: irq3 - - const: irq4 - - const: irq5 - - const: irq6 - - const: irq7 - - const: tint0 - - const: tint1 - - const: tint2 - - const: tint3 - - const: tint4 - - const: tint5 - - const: tint6 - - const: tint7 - - const: tint8 - - const: tint9 - - const: tint10 - - const: tint11 - - const: tint12 - - const: tint13 - - const: tint14 - - const: tint15 - - const: tint16 - - const: tint17 - - const: tint18 - - const: tint19 - - const: tint20 - - const: tint21 - - const: tint22 - - const: tint23 - - const: tint24 - - const: tint25 - - const: tint26 - - const: tint27 - - const: tint28 - - const: tint29 - - const: tint30 - - const: tint31 - - const: bus-err - - const: ec7tie1-0 - - const: ec7tie2-0 - - const: ec7tiovf-0 - - const: ec7tie1-1 - - const: ec7tie2-1 - - const: ec7tiovf-1 + oneOf: + - description: NMI interrupt + const: nmi + - description: External IRQ interrupt + pattern: '^irq([0-9]|1[0-5])$' + - description: GPIO interrupt + pattern: '^tint([0-9]|1[0-9]|2[0-9]|3[0-1])$' + - description: Bus error interrupt + const: bus-err + - description: ECCRAM0 or combined ECCRAM0/1 1bit error interrupt + const: ec7tie1-0 + - description: ECCRAM0 or combined ECCRAM0/1 2bit error interrupt + const: ec7tie2-0 + - description: ECCRAM0 or combined ECCRAM0/1 error overflow interrupt + const: ec7tiovf-0 + - description: ECCRAM1 1bit error interrupt + const: ec7tie1-1 + - description: ECCRAM1 2bit error interrupt + const: ec7tie2-1 + - description: ECCRAM1 error overflow interrupt + const: ec7tiovf-1 + - description: Integrated GPT Error interrupt + pattern: '^ovfunf([0-7])$' clocks: maxItems: 2 @@ -185,6 +115,24 @@ allOf: compatible: contains: enum: + - renesas,r9a07g043f-irqc + - renesas,r9a07g043u-irqc + - renesas,r9a07g044-irqc + - renesas,r9a07g054-irqc + then: + properties: + interrupts: + minItems: 48 + maxItems: 48 + interrupt-names: + minItems: 48 + maxItems: 48 + + - if: + properties: + compatible: + contains: + enum: - renesas,r9a08g045-irqc then: properties: @@ -192,12 +140,19 @@ allOf: maxItems: 45 interrupt-names: maxItems: 45 - else: + + - if: + properties: + compatible: + contains: + enum: + - renesas,r9a08g046-irqc + then: properties: interrupts: - minItems: 48 + minItems: 61 interrupt-names: - minItems: 48 + minItems: 61 unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index cdbd23b5c08c..06fb5c8e7547 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -35,6 +35,7 @@ properties: - description: Qcom SoCs implementing "qcom,smmu-500" and "arm,mmu-500" items: - enum: + - qcom,eliza-smmu-500 - qcom,glymur-smmu-500 - qcom,kaanapali-smmu-500 - qcom,milos-smmu-500 @@ -92,6 +93,7 @@ properties: items: - enum: - qcom,glymur-smmu-500 + - qcom,hawi-smmu-500 - qcom,kaanapali-smmu-500 - qcom,milos-smmu-500 - qcom,qcm2290-smmu-500 diff --git a/Documentation/devicetree/bindings/leds/allwinner,sun50i-a100-ledc.yaml b/Documentation/devicetree/bindings/leds/allwinner,sun50i-a100-ledc.yaml index 760cb336dccb..0b73fe5b662f 100644 --- a/Documentation/devicetree/bindings/leds/allwinner,sun50i-a100-ledc.yaml +++ b/Documentation/devicetree/bindings/leds/allwinner,sun50i-a100-ledc.yaml @@ -21,6 +21,7 @@ properties: - enum: - allwinner,sun20i-d1-ledc - allwinner,sun50i-r329-ledc + - allwinner,sun55i-a523-ledc - const: allwinner,sun50i-a100-ledc reg: diff --git a/Documentation/devicetree/bindings/leds/leds-lp5860.yaml b/Documentation/devicetree/bindings/leds/leds-lp5860.yaml index 1ccba4854159..0e88c71c2d39 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp5860.yaml +++ b/Documentation/devicetree/bindings/leds/leds-lp5860.yaml @@ -33,6 +33,11 @@ properties: '#size-cells': const: 0 + enable-gpios: + maxItems: 1 + description: | + GPIO attached to the chip's enable pin (VIO_EN). + patternProperties: '^multi-led@[0-9a-f]+$': type: object @@ -74,6 +79,7 @@ unevaluatedProperties: false examples: - | + #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/leds/common.h> spi { @@ -83,6 +89,7 @@ examples: led-controller@0 { compatible = "ti,lp5860"; reg = <0x0>; + enable-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml b/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml index 97535d6dc47a..2ae5cc31e623 100644 --- a/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml +++ b/Documentation/devicetree/bindings/leds/sprd,sc2731-bltc.yaml @@ -18,7 +18,12 @@ description: | properties: compatible: - const: sprd,sc2731-bltc + oneOf: + - items: + - enum: + - sprd,sc2730-bltc + - const: sprd,sc2731-bltc + - const: sprd,sc2731-bltc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml b/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml index d3329e991d16..ae48dd4ab589 100644 --- a/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml +++ b/Documentation/devicetree/bindings/media/i2c/alliedvision,alvium-csi2.yaml @@ -8,7 +8,7 @@ title: Allied Vision Alvium Camera maintainers: - Tommaso Merciai <tomm.merciai@gmail.com> - - Martin Hecht <martin.hecht@avnet.eu> + - Martin Hecht <mhecht73@gmail.com> allOf: - $ref: /schemas/media/video-interface-devices.yaml# diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml index dffd23ca4839..e896f4db2421 100644 --- a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml +++ b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml @@ -17,7 +17,9 @@ description: |- properties: compatible: - const: onnn,mt9m114 + enum: + - onnn,mt9m114 + - aptina,mi1040 reg: description: I2C device address diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml new file mode 100644 index 000000000000..6f2017c75125 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov08d10.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Omnivision OV08D10 1/4-Inch 8MP CMOS color image sensor + +maintainers: + - Matthias Fend <matthias.fend@emfend.at> + +description: + The Omnivision OV08D10 is a 1/4-Inch 8MP CMOS color image sensor with an + active array size of 3280 x 2464. It is programmable through I2C + interface. Image data is transmitted via MIPI CSI-2 using 2 lanes. + +allOf: + - $ref: /schemas/media/video-interface-devices.yaml# + +properties: + compatible: + const: ovti,ov08d10 + + reg: + maxItems: 1 + + clocks: + description: MCLK input clock (6 - 27 MHz) + maxItems: 1 + + reset-gpios: + description: Active low XSHUTDN pin + maxItems: 1 + + dovdd-supply: + description: IO power supply (1.8V) + + avdd-supply: + description: Analog power supply (2.8V) + + dvdd-supply: + description: Core power supply (1.2V) + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + required: + - data-lanes + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/media/video-interfaces.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@36 { + compatible = "ovti,ov08d10"; + reg = <0x36>; + + clocks = <&ov08d10_clk>; + + dovdd-supply = <&ov08d10_vdddo_1v8>; + avdd-supply = <&ov08d10_vdda_2v8>; + dvdd-supply = <&ov08d10_vddd_1v2>; + + orientation = <2>; + rotation = <0>; + + reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + + port { + ov08d10_output: endpoint { + data-lanes = <1 2>; + link-frequencies = /bits/ 64 <360000000 720000000>; + remote-endpoint = <&csi_input>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2732.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2732.yaml new file mode 100644 index 000000000000..814fc568c550 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2732.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov2732.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OmniVision OV2732 Image Sensor + +maintainers: + - Walter Werner Schneider <contact@schnwalter.eu> + +description: + The OmniVision OV2732 is a 2MP (1920x1080) color CMOS image sensor controlled + through an I2C-compatible SCCB bus. + +properties: + compatible: + const: ovti,ov2732 + + reg: + maxItems: 1 + + clocks: + items: + - description: XVCLK clock + + avdd-supply: + description: Analog Domain Power Supply + + dovdd-supply: + description: I/O Domain Power Supply + + dvdd-supply: + description: Digital Domain Power Supply + + powerdown-gpios: + maxItems: 1 + description: Reference to the GPIO connected to the pwdn pin. Active low. + + reset-gpios: + maxItems: 1 + description: Reference to the GPIO connected to the reset pin. Active low. + + port: + description: MIPI CSI-2 transmitter port + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + items: + - const: 1 + - const: 2 + + required: + - data-lanes + - link-frequencies + +required: + - compatible + - reg + - clocks + - avdd-supply + - dovdd-supply + - dvdd-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ov2732: camera@36 { + compatible = "ovti,ov2732"; + reg = <0x36>; + clocks = <&ov2732_clk>; + + avdd-supply = <&ov2732_avdd>; + dovdd-supply = <&ov2732_dovdd>; + dvdd-supply = <&ov2732_dvdd>; + + powerdown-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpio0 8 GPIO_ACTIVE_LOW>; + + port { + camera_out: endpoint { + data-lanes = <1 2>; + link-frequencies = /bits/ 64 <360000000>; + remote-endpoint = <&mipi_in_camera>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml index fa71f24823f2..d0f577363f93 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8856.yaml @@ -18,6 +18,9 @@ description: |- through I2C and two-wire SCCB. The sensor output is available via CSI-2 serial data output (up to 4-lane). +allOf: + - $ref: /schemas/media/video-interface-devices.yaml# + properties: compatible: const: ovti,ov8856 @@ -57,6 +60,9 @@ properties: This corresponds to the hardware pin XSHUTDOWN which is physically active low. + orientation: true + rotation: true + port: $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml new file mode 100644 index 000000000000..6050d7e7dcfe --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml @@ -0,0 +1,111 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/sony,imx355.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sony IMX355 Sensor + +maintainers: + - Richard Acayan <mailingradian@gmail.com> + +description: + The IMX355 sensor is a 3280x2464 image sensor, commonly found as the front + camera in smartphones. + +allOf: + - $ref: /schemas/media/video-interface-devices.yaml# + +properties: + compatible: + const: sony,imx355 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + avdd-supply: + description: Analog power supply. + + dvdd-supply: + description: Digital power supply. + + dovdd-supply: + description: Interface power supply. + + reset-gpios: + description: Reset GPIO (active low). + maxItems: 1 + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 4 + maxItems: 4 + + required: + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - avdd-supply + - dvdd-supply + - dovdd-supply + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,camcc-sdm845.h> + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + camera@1a { + compatible = "sony,imx355"; + reg = <0x1a>; + + clocks = <&camcc CAM_CC_MCLK2_CLK>; + + assigned-clocks = <&camcc CAM_CC_MCLK2_CLK>; + assigned-clock-rates = <24000000>; + + reset-gpios = <&tlmm 9 GPIO_ACTIVE_LOW>; + + avdd-supply = <&cam_front_ldo>; + dvdd-supply = <&cam_front_ldo>; + dovdd-supply = <&cam_vio_ldo>; + + pinctrl-names = "default"; + pinctrl-0 = <&cam_front_default>; + + rotation = <270>; + orientation = <0>; + + port { + cam_front_endpoint: endpoint { + data-lanes = <1 2 3 4>; + link-frequencies = /bits/ 64 <360000000>; + remote-endpoint = <&camss_endpoint1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml index 0539d52de422..8e2b82d6dc81 100644 --- a/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ti,ds90ub960.yaml @@ -13,12 +13,10 @@ description: The TI DS90UB9XX devices are FPD-Link video deserializers with I2C and GPIO forwarding. -allOf: - - $ref: /schemas/i2c/i2c-atr.yaml# - properties: compatible: enum: + - ti,ds90ub954-q1 - ti,ds90ub960-q1 - ti,ds90ub9702-q1 @@ -125,116 +123,127 @@ properties: ports: $ref: /schemas/graph.yaml#/properties/ports + description: + Ports represent FPD-Link inputs to the deserializer and CSI TX outputs + from the deserializer. The number of ports is model-dependent. - properties: - port@0: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: FPD-Link input 0 - - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - description: - Endpoint for FPD-Link port. If the RX mode for this port is RAW, - hsync-active and vsync-active must be defined. - - port@1: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: FPD-Link input 1 - - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - description: - Endpoint for FPD-Link port. If the RX mode for this port is RAW, - hsync-active and vsync-active must be defined. - - port@2: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: FPD-Link input 2 +required: + - compatible + - reg + - clocks + - clock-names + - ports - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - description: - Endpoint for FPD-Link port. If the RX mode for this port is RAW, - hsync-active and vsync-active must be defined. +$defs: + FPDLink-input-port: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: FPD-Link input - port@3: - $ref: /schemas/graph.yaml#/$defs/port-base + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# unevaluatedProperties: false - description: FPD-Link input 3 + description: + Endpoint for FPD-Link port. If the RX mode for this port is RAW, + hsync-active and vsync-active must be defined. - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - description: - Endpoint for FPD-Link port. If the RX mode for this port is RAW, - hsync-active and vsync-active must be defined. + CSI2-output-port: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: CSI-2 Output - port@4: - $ref: /schemas/graph.yaml#/$defs/port-base + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# unevaluatedProperties: false - description: CSI-2 Output 0 properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - - properties: - data-lanes: - minItems: 1 - maxItems: 4 - link-frequencies: - maxItems: 1 - - required: - - data-lanes - - link-frequencies - - port@5: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: CSI-2 Output 1 + data-lanes: + minItems: 1 + maxItems: 4 + link-frequencies: + maxItems: 1 - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - unevaluatedProperties: false - - properties: - data-lanes: - minItems: 1 - maxItems: 4 - link-frequencies: - maxItems: 1 - - required: - - data-lanes - - link-frequencies - - required: - - port@0 - - port@1 - - port@2 - - port@3 - - port@4 - - port@5 + required: + - data-lanes + - link-frequencies -required: - - compatible - - reg - - clocks - - clock-names - - ports +allOf: + - $ref: /schemas/i2c/i2c-atr.yaml# + - if: + properties: + compatible: + contains: + enum: + - ti,ds90ub960-q1 + - ti,ds90ub9702-q1 + then: + properties: + ports: + properties: + port@0: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 0 + + port@1: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 1 + + port@2: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 2 + + port@3: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 3 + + port@4: + $ref: '#/$defs/CSI2-output-port' + description: CSI-2 Output 0 + + port@5: + $ref: '#/$defs/CSI2-output-port' + description: CSI-2 Output 1 + + required: + - port@0 + - port@1 + - port@2 + - port@3 + - port@4 + - port@5 + + - if: + properties: + compatible: + contains: + const: ti,ds90ub954-q1 + then: + properties: + ports: + properties: + port@0: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 0 + + port@1: + $ref: '#/$defs/FPDLink-input-port' + description: FPD-Link input 1 + + port@2: + $ref: '#/$defs/CSI2-output-port' + description: CSI-2 Output 0 + + required: + - port@0 + - port@1 + - port@2 + + links: + properties: + link@2: false + link@3: false unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml index 001a0d9b71e0..b59c4ce30b8b 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml @@ -24,6 +24,7 @@ properties: - fsl,imx8ulp-isi - fsl,imx91-isi - fsl,imx93-isi + - fsl,imx95-isi reg: maxItems: 1 @@ -50,7 +51,7 @@ properties: interrupts: description: Processing pipeline interrupts, one per pipeline minItems: 1 - maxItems: 2 + maxItems: 8 power-domains: maxItems: 1 @@ -99,6 +100,7 @@ allOf: then: properties: interrupts: + minItems: 2 maxItems: 2 ports: properties: @@ -120,6 +122,29 @@ allOf: required: - fsl,blk-ctrl + - if: + properties: + compatible: + contains: + const: fsl,imx95-isi + then: + properties: + interrupts: + minItems: 8 + ports: + properties: + port@0: + description: Pixel Link Slave 0 + port@1: + description: Pixel Link Slave 1 + port@2: + description: MIPI CSI-2 RX 0 + port@3: + description: MIPI CSI-2 RX 1 + required: + - port@2 + - port@3 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml index 3389bab266a9..4fcfc4fd3565 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml @@ -20,6 +20,7 @@ properties: - enum: - fsl,imx8mq-mipi-csi2 - fsl,imx8qxp-mipi-csi2 + - fsl,imx8ulp-mipi-csi2 - items: - const: fsl,imx8qm-mipi-csi2 - const: fsl,imx8qxp-mipi-csi2 @@ -39,12 +40,16 @@ properties: clock that the RX DPHY receives. - description: ui is the pixel clock (phy_ref up to 333Mhz). See the reference manual for details. + - description: pclk is clock for csr APB interface. + minItems: 3 clock-names: items: - const: core - const: esc - const: ui + - const: pclk + minItems: 3 power-domains: maxItems: 1 @@ -130,21 +135,53 @@ allOf: compatible: contains: enum: - - fsl,imx8qxp-mipi-csi2 + - fsl,imx8mq-mipi-csi2 + then: + properties: + reg: + maxItems: 1 + resets: + minItems: 3 + clocks: + maxItems: 3 + clock-names: + maxItems: 3 + required: + - fsl,mipi-phy-gpr + + - if: + properties: + compatible: + contains: + const: fsl,imx8qxp-mipi-csi2 then: properties: reg: minItems: 2 resets: maxItems: 1 - else: + clocks: + maxItems: 3 + clock-names: + maxItems: 3 + + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8ulp-mipi-csi2 + then: properties: reg: - maxItems: 1 + minItems: 2 resets: - minItems: 3 - required: - - fsl,mipi-phy-gpr + minItems: 2 + maxItems: 2 + clocks: + minItems: 4 + clock-names: + minItems: 4 additionalProperties: false diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml index 3f3ee82fc878..7e6dc410c2d2 100644 --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml @@ -42,7 +42,7 @@ properties: - const: vcodec0_bus iommus: - maxItems: 5 + maxItems: 2 interconnects: maxItems: 2 @@ -102,10 +102,7 @@ examples: memory-region = <&pil_video_mem>; iommus = <&apps_smmu 0x860 0x0>, - <&apps_smmu 0x880 0x0>, - <&apps_smmu 0x861 0x04>, - <&apps_smmu 0x863 0x0>, - <&apps_smmu 0x804 0xe0>; + <&apps_smmu 0x880 0x0>; interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>, diff --git a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml index 46cc7fff1599..084b65740d53 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml @@ -124,7 +124,6 @@ properties: maxItems: 4 required: - - clock-lanes - data-lanes port@1: @@ -147,7 +146,6 @@ properties: maxItems: 4 required: - - clock-lanes - data-lanes port@2: @@ -170,7 +168,6 @@ properties: maxItems: 4 required: - - clock-lanes - data-lanes required: diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml index 2c2bd87582eb..4ac4a3b6f406 100644 --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml @@ -17,6 +17,7 @@ description: properties: compatible: enum: + - fsl,imx93-mipi-csi2 - rockchip,rk3568-mipi-csi2 reg: @@ -26,14 +27,23 @@ properties: items: - description: Interrupt that signals changes in CSI2HOST_ERR1. - description: Interrupt that signals changes in CSI2HOST_ERR2. + minItems: 1 interrupt-names: items: - const: err1 - const: err2 + minItems: 1 clocks: - maxItems: 1 + minItems: 1 + maxItems: 2 + + clock-names: + items: + - const: per + - const: pixel + minItems: 1 phys: maxItems: 1 @@ -88,10 +98,43 @@ required: - phys - ports - power-domains - - resets additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3568-mipi-csi2 + then: + properties: + interrupts: + minItems: 2 + interrupt-names: + minItems: 2 + clocks: + maxItems: 1 + clock-names: + maxItems: 1 + required: + - resets + + - if: + properties: + compatible: + contains: + const: fsl,imx93-mipi-csi2 + then: + properties: + interrupts: + maxItems: 1 + interrupt-names: false + clocks: + minItems: 2 + clock-names: + minItems: 2 + examples: - | #include <dt-bindings/clock/rk3568-cru.h> diff --git a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml index 809fda45b3bd..42022401d0ff 100644 --- a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml @@ -28,16 +28,20 @@ properties: reg: minItems: 1 - items: - - description: The function configuration registers base - - description: The link table configuration registers base - - description: The cache configuration registers base + maxItems: 3 reg-names: - items: - - const: function - - const: link - - const: cache + oneOf: + - items: + - const: link + - const: function + - const: cache + - items: + - const: function + - const: link + - const: cache + deprecated: true + description: Use link,function,cache block order instead. interrupts: maxItems: 1 @@ -123,6 +127,8 @@ allOf: minItems: 5 reset-names: minItems: 5 + required: + - reg-names else: properties: reg: diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml index 34147127192f..d9fbb90b0977 100644 --- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml @@ -27,11 +27,14 @@ properties: - const: mclk dmas: - maxItems: 1 + minItems: 1 + maxItems: 2 dma-names: items: - const: tx + - const: mdma_tx + minItems: 1 resets: maxItems: 1 @@ -40,6 +43,15 @@ properties: minItems: 1 maxItems: 2 + power-domains: + maxItems: 1 + + sram: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to a reserved SRAM region which is used as temporary + storage memory between DMA and MDMA engines. + port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml b/Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml deleted file mode 100644 index c66586d90fa2..000000000000 --- a/Documentation/devicetree/bindings/media/starfive,jh7110-camss.yaml +++ /dev/null @@ -1,180 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/media/starfive,jh7110-camss.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Starfive SoC CAMSS ISP - -maintainers: - - Jack Zhu <jack.zhu@starfivetech.com> - - Changhuang Liang <changhuang.liang@starfivetech.com> - -description: - The Starfive CAMSS ISP is a Camera interface for Starfive JH7110 SoC. It - consists of a VIN controller (Video In Controller, a top-level control unit) - and an ISP. - -properties: - compatible: - const: starfive,jh7110-camss - - reg: - maxItems: 2 - - reg-names: - items: - - const: syscon - - const: isp - - clocks: - maxItems: 7 - - clock-names: - items: - - const: apb_func - - const: wrapper_clk_c - - const: dvp_inv - - const: axiwr - - const: mipi_rx0_pxl - - const: ispcore_2x - - const: isp_axi - - resets: - maxItems: 6 - - reset-names: - items: - - const: wrapper_p - - const: wrapper_c - - const: axird - - const: axiwr - - const: isp_top_n - - const: isp_top_axi - - power-domains: - items: - - description: JH7110 ISP Power Domain Switch Controller. - - interrupts: - maxItems: 4 - - ports: - $ref: /schemas/graph.yaml#/properties/ports - - properties: - port@0: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: Input port for receiving DVP data. - - properties: - endpoint: - $ref: video-interfaces.yaml# - unevaluatedProperties: false - - properties: - bus-type: - enum: [5, 6] - - bus-width: - enum: [8, 10, 12] - - data-shift: - enum: [0, 2] - default: 0 - - hsync-active: - enum: [0, 1] - default: 1 - - vsync-active: - enum: [0, 1] - default: 1 - - required: - - bus-type - - bus-width - - port@1: - $ref: /schemas/graph.yaml#/properties/port - description: Input port for receiving CSI data. - - required: - - port@0 - - port@1 - -required: - - compatible - - reg - - reg-names - - clocks - - clock-names - - resets - - reset-names - - power-domains - - interrupts - - ports - -additionalProperties: false - -examples: - - | - isp@19840000 { - compatible = "starfive,jh7110-camss"; - reg = <0x19840000 0x10000>, - <0x19870000 0x30000>; - reg-names = "syscon", "isp"; - clocks = <&ispcrg 0>, - <&ispcrg 13>, - <&ispcrg 2>, - <&ispcrg 12>, - <&ispcrg 1>, - <&syscrg 51>, - <&syscrg 52>; - clock-names = "apb_func", - "wrapper_clk_c", - "dvp_inv", - "axiwr", - "mipi_rx0_pxl", - "ispcore_2x", - "isp_axi"; - resets = <&ispcrg 0>, - <&ispcrg 1>, - <&ispcrg 10>, - <&ispcrg 11>, - <&syscrg 41>, - <&syscrg 42>; - reset-names = "wrapper_p", - "wrapper_c", - "axird", - "axiwr", - "isp_top_n", - "isp_top_axi"; - power-domains = <&pwrc 5>; - interrupts = <92>, <87>, <88>, <90>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - vin_from_sc2235: endpoint { - remote-endpoint = <&sc2235_to_vin>; - bus-type = <5>; - bus-width = <8>; - data-shift = <2>; - hsync-active = <1>; - vsync-active = <0>; - pclk-sample = <1>; - }; - }; - - port@1 { - reg = <1>; - vin_from_csi2rx: endpoint { - remote-endpoint = <&csi2rx_to_vin>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml index 4e4fb4acd7f9..7a653a011f03 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml @@ -52,6 +52,9 @@ properties: Should contain freqs and voltages and opp-supported-hw property, which is a bitfield indicating SoC speedo ID mask. +allOf: + - $ref: /schemas/thermal/thermal-cooling-devices.yaml + required: - compatible - reg @@ -59,7 +62,7 @@ required: - clock-names - nvidia,memory-controller -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -90,4 +93,5 @@ examples: operating-points-v2 = <&dvfs_opp_table>; #interconnect-cells = <0>; + #cooling-cells = <2>; }; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-mc.yaml new file mode 100644 index 000000000000..268d5ff958f9 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-mc.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra210-mc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra210 SoC Memory Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: | + The NVIDIA Tegra210 SoC features a 64 bit memory controller that is split + into two 32 bit channels to support LPDDR3 and LPDDR4 with x16 subpartitions. + The MC handles memory requests for 34-bit virtual addresses from internal + clients and arbitrates among them to allocate memory bandwidth. + + Up to 8 GiB of physical memory can be supported. Security features such as + encryption of traffic to and from DRAM via general security apertures are + available for video and other secure applications. + +properties: + $nodename: + pattern: "^memory-controller@[0-9a-f]+$" + + compatible: + items: + - enum: + - nvidia,tegra210-mc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: module clock + + clock-names: + items: + - const: mc + + "#iommu-cells": + const: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - "#iommu-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra210-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + memory-controller@70019000 { + compatible = "nvidia,tegra210-mc"; + reg = <0x70019000 0x1000>; + interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA210_CLK_MC>; + clock-names = "mc"; + + #iommu-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/mfd/fsl,imx25-tsadc.yaml b/Documentation/devicetree/bindings/mfd/fsl,imx25-tsadc.yaml new file mode 100644 index 000000000000..b5c6a2d47501 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/fsl,imx25-tsadc.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/fsl,imx25-tsadc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MX25 ADC/TSC MultiFunction Device (MFD) + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +description: + This device combines two general purpose conversion queues one used for general + ADC and the other used for touchscreens. + +properties: + compatible: + const: fsl,imx25-tsadc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ipg + + interrupt-controller: true + + '#interrupt-cells': + const: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + ranges: true + +patternProperties: + '^touchscreen@[0-9a-f]+$': + type: object + $ref: /schemas/input/touchscreen/fsl,imx25-tcq.yaml + unevaluatedProperties: false + + '^adc@[0-9a-f]+$': + type: object + $ref: /schemas/iio/adc/fsl,imx25-gcq.yaml + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - '#interrupt-cells' + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + tscadc@50030000 { + compatible = "fsl,imx25-tsadc"; + reg = <0x50030000 0xc>; + interrupts = <46>; + clocks = <&clks 119>; + clock-names = "ipg"; + interrupt-controller; + #interrupt-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + touchscreen@50030400 { + compatible = "fsl,imx25-tcq"; + reg = <0x50030400 0x60>; + interrupts = <0>; + fsl,wires = <4>; + }; + + adc@50030800 { + compatible = "fsl,imx25-gcq"; + reg = <0x50030800 0x60>; + interrupts = <1>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt deleted file mode 100644 index b03505286997..000000000000 --- a/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt +++ /dev/null @@ -1,47 +0,0 @@ -Freescale MX25 ADC/TSC MultiFunction Device (MFD) - -This device combines two general purpose conversion queues one used for general -ADC and the other used for touchscreens. - -Required properties: - - compatible: Should be "fsl,imx25-tsadc". - - reg: Start address and size of the memory area of - the device - - interrupts: Interrupt for this device - (See: ../interrupt-controller/interrupts.txt) - - clocks: An 'ipg' clock (See: ../clock/clock-bindings.txt) - - interrupt-controller: This device is an interrupt controller. It - controls the interrupts of both - conversion queues. - - #interrupt-cells: Should be '<1>'. - - #address-cells: Should be '<1>'. - - #size-cells: Should be '<1>'. - -This device includes two conversion queues which can be added as subnodes. -The first queue is for the touchscreen, the second for general purpose ADC. - -Example: - tscadc: tscadc@50030000 { - compatible = "fsl,imx25-tsadc"; - reg = <0x50030000 0xc>; - interrupts = <46>; - clocks = <&clks 119>; - clock-names = "ipg"; - interrupt-controller; - #interrupt-cells = <1>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - tsc: tcq@50030400 { - compatible = "fsl,imx25-tcq"; - reg = <0x50030400 0x60>; - ... - }; - - adc: gcq@50030800 { - compatible = "fsl,imx25-gcq"; - reg = <0x50030800 0x60>; - ... - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt deleted file mode 100644 index 5a642a51d58e..000000000000 --- a/Documentation/devicetree/bindings/mfd/max77620.txt +++ /dev/null @@ -1,162 +0,0 @@ -MAX77620 Power management IC from Maxim Semiconductor. - -Required properties: -------------------- -- compatible: Must be one of - "maxim,max77620" - "maxim,max20024" - "maxim,max77663" -- reg: I2C device address. - -Optional properties: -------------------- -- interrupts: The interrupt on the parent the controller is - connected to. -- interrupt-controller: Marks the device node as an interrupt controller. -- #interrupt-cells: is <2> and their usage is compliant to the 2 cells - variant of <../interrupt-controller/interrupts.txt> - IRQ numbers for different interrupt source of MAX77620 - are defined at dt-bindings/mfd/max77620.h. - -- system-power-controller: Indicates that this PMIC is controlling the - system power, see [1] for more details. - -[1] Documentation/devicetree/bindings/power/power-controller.txt - -Optional subnodes and their properties: -======================================= - -Flexible power sequence configurations: --------------------------------------- -The Flexible Power Sequencer (FPS) allows each regulator to power up under -hardware or software control. Additionally, each regulator can power on -independently or among a group of other regulators with an adjustable power-up -and power-down delays (sequencing). GPIO1, GPIO2, and GPIO3 can be programmed -to be part of a sequence allowing external regulators to be sequenced along -with internal regulators. 32KHz clock can be programmed to be part of a -sequence. - -The flexible sequencing structure consists of two hardware enable inputs -(EN0, EN1), and 3 master sequencing timers called FPS0, FPS1 and FPS2. -Each master sequencing timer is programmable through its configuration -register to have a hardware enable source (EN1 or EN2) or a software enable -source (SW). When enabled/disabled, the master sequencing timer generates -eight sequencing events on different time periods called slots. The time -period between each event is programmable within the configuration register. -Each regulator, GPIO1, GPIO2, GPIO3, and 32KHz clock has a flexible power -sequence slave register which allows its enable source to be specified as -a flexible power sequencer timer or a software bit. When a FPS source of -regulators, GPIOs and clocks specifies the enable source to be a flexible -power sequencer, the power up and power down delays can be specified in -the regulators, GPIOs and clocks flexible power sequencer configuration -registers. - -When FPS event cleared (set to LOW), regulators, GPIOs and 32KHz -clock are set into following state at the sequencing event that -corresponds to its flexible sequencer configuration register. - Sleep state: In this state, regulators, GPIOs - and 32KHz clock get disabled at - the sequencing event. - Global Low Power Mode (GLPM): In this state, regulators are set in - low power mode at the sequencing event. - -The configuration parameters of FPS is provided through sub-node "fps" -and their child for FPS specific. The child node name for FPS are "fps0", -"fps1", and "fps2" for FPS0, FPS1 and FPS2 respectively. - -The FPS configurations like FPS source, power up and power down slots for -regulators, GPIOs and 32kHz clocks are provided in their respective -configuration nodes which is explained in respective sub-system DT -binding document. - -There is need for different FPS configuration parameters based on system -state like when system state changed from active to suspend or active to -power off (shutdown). - -Optional properties: -------------------- --maxim,fps-event-source: u32, FPS event source like external - hardware input to PMIC i.e. EN0, EN1 or - software (SW). - The macros are defined on - dt-bindings/mfd/max77620.h - for different control source. - - MAX77620_FPS_EVENT_SRC_EN0 - for hardware input pin EN0. - - MAX77620_FPS_EVENT_SRC_EN1 - for hardware input pin EN1. - - MAX77620_FPS_EVENT_SRC_SW - for software control. - --maxim,shutdown-fps-time-period-us: u32, FPS time period in microseconds - when system enters in to shutdown - state. - --maxim,suspend-fps-time-period-us: u32, FPS time period in microseconds - when system enters in to suspend state. - --maxim,device-state-on-disabled-event: u32, describe the PMIC state when FPS - event cleared (set to LOW) whether it - should go to sleep state or low-power - state. Following are valid values: - - MAX77620_FPS_INACTIVE_STATE_SLEEP - to set the PMIC state to sleep. - - MAX77620_FPS_INACTIVE_STATE_LOW_POWER - to set the PMIC state to low - power. - Absence of this property or other value - will not change device state when FPS - event get cleared. - -Here supported time periods by device in microseconds are as follows: -MAX77620 supports 40, 80, 160, 320, 640, 1280, 2560 and 5120 microseconds. -MAX20024 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds. -MAX77663 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds. - --maxim,power-ok-control: configure map power ok bit - 1: Enables POK(Power OK) to control nRST_IO and GPIO1 - POK function. - 0: Disables POK control. - if property missing, do not configure MPOK bit. - If POK mapping is enabled for GPIO1/nRST_IO then, - GPIO1/nRST_IO pins are HIGH only if all rails - that have POK control enabled are HIGH. - If any of the rails goes down(which are enabled for POK - control) then, GPIO1/nRST_IO goes LOW. - this property is valid for max20024 only. - -For DT binding details of different sub modules like GPIO, pincontrol, -regulator, power, please refer respective device-tree binding document -under their respective sub-system directories. - -Example: --------- -#include <dt-bindings/mfd/max77620.h> - -max77620@3c { - compatible = "maxim,max77620"; - reg = <0x3c>; - - interrupt-parent = <&intc>; - interrupts = <0 86 IRQ_TYPE_NONE>; - - interrupt-controller; - #interrupt-cells = <2>; - - fps { - fps0 { - maxim,shutdown-fps-time-period-us = <1280>; - maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN1>; - }; - - fps1 { - maxim,shutdown-fps-time-period-us = <1280>; - maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN0>; - }; - - fps2 { - maxim,shutdown-fps-time-period-us = <1280>; - maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_SW>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml new file mode 100644 index 000000000000..602711865274 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml @@ -0,0 +1,444 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77620.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MAX77620 Power management IC from Maxim Semiconductor + +maintainers: + - Svyatoslav Ryhel <clamor95@gmail.com> + +properties: + compatible: + enum: + - maxim,max20024 + - maxim,max77620 + - maxim,max77663 + + reg: + description: + Can contain an optional second I2C address pointing to the PMIC's + RTC device. If no RTC address is provided, a default address specific + to this PMIC will be used. + minItems: 1 + maxItems: 2 + + reg-names: + items: + - const: pmic + - const: rtc + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: + Device has 8 GPIO pins which can be configured as GPIO as well as + the special IO functions. The first cell is the pin number, and the + second cell is used to specify the gpio polarity (GPIO_ACTIVE_HIGH or + GPIO_ACTIVE_LOW). + + system-power-controller: true + + "#thermal-sensor-cells": + const: 0 + description: + Maxim Semiconductor MAX77620 supports alarm interrupts when its + die temperature crosses 120C and 140C. These threshold temperatures + are not configurable. Device does not provide the real temperature + of die other than just indicating whether temperature is above or + below threshold level. + + fps: + type: object + additionalProperties: false + description: | + The Flexible Power Sequencer (FPS) allows each regulator to power up + under hardware or software control. Additionally, each regulator can + power on independently or among a group of other regulators with an + adjustable power-up and power-down delays (sequencing). GPIO1, GPIO2, + and GPIO3 can be programmed to be part of a sequence allowing external + regulators to be sequenced along with internal regulators. 32KHz clock + can be programmed to be part of a sequence. + + The flexible sequencing structure consists of two hardware enable inputs + (EN0, EN1), and 3 master sequencing timers called FPS0, FPS1 and FPS2. + Each master sequencing timer is programmable through its configuration + register to have a hardware enable source (EN1 or EN2) or a software enable + source (SW). When enabled/disabled, the master sequencing timer generates + eight sequencing events on different time periods called slots. The time + period between each event is programmable within the configuration register. + Each regulator, GPIO1, GPIO2, GPIO3, and 32KHz clock has a flexible power + sequence slave register which allows its enable source to be specified as + a flexible power sequencer timer or a software bit. When a FPS source of + regulators, GPIOs and clocks specifies the enable source to be a flexible + power sequencer, the power up and power down delays can be specified in + the regulators, GPIOs and clocks flexible power sequencer configuration + registers. + + When FPS event cleared (set to LOW), regulators, GPIOs and 32KHz clock + are set into following state at the sequencing event that corresponds + to its flexible sequencer configuration register. + + Sleep state: In this state, regulators, GPIOs and 32KHz clock get disabled + at the sequencing event. + Global Low Power Mode (GLPM): In this state, regulators are set in low + power mode at the sequencing event. + + The configuration parameters of FPS is provided through sub-node "fps" + and their child for FPS specific. The child node name for FPS are "fps0", + "fps1", and "fps2" for FPS0, FPS1 and FPS2 respectively. + + The FPS configurations like FPS source, power up and power down slots for + regulators, GPIOs and 32kHz clocks are provided in their respective + configuration nodes which is explained in respective sub-system DT + binding document. + + There is need for different FPS configuration parameters based on system + state like when system state changed from active to suspend or active to + power off (shutdown). + + patternProperties: + "^fps[0-2]$": + type: object + additionalProperties: false + + properties: + maxim,fps-event-source: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + FPS event source like external hardware input to PMIC i.e. EN0, EN1 + or software (SW). + + The macros are defined on dt-bindings/mfd/max77620.h for different + control source. + - MAX77620_FPS_EVENT_SRC_EN0 for hardware input pin EN0. + - MAX77620_FPS_EVENT_SRC_EN1 for hardware input pin EN1. + - MAX77620_FPS_EVENT_SRC_SW for software control. + + maxim,shutdown-fps-time-period-us: + description: + FPS time period in microseconds when system enters in to shutdown state. + + maxim,suspend-fps-time-period-us: + description: + FPS time period in microseconds when system enters in to suspend state. + + maxim,device-state-on-disabled-event: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Describe the PMIC state when FPS event cleared (set to LOW) whether it + should go to sleep state or low-power state. Following are valid values: + - MAX77620_FPS_INACTIVE_STATE_SLEEP to set the PMIC state to sleep. + - MAX77620_FPS_INACTIVE_STATE_LOW_POWER to set the PMIC state to low + power. + Absence of this property or other value will not change device state + when FPS event get cleared. + + maxim,power-ok-control: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Configure map power ok bit + + 1: Enables POK(Power OK) to control nRST_IO and GPIO1 POK function. + 0: Disables POK control. + + If property missing, do not configure MPOK bit. If POK mapping is + enabled for GPIO1/nRST_IO then, GPIO1/nRST_IO pins are HIGH only if + all rails that have POK control enabled are HIGH. If any of the rails + goes down (which are enabled for POK control) then, GPIO1/nRST_IO + goes LOW. + enum: [0, 1] + + pinmux: + $ref: /schemas/pinctrl/maxim,max77620-pinctrl.yaml + + regulators: + $ref: /schemas/regulator/maxim,max77620-regulator.yaml + +allOf: + - if: + properties: + compatible: + contains: + enum: + - maxim,max20024 + - maxim,max77663 + then: + properties: + "#thermal-sensor-cells": false + fps: + patternProperties: + "^fps[0-2]$": + properties: + maxim,shutdown-fps-time-period-us: + enum: [20, 40, 80, 160, 320, 640, 1280, 2540] + maxim,suspend-fps-time-period-us: + enum: [20, 40, 80, 160, 320, 640, 1280, 2540] + maxim,power-ok-control: false + + - if: + properties: + compatible: + contains: + const: maxim,max77620 + then: + properties: + fps: + patternProperties: + "^fps[0-2]$": + properties: + maxim,shutdown-fps-time-period-us: + enum: [40, 80, 160, 320, 640, 1280, 2560, 5120] + maxim,suspend-fps-time-period-us: + enum: [40, 80, 160, 320, 640, 1280, 2560, 5120] + + - if: + properties: + compatible: + not: + contains: + const: maxim,max77663 + then: + properties: + reg-names: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/mfd/max77620.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@3c { + compatible = "maxim,max77620"; + reg = <0x3c>; + + interrupt-parent = <&gpio>; + interrupts = <86 IRQ_TYPE_LEVEL_HIGH>; + + interrupt-controller; + #interrupt-cells = <2>; + + gpio-controller; + #gpio-cells = <2>; + + #thermal-sensor-cells = <0>; + + system-power-controller; + + pinctrl-names = "default"; + pinctrl-0 = <&max77620_default>; + + max77620_default: pinmux { + gpio0 { + pins = "gpio0"; + function = "gpio"; + }; + + gpio1 { + pins = "gpio1"; + function = "fps-out"; + maxim,active-fps-source = <MAX77620_FPS_SRC_0>; + }; + + gpio2 { + pins = "gpio2"; + function = "fps-out"; + maxim,active-fps-source = <MAX77620_FPS_SRC_1>; + }; + + gpio3 { + pins = "gpio3"; + function = "gpio"; + }; + + gpio4 { + pins = "gpio4"; + function = "32k-out1"; + }; + + gpio5-6 { + pins = "gpio5", "gpio6"; + function = "gpio"; + drive-push-pull = <1>; + }; + + gpio7 { + pins = "gpio7"; + function = "gpio"; + }; + }; + + fps { + fps0 { + maxim,shutdown-fps-time-period-us = <1280>; + maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN0>; + }; + + fps1 { + maxim,shutdown-fps-time-period-us = <1280>; + maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN1>; + }; + + fps2 { + maxim,shutdown-fps-time-period-us = <1280>; + maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_SW>; + }; + }; + + regulators { + in-sd0-supply = <&vdd_5v0_vbus>; + in-sd1-supply = <&vdd_5v0_vbus>; + in-sd2-supply = <&vdd_5v0_vbus>; + in-sd3-supply = <&vdd_5v0_vbus>; + + in-ldo0-1-supply = <&vdd_1v8_vio>; + in-ldo2-supply = <&vdd_3v3_vbat>; + in-ldo3-5-supply = <&vdd_3v3_vbat>; + in-ldo4-6-supply = <&vdd_3v3_vbat>; + in-ldo7-8-supply = <&vdd_1v8_vio>; + + sd0 { + regulator-name = "vdd_cpu"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1250000>; + regulator-always-on; + regulator-boot-on; + + maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>; + }; + + sd1 { + regulator-name = "vdd_core"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + + maxim,active-fps-source = <MAX77620_FPS_SRC_1>; + }; + + vdd_1v8_vio: sd2 { + regulator-name = "vdd_1v8_gen"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + + maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>; + }; + + sd3 { + regulator-name = "vddio_ddr"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-always-on; + regulator-boot-on; + + maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>; + }; + + ldo0 { + regulator-name = "avdd_pll"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-always-on; + regulator-boot-on; + + maxim,active-fps-source = <MAX77620_FPS_SRC_1>; + }; + + ldo1 { + regulator-name = "vdd_ddr_hs"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + regulator-boot-on; + + maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>; + }; + + ldo2 { + regulator-name = "avdd_usb"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>; + }; + + ldo3 { + regulator-name = "vdd_sdmmc3"; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-always-on; + + maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>; + }; + + ldo4 { + regulator-name = "vdd_rtc"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-always-on; + regulator-boot-on; + + maxim,active-fps-source = <MAX77620_FPS_SRC_0>; + }; + + ldo5 { + regulator-name = "vdd_ddr_rx"; + regulator-min-microvolt = <2850000>; + regulator-max-microvolt = <2850000>; + regulator-always-on; + regulator-boot-on; + + maxim,active-fps-source = <MAX77620_FPS_SRC_0>; + }; + + ldo6 { + regulator-name = "avdd_osc"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + + maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>; + }; + + ldo7 { + regulator-name = "vdd_1v2_mhl"; + regulator-min-microvolt = <1050000>; + regulator-max-microvolt = <1250000>; + + maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>; + }; + + ldo8 { + regulator-name = "avdd_dsi_csi"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + + maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml index 525de9ab3c2b..42e4a84d5204 100644 --- a/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml +++ b/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml @@ -16,6 +16,9 @@ description: | The MAX77759 includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C Port Controller (TCPC), NVMEM, and a GPIO expander. +allOf: + - $ref: /schemas/power/supply/power-supply.yaml# + properties: compatible: const: maxim,max77759 @@ -37,12 +40,18 @@ properties: nvmem-0: $ref: /schemas/nvmem/maxim,max77759-nvmem.yaml + chgin-otg-regulator: + type: object + description: Provides Boost for sourcing VBUS. + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + required: - compatible - interrupts - reg -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -59,6 +68,11 @@ examples: interrupt-controller; #interrupt-cells = <2>; + power-supplies = <&maxtcpci>; + + chgin-otg-regulator { + regulator-name = "chgin-otg"; + }; gpio { compatible = "maxim,max77759-gpio"; diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml index 9f42097dfbac..b094542339e8 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml @@ -4,19 +4,19 @@ $id: http://devicetree.org/schemas/mfd/rohm,bd72720-pmic.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: ROHM BD72720 Power Management Integrated Circuit +title: ROHM BD72720 and BD73900 Power Management Integrated Circuits maintainers: - Matti Vaittinen <mazziesaccount@gmail.com> description: - BD72720 is a single-chip power management IC for battery-powered portable - devices. The BD72720 integrates 10 bucks and 11 LDOs, and a 3000 mA - switching charger. The IC also includes a Coulomb counter, a real-time - clock (RTC), GPIOs and a 32.768 kHz clock gate. + BD72720 and BD73900 are single-chip power management ICs for + battery-powered portable devices. They integrate 10 bucks and 11 LDOs, + and a 3000 mA switching charger. ICs also include a Coulomb counter, + a real-time clock (RTC), GPIOs and a 32.768 kHz clock gate. -# In addition to the properties found from the charger node, the ROHM BD72720 -# uses properties from a static battery node. Please see the: +# In addition to the properties found from the charger node, PMICs +# use properties from a static battery node. Please see the: # Documentation/devicetree/bindings/power/supply/battery.yaml # # Following properties are used @@ -48,7 +48,12 @@ description: properties: compatible: - const: rohm,bd72720 + oneOf: + - const: rohm,bd72720 + + - items: + - const: rohm,bd73900 + - const: rohm,bd72720 reg: description: @@ -84,7 +89,7 @@ properties: minimum: 10000 maximum: 50000 description: - BD72720 has a SAR ADC for measuring charging currents. External sense + PMIC has a SAR ADC for measuring charging currents. External sense resistor (RSENSE in data sheet) should be used. If some other but 30 mOhm resistor is used the resistance value should be given here in micro Ohms. @@ -100,7 +105,7 @@ properties: rohm,pin-fault_b: $ref: /schemas/types.yaml#/definitions/string description: - BD72720 has an OTP option to use fault_b-pin for different + PMIC has an OTP option to use fault_b-pin for different purposes. Set this property accordingly. OTP options are OTP0 - bi-directional FAULT_B or READY indicator depending on a 'sub option' @@ -116,7 +121,7 @@ patternProperties: "^rohm,pin-dvs[0-1]$": $ref: /schemas/types.yaml#/definitions/string description: - BD72720 has 4 different OTP options to determine the use of dvs<X>-pins. + PMIC has 4 different OTP options to determine the use of dvs<X>-pins. OTP0 - regulator RUN state control. OTP1 - GPI. OTP2 - GPO. @@ -130,7 +135,7 @@ patternProperties: "^rohm,pin-exten[0-1]$": $ref: /schemas/types.yaml#/definitions/string - description: BD72720 has an OTP option to use exten0-pin for different + description: PMIC has an OTP option to use exten0-pin for different purposes. Set this property accordingly. OTP0 - GPO OTP1 - Power sequencer output. diff --git a/Documentation/devicetree/bindings/mfd/spacemit,p1.yaml b/Documentation/devicetree/bindings/mfd/spacemit,p1.yaml index c6593ac6ef6a..c67b1c6e4e4f 100644 --- a/Documentation/devicetree/bindings/mfd/spacemit,p1.yaml +++ b/Documentation/devicetree/bindings/mfd/spacemit,p1.yaml @@ -27,8 +27,41 @@ properties: interrupts: maxItems: 1 - vin-supply: - description: Input supply phandle. + vin1-supply: + description: + Power supply for BUCK1. Required if BUCK1 is defined. + + vin2-supply: + description: + Power supply for BUCK2. Required if BUCK2 is defined. + + vin3-supply: + description: + Power supply for BUCK3. Required if BUCK3 is defined. + + vin4-supply: + description: + Power supply for BUCK4. Required if BUCK4 is defined. + + vin5-supply: + description: + Power supply for BUCK5. Required if BUCK5 is defined. + + vin6-supply: + description: + Power supply for BUCK6. Required if BUCK6 is defined. + + aldoin-supply: + description: + Power supply for ALDO1-4. Required if any are defined. + + dldoin1-supply: + description: + Power supply for DLDO1-4. Required if any are defined. + + dldoin2-supply: + description: + Power supply for DLDO5-7. Required if any are defined. regulators: type: object @@ -58,6 +91,10 @@ examples: compatible = "spacemit,p1"; reg = <0x41>; interrupts = <64>; + vin1-supply = <®_vcc_5v>; + vin5-supply = <®_vcc_5v>; + aldoin-supply = <®_vcc_5v>; + dldoin1-supply = <&buck5>; regulators { buck1 { @@ -68,6 +105,14 @@ examples: regulator-always-on; }; + buck5: buck5 { + regulator-name = "buck5"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3450000>; + regulator-ramp-delay = <5000>; + regulator-always-on; + }; + aldo1 { regulator-name = "aldo1"; regulator-min-microvolt = <500000>; diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index e57add2bacd3..e22867088063 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -61,6 +61,7 @@ select: - cirrus,ep7209-syscon2 - cirrus,ep7209-syscon3 - cnxt,cx92755-uc + - econet,en751221-chip-scu - freecom,fsg-cs2-system-controller - fsl,imx93-aonmix-ns-syscfg - fsl,imx93-wakeupmix-syscfg @@ -173,6 +174,7 @@ properties: - cirrus,ep7209-syscon2 - cirrus,ep7209-syscon3 - cnxt,cx92755-uc + - econet,en751221-chip-scu - freecom,fsg-cs2-system-controller - fsl,imx93-aonmix-ns-syscfg - fsl,imx93-wakeupmix-syscfg diff --git a/Documentation/devicetree/bindings/mips/mobileye.yaml b/Documentation/devicetree/bindings/mips/mobileye.yaml index d60744550e46..83abe268e96b 100644 --- a/Documentation/devicetree/bindings/mips/mobileye.yaml +++ b/Documentation/devicetree/bindings/mips/mobileye.yaml @@ -31,6 +31,11 @@ properties: - enum: - mobileye,eyeq6h-epm6 - const: mobileye,eyeq6h + - description: Boards with Mobileye EyeQ6Lplus SoC + items: + - enum: + - mobileye,eyeq6lplus-epm6 + - const: mobileye,eyeq6lplus additionalProperties: true diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml index 57646575a13f..976f36de2091 100644 --- a/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gx-mmc.yaml @@ -19,6 +19,10 @@ allOf: properties: compatible: oneOf: + - items: + - enum: + - amlogic,t7-mmc + - const: amlogic,meson-axg-mmc - const: amlogic,meson-axg-mmc - items: - const: amlogic,meson-gx-mmc diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml index 8e79de97b242..f343fb78e114 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml @@ -106,6 +106,9 @@ properties: description: For this device it is strongly suggested to include arasan,soc-ctl-syscon. + - items: + - const: axiado,ax3000-sdhci-5.1-emmc # Axiado AX3000 eMMC controller + - const: arasan,sdhci-5.1 reg: maxItems: 1 @@ -121,6 +124,8 @@ properties: - const: clk_ahb - const: gate + dma-coherent: true + interrupts: minItems: 1 maxItems: 2 diff --git a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml index f90fd73904a2..8d62be4355a0 100644 --- a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml +++ b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml @@ -11,7 +11,7 @@ maintainers: - Ulf Hansson <ulf.hansson@linaro.org> description: - The ARM PrimeCells MMCI PL180 and PL181 provides an interface for + The ARM PrimeCell MMCI PL180 and PL181 provides an interface for reading and writing to MultiMedia and SD cards alike. Over the years vendors have use the VHDL code from ARM to create derivative MMC/SD/SDIO host controllers with very similar characteristics. diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml index d24950ccea95..e4a9c2810893 100644 --- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml @@ -22,10 +22,15 @@ description: |+ properties: compatible: - enum: - - aspeed,ast2400-sd-controller - - aspeed,ast2500-sd-controller - - aspeed,ast2600-sd-controller + oneOf: + - enum: + - aspeed,ast2400-sd-controller + - aspeed,ast2500-sd-controller + - aspeed,ast2600-sd-controller + - items: + - const: aspeed,ast2700-sd-controller + - const: aspeed,ast2600-sd-controller + reg: maxItems: 1 description: Common configuration registers @@ -38,6 +43,9 @@ properties: maxItems: 1 description: The SD/SDIO controller clock gate + resets: + maxItems: 1 + patternProperties: "^sdhci@[0-9a-f]+$": type: object @@ -46,10 +54,15 @@ patternProperties: properties: compatible: - enum: - - aspeed,ast2400-sdhci - - aspeed,ast2500-sdhci - - aspeed,ast2600-sdhci + oneOf: + - enum: + - aspeed,ast2400-sdhci + - aspeed,ast2500-sdhci + - aspeed,ast2600-sdhci + - items: + - const: aspeed,ast2700-sdhci + - const: aspeed,ast2600-sdhci + reg: maxItems: 1 description: The SDHCI registers @@ -78,6 +91,18 @@ required: - ranges - clocks +if: + properties: + compatible: + contains: + const: aspeed,ast2700-sd-controller +then: + required: + - resets +else: + properties: + resets: false + examples: - | #include <dt-bindings/clock/aspeed-clock.h> diff --git a/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml index 2f63f2cdeb71..65bb2f66f8cf 100644 --- a/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml @@ -26,9 +26,14 @@ properties: reg: minItems: 1 + dma-coherent: true + interrupts: maxItems: 1 + iommus: + maxItems: 1 + clocks: maxItems: 1 description: diff --git a/Documentation/devicetree/bindings/mmc/bst,c1200-sdhci.yaml b/Documentation/devicetree/bindings/mmc/bst,c1200-sdhci.yaml new file mode 100644 index 000000000000..8358bb70c333 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/bst,c1200-sdhci.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/bst,c1200-sdhci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Black Sesame Technologies DWCMSHC SDHCI Controller + +maintainers: + - Ge Gordon <gordon.ge@bst.ai> + +allOf: + - $ref: sdhci-common.yaml# + +properties: + compatible: + const: bst,c1200-sdhci + + reg: + items: + - description: Core SDHCI registers + - description: CRM registers + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: core + + memory-region: + maxItems: 1 + + dma-coherent: true + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + bus { + #address-cells = <2>; + #size-cells = <2>; + + mmc@22200000 { + compatible = "bst,c1200-sdhci"; + reg = <0x0 0x22200000 0x0 0x1000>, + <0x0 0x23006000 0x0 0x1000>; + interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk_mmc>; + clock-names = "core"; + memory-region = <&mmc0_reserved>; + max-frequency = <200000000>; + bus-width = <8>; + non-removable; + dma-coherent; + }; + }; diff --git a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml index ac75d694611a..6c7317d13aa6 100644 --- a/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml @@ -134,8 +134,6 @@ allOf: items: - description: Host controller registers - description: Elba byte-lane enable register for writes - required: - - resets else: properties: reg: diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index b98a84f93277..014b049baeb6 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -35,6 +35,7 @@ properties: - fsl,imx8mm-usdhc - fsl,imxrt1050-usdhc - nxp,s32g2-usdhc + - nxp,s32n79-usdhc - items: - const: fsl,imx50-esdhc - const: fsl,imx53-esdhc diff --git a/Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml new file mode 100644 index 000000000000..296bd776488e --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/hisilicon,hi3660-dw-mshc.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/hisilicon,hi3660-dw-mshc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Hisilicon specific extensions to the Synopsys Designware Mobile Storage Host Controller + +maintainers: + - Zhangfei Gao <zhangfei.gao@linaro.org> + +description: + The Synopsys designware mobile storage host controller is used to interface + a SoC with storage medium such as eMMC or SD/MMC cards. This file documents + differences between the core Synopsys dw mshc controller properties described + by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific + extensions to the Synopsys Designware Mobile Storage Host Controller. + +allOf: + - $ref: /schemas/mmc/synopsys-dw-mshc-common.yaml# + +properties: + compatible: + oneOf: + - enum: + - hisilicon,hi3660-dw-mshc + - hisilicon,hi4511-dw-mshc + - hisilicon,hi6220-dw-mshc + - items: + - const: hisilicon,hi3670-dw-mshc + - const: hisilicon,hi3660-dw-mshc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: card interface unit clock + - description: bus interface unit clock + + clock-names: + items: + - const: ciu + - const: biu + + hisilicon,peripheral-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle of syscon used to control peripheral. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/hi3620-clock.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mmc@fcd03000 { + compatible = "hisilicon,hi4511-dw-mshc"; + reg = <0xfcd03000 0x1000>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&mmc_clock HI3620_SD_CIUCLK>, <&clock HI3620_DDRC_PER_CLK>; + clock-names = "ciu", "biu"; + vmmc-supply = <&ldo12>; + fifo-depth = <0x100>; + pinctrl-names = "default"; + pinctrl-0 = <&sd_pmx_pins &sd_cfg_func1 &sd_cfg_func2>; + bus-width = <4>; + disable-wp; + cd-gpios = <&gpio10 3 GPIO_ACTIVE_HIGH>; + cap-mmc-highspeed; + cap-sd-highspeed; + }; + + - | + #include <dt-bindings/clock/hi6220-clock.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + mmc@f723e000 { + compatible = "hisilicon,hi6220-dw-mshc"; + reg = <0x0 0xf723e000 0x0 0x1000>; + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock_sys HI6220_MMC1_CIUCLK>, + <&clock_sys HI6220_MMC1_CLK>; + clock-names = "ciu", "biu"; + bus-width = <4>; + disable-wp; + cap-sd-highspeed; + sd-uhs-sdr12; + sd-uhs-sdr25; + card-detect-delay = <200>; + hisilicon,peripheral-syscon = <&ao_ctrl>; + cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; + pinctrl-names = "default", "idle"; + pinctrl-0 = <&sd_pmx_func &sd_clk_cfg_func &sd_cfg_func>; + pinctrl-1 = <&sd_pmx_idle &sd_clk_cfg_idle &sd_cfg_idle>; + vqmmc-supply = <&ldo7>; + vmmc-supply = <&ldo10>; + }; + }; diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt deleted file mode 100644 index 36c4bea675d5..000000000000 --- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt +++ /dev/null @@ -1,73 +0,0 @@ -* Hisilicon specific extensions to the Synopsys Designware Mobile - Storage Host Controller - -Read synopsys-dw-mshc.txt for more details - -The Synopsys designware mobile storage host controller is used to interface -a SoC with storage medium such as eMMC or SD/MMC cards. This file documents -differences between the core Synopsys dw mshc controller properties described -by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific -extensions to the Synopsys Designware Mobile Storage Host Controller. - -Required Properties: - -* compatible: should be one of the following. - - "hisilicon,hi3660-dw-mshc": for controllers with hi3660 specific extensions. - - "hisilicon,hi3670-dw-mshc", "hisilicon,hi3660-dw-mshc": for controllers - with hi3670 specific extensions. - - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions. - - "hisilicon,hi6220-dw-mshc": for controllers with hi6220 specific extensions. - -Optional Properties: -- hisilicon,peripheral-syscon: phandle of syscon used to control peripheral. - -Example: - - /* for Hi3620 */ - - /* SoC portion */ - dwmmc_0: dwmmc0@fcd03000 { - compatible = "hisilicon,hi4511-dw-mshc"; - reg = <0xfcd03000 0x1000>; - interrupts = <0 16 4>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&mmc_clock HI3620_SD_CIUCLK>, <&clock HI3620_DDRC_PER_CLK>; - clock-names = "ciu", "biu"; - }; - - /* Board portion */ - dwmmc0@fcd03000 { - vmmc-supply = <&ldo12>; - fifo-depth = <0x100>; - pinctrl-names = "default"; - pinctrl-0 = <&sd_pmx_pins &sd_cfg_func1 &sd_cfg_func2>; - bus-width = <4>; - disable-wp; - cd-gpios = <&gpio10 3 0>; - cap-mmc-highspeed; - cap-sd-highspeed; - }; - - /* for Hi6220 */ - - dwmmc_1: dwmmc1@f723e000 { - compatible = "hisilicon,hi6220-dw-mshc"; - bus-width = <0x4>; - disable-wp; - cap-sd-highspeed; - sd-uhs-sdr12; - sd-uhs-sdr25; - card-detect-delay = <200>; - hisilicon,peripheral-syscon = <&ao_ctrl>; - reg = <0x0 0xf723e000 0x0 0x1000>; - interrupts = <0x0 0x49 0x4>; - clocks = <&clock_sys HI6220_MMC1_CIUCLK>, <&clock_sys HI6220_MMC1_CLK>; - clock-names = "ciu", "biu"; - cd-gpios = <&gpio1 0 1>; - pinctrl-names = "default", "idle"; - pinctrl-0 = <&sd_pmx_func &sd_clk_cfg_func &sd_cfg_func>; - pinctrl-1 = <&sd_pmx_idle &sd_clk_cfg_idle &sd_cfg_idle>; - vqmmc-supply = <&ldo7>; - vmmc-supply = <&ldo10>; - }; diff --git a/Documentation/devicetree/bindings/mmc/loongson,ls2k0500-mmc.yaml b/Documentation/devicetree/bindings/mmc/loongson,ls2k0500-mmc.yaml index c142421bc723..b3e8d3f13592 100644 --- a/Documentation/devicetree/bindings/mmc/loongson,ls2k0500-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/loongson,ls2k0500-mmc.yaml @@ -22,6 +22,7 @@ allOf: properties: compatible: enum: + - loongson,ls2k0300-mmc - loongson,ls2k0500-mmc - loongson,ls2k1000-mmc - loongson,ls2k2000-mmc diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 6dd26ad31491..eb3755bdfdf7 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -25,6 +25,7 @@ properties: - mediatek,mt8135-mmc - mediatek,mt8173-mmc - mediatek,mt8183-mmc + - mediatek,mt8189-mmc - mediatek,mt8196-mmc - mediatek,mt8516-mmc - items: @@ -192,6 +193,7 @@ allOf: - mediatek,mt8183-mmc - mediatek,mt8186-mmc - mediatek,mt8188-mmc + - mediatek,mt8189-mmc - mediatek,mt8195-mmc - mediatek,mt8196-mmc - mediatek,mt8516-mmc @@ -240,6 +242,7 @@ allOf: - mediatek,mt7986-mmc - mediatek,mt7988-mmc - mediatek,mt8183-mmc + - mediatek,mt8189-mmc - mediatek,mt8196-mmc then: properties: diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index c754ea71f51f..64fac0d11329 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -106,6 +106,11 @@ properties: iommus: maxItems: 1 + mux-states: + description: + mux controller node to route the SD/SDIO/eMMC signals from SoC to cards. + maxItems: 1 + power-domains: maxItems: 1 @@ -275,6 +280,7 @@ examples: max-frequency = <195000000>; power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; resets = <&cpg 314>; + mux-states = <&mux 0>; }; sdhi1: mmc@ee120000 { diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml index acb9fb9a92cd..4965bb518c54 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml @@ -47,6 +47,10 @@ properties: - rockchip,rv1126-dw-mshc - const: rockchip,rk3288-dw-mshc # for Rockchip RK3576 with phase tuning inside the controller + - items: + - enum: + - rockchip,rv1103b-dw-mshc + - const: rockchip,rk3576-dw-mshc - const: rockchip,rk3576-dw-mshc reg: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml index 938be8228d66..695a95e8f35d 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.yaml @@ -38,10 +38,12 @@ properties: - items: - enum: - qcom,ipq5018-sdhci + - qcom,ipq5210-sdhci - qcom,ipq5332-sdhci - qcom,ipq5424-sdhci - qcom,ipq6018-sdhci - qcom,ipq9574-sdhci + - qcom,ipq9650-sdhci - qcom,kaanapali-sdhci - qcom,milos-sdhci - qcom,qcm2290-sdhci diff --git a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml index 7e7c55dc2440..cd823a3ef213 100644 --- a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml @@ -23,6 +23,9 @@ properties: - const: sophgo,sg2044-dwcmshc - const: sophgo,sg2042-dwcmshc - enum: + - canaan,k230-emmc + - canaan,k230-sdio + - hpe,gsc-dwcmshc - rockchip,rk3568-dwcmshc - rockchip,rk3588-dwcmshc - snps,dwcmshc-sdhci @@ -50,11 +53,18 @@ properties: maxItems: 1 resets: + minItems: 4 maxItems: 5 reset-names: + minItems: 4 maxItems: 5 + canaan,usb-phy: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the Canaan K230 USB PHY node required for + k230-emmc/sdio. + rockchip,txclk-tapnum: description: Specify the number of delay for tx sampling. $ref: /schemas/types.yaml#/definitions/uint8 @@ -77,6 +87,17 @@ properties: description: Specifies the drive impedance in Ohm. enum: [33, 40, 50, 66, 100] + hpe,gxp-sysreg: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to HPE GXP SoC system register block (syscon) + - description: offset of the MSHCCS register within the syscon block + description: + Phandle to the HPE GXP SoC system register block (syscon) and + offset of the MSHCCS register used to configure clock + synchronisation for HS200 tuning. + required: - compatible - reg @@ -91,6 +112,47 @@ allOf: properties: compatible: contains: + enum: + - canaan,k230-emmc + - canaan,k230-sdio + then: + properties: + clocks: + minItems: 5 + clock-names: + items: + - const: core + - const: bus + - const: axi + - const: block + - const: timer + required: + - canaan,usb-phy + + - if: + properties: + compatible: + contains: + const: hpe,gsc-dwcmshc + + then: + properties: + clocks: + items: + - description: core clock + clock-names: + items: + - const: core + required: + - hpe,gxp-sysreg + else: + properties: + hpe,gxp-sysreg: false + + - if: + properties: + compatible: + contains: const: sophgo,sg2042-dwcmshc then: @@ -146,6 +208,7 @@ allOf: else: properties: resets: + minItems: 5 maxItems: 5 reset-names: items: diff --git a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml index 13d9382058fb..9a055d963a7f 100644 --- a/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/spacemit,sdhci.yaml @@ -14,7 +14,9 @@ allOf: properties: compatible: - const: spacemit,k1-sdhci + enum: + - spacemit,k1-sdhci + - spacemit,k3-sdhci reg: maxItems: 1 @@ -32,6 +34,16 @@ properties: - const: core - const: io + resets: + items: + - description: axi reset, connect to AXI bus, shared by all controllers + - description: sdh reset, connect to individual controller separately + + reset-names: + items: + - const: axi + - const: sdh + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml index 0badb2e978c7..adb684e3207c 100644 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml @@ -101,7 +101,7 @@ required: unevaluatedProperties: false allOf: - - $ref: nand-controller.yaml + - $ref: nand-controller-legacy.yaml - if: properties: diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml index bd8f7b683953..fbaff7d3eda8 100644 --- a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml @@ -10,22 +10,43 @@ maintainers: - Uwe Kleine-König <u.kleine-koenig@pengutronix.de> allOf: - - $ref: nand-controller.yaml + - $ref: nand-controller-legacy.yaml properties: compatible: oneOf: - - const: fsl,imx27-nand + - enum: + - fsl,imx25-nand + - fsl,imx27-nand + - fsl,imx51-nand + - fsl,imx53-nand + - items: + - enum: + - fsl,imx35-nand + - const: fsl,imx25-nand - items: - enum: - fsl,imx31-nand - const: fsl,imx27-nand reg: - maxItems: 1 + minItems: 1 + items: + - description: IP register space + - description: Nand flash internal buffer space interrupts: maxItems: 1 + clocks: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + items: + - const: rx-tx + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/mtd/nand-chip.yaml b/Documentation/devicetree/bindings/mtd/nand-chip.yaml index 609d4a4ddd80..8800d1d07266 100644 --- a/Documentation/devicetree/bindings/mtd/nand-chip.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-chip.yaml @@ -11,6 +11,7 @@ maintainers: allOf: - $ref: mtd.yaml# + - $ref: nand-property.yaml description: | This file covers the generic description of a NAND chip. It implies that the @@ -22,51 +23,6 @@ properties: description: Contains the chip-select IDs. - nand-ecc-engine: - description: | - A phandle on the hardware ECC engine if any. There are - basically three possibilities: - 1/ The ECC engine is part of the NAND controller, in this - case the phandle should reference the parent node. - 2/ The ECC engine is part of the NAND part (on-die), in this - case the phandle should reference the node itself. - 3/ The ECC engine is external, in this case the phandle should - reference the specific ECC engine node. - $ref: /schemas/types.yaml#/definitions/phandle - - nand-use-soft-ecc-engine: - description: Use a software ECC engine. - type: boolean - - nand-no-ecc-engine: - description: Do not use any ECC correction. - type: boolean - - nand-ecc-algo: - description: - Desired ECC algorithm. - $ref: /schemas/types.yaml#/definitions/string - enum: [hamming, bch, rs] - - nand-ecc-strength: - description: - Maximum number of bits that can be corrected per ECC step. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 1 - - nand-ecc-step-size: - description: - Number of data bytes covered by a single ECC step. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 1 - - secure-regions: - description: - Regions in the NAND chip which are protected using a secure element - like Trustzone. This property contains the start address and size of - the secure regions present. - $ref: /schemas/types.yaml#/definitions/uint64-matrix - required: - reg diff --git a/Documentation/devicetree/bindings/mtd/nand-controller-legacy.yaml b/Documentation/devicetree/bindings/mtd/nand-controller-legacy.yaml new file mode 100644 index 000000000000..d6e612413df1 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/nand-controller-legacy.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/nand-controller-legacy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAND Controller Common Properties + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + - Richard Weinberger <richard@nod.at> + +description: > + The NAND controller should be represented with its own DT node, and + all NAND chips attached to this controller should be defined as + children nodes of the NAND controller. This representation should be + enforced even for simple controllers supporting only one chip. + + This is only for legacy nand controller, new controller should use + nand-controller.yaml + +properties: + + "#address-cells": + const: 1 + + "#size-cells": + enum: [0, 1] + + ranges: true + + cs-gpios: + description: + Array of chip-select available to the controller. The first + entries are a 1:1 mapping of the available chip-select on the + NAND controller (even if they are not used). As many additional + chip-select as needed may follow and should be phandles of GPIO + lines. 'reg' entries of the NAND chip subnodes become indexes of + this array when this property is present. + minItems: 1 + maxItems: 8 + + partitions: + type: object + + required: + - compatible + +patternProperties: + "^nand@[a-f0-9]$": + type: object + $ref: raw-nand-chip.yaml# + + "^partition@[0-9a-f]+$": + type: object + $ref: /schemas/mtd/partitions/partition.yaml#/$defs/partition-node + deprecated: true + +allOf: + - $ref: raw-nand-property.yaml# + - $ref: nand-property.yaml# + +# This is a generic file other binding inherit from and extend +additionalProperties: true + diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index 28167c0cf271..0aa61d5fa50b 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -16,6 +16,8 @@ description: | children nodes of the NAND controller. This representation should be enforced even for simple controllers supporting only one chip. +select: false + properties: $nodename: pattern: "^nand-controller(@.*)?" diff --git a/Documentation/devicetree/bindings/mtd/nand-property.yaml b/Documentation/devicetree/bindings/mtd/nand-property.yaml new file mode 100644 index 000000000000..55488a4b1548 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/nand-property.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/nand-property.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAND Chip Common Properties + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +description: | + This file covers the generic properties of a NAND chip. It implies that the + bus interface should not be taken into account: both raw NAND devices and + SPI-NAND devices are concerned by this description. + +properties: + nand-ecc-engine: + description: | + A phandle on the hardware ECC engine if any. There are + basically three possibilities: + 1/ The ECC engine is part of the NAND controller, in this + case the phandle should reference the parent node. + 2/ The ECC engine is part of the NAND part (on-die), in this + case the phandle should reference the node itself. + 3/ The ECC engine is external, in this case the phandle should + reference the specific ECC engine node. + $ref: /schemas/types.yaml#/definitions/phandle + + nand-use-soft-ecc-engine: + description: Use a software ECC engine. + type: boolean + + nand-no-ecc-engine: + description: Do not use any ECC correction. + type: boolean + + nand-ecc-algo: + description: + Desired ECC algorithm. + $ref: /schemas/types.yaml#/definitions/string + enum: [hamming, bch, rs] + + nand-ecc-strength: + description: + Maximum number of bits that can be corrected per ECC step. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + + nand-ecc-step-size: + description: + Number of data bytes covered by a single ECC step. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + + secure-regions: + description: + Regions in the NAND chip which are protected using a secure element + like Trustzone. This property contains the start address and size of + the secure regions present. + $ref: /schemas/types.yaml#/definitions/uint64-matrix + +# This file can be referenced by more specific devices (like spi-nands) +additionalProperties: true diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml index 2397d97ecac5..eaeac2f2ea94 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml @@ -57,6 +57,15 @@ properties: user space from type: boolean + part-concat-next: + description: List of phandles to MTD partitions that need be concatenated + with the current partition. + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 16 + items: + maxItems: 1 + align: $ref: /schemas/types.yaml#/definitions/uint32 minimum: 2 @@ -180,4 +189,15 @@ examples: reg = <0x200000 0x100000>; align = <0x4000>; }; + + part0: partition@400000 { + part-concat-next = <&part1>; + label = "part0_0"; + reg = <0x400000 0x100000>; + }; + + part1: partition@800000 { + label = "part0_1"; + reg = <0x800000 0x800000>; + }; }; diff --git a/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml index 092448d7bfc5..792de3e3c6ee 100644 --- a/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml +++ b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml @@ -11,6 +11,7 @@ maintainers: allOf: - $ref: nand-chip.yaml# + - $ref: raw-nand-property.yaml# description: | The ECC strength and ECC step size properties define the user @@ -31,79 +32,6 @@ properties: description: Contains the chip-select IDs. - nand-ecc-placement: - description: - Location of the ECC bytes. This location is unknown by default - but can be explicitly set to "oob", if all ECC bytes are - known to be stored in the OOB area, or "interleaved" if ECC - bytes will be interleaved with regular data in the main area. - $ref: /schemas/types.yaml#/definitions/string - enum: [ oob, interleaved ] - deprecated: true - - nand-ecc-mode: - description: - Legacy ECC configuration mixing the ECC engine choice and - configuration. - $ref: /schemas/types.yaml#/definitions/string - enum: [none, soft, soft_bch, hw, hw_syndrome, on-die] - deprecated: true - - nand-bus-width: - description: - Bus width to the NAND chip - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [8, 16] - default: 8 - - nand-on-flash-bbt: - description: - With this property, the OS will search the device for a Bad - Block Table (BBT). If not found, it will create one, reserve - a few blocks at the end of the device to store it and update - it as the device ages. Otherwise, the out-of-band area of a - few pages of all the blocks will be scanned at boot time to - find Bad Block Markers (BBM). These markers will help to - build a volatile BBT in RAM. - $ref: /schemas/types.yaml#/definitions/flag - - nand-ecc-maximize: - description: - Whether or not the ECC strength should be maximized. The - maximum ECC strength is both controller and chip - dependent. The ECC engine has to select the ECC config - providing the best strength and taking the OOB area size - constraint into account. This is particularly useful when - only the in-band area is used by the upper layers, and you - want to make your NAND as reliable as possible. - $ref: /schemas/types.yaml#/definitions/flag - - nand-is-boot-medium: - description: - Whether or not the NAND chip is a boot medium. Drivers might - use this information to select ECC algorithms supported by - the boot ROM or similar restrictions. - $ref: /schemas/types.yaml#/definitions/flag - - nand-rb: - description: - Contains the native Ready/Busy IDs. - $ref: /schemas/types.yaml#/definitions/uint32-array - - rb-gpios: - description: - Contains one or more GPIO descriptor (the numper of descriptor - depends on the number of R/B pins exposed by the flash) for the - Ready/Busy pins. Active state refers to the NAND ready state and - should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. - - wp-gpios: - description: - Contains one GPIO descriptor for the Write Protect pin. - Active state refers to the NAND Write Protect state and should be - set to GPIOD_ACTIVE_LOW unless the signal is inverted. - maxItems: 1 - required: - reg diff --git a/Documentation/devicetree/bindings/mtd/raw-nand-property.yaml b/Documentation/devicetree/bindings/mtd/raw-nand-property.yaml new file mode 100644 index 000000000000..f853b72426c4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/raw-nand-property.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/raw-nand-property.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Raw NAND Chip Common Properties + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +description: | + The ECC strength and ECC step size properties define the user + desires in terms of correction capability of a controller. Together, + they request the ECC engine to correct {strength} bit errors per + {size} bytes for a particular raw NAND chip. + + The interpretation of these parameters is implementation-defined, so + not all implementations must support all possible + combinations. However, implementations are encouraged to further + specify the value(s) they support. + +properties: + nand-ecc-placement: + description: + Location of the ECC bytes. This location is unknown by default + but can be explicitly set to "oob", if all ECC bytes are + known to be stored in the OOB area, or "interleaved" if ECC + bytes will be interleaved with regular data in the main area. + $ref: /schemas/types.yaml#/definitions/string + enum: [ oob, interleaved ] + deprecated: true + + nand-ecc-mode: + description: + Legacy ECC configuration mixing the ECC engine choice and + configuration. + $ref: /schemas/types.yaml#/definitions/string + enum: [none, soft, soft_bch, hw, hw_syndrome, on-die] + deprecated: true + + nand-bus-width: + description: + Bus width to the NAND chip + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16] + default: 8 + + nand-on-flash-bbt: + description: + With this property, the OS will search the device for a Bad + Block Table (BBT). If not found, it will create one, reserve + a few blocks at the end of the device to store it and update + it as the device ages. Otherwise, the out-of-band area of a + few pages of all the blocks will be scanned at boot time to + find Bad Block Markers (BBM). These markers will help to + build a volatile BBT in RAM. + $ref: /schemas/types.yaml#/definitions/flag + + nand-ecc-maximize: + description: + Whether or not the ECC strength should be maximized. The + maximum ECC strength is both controller and chip + dependent. The ECC engine has to select the ECC config + providing the best strength and taking the OOB area size + constraint into account. This is particularly useful when + only the in-band area is used by the upper layers, and you + want to make your NAND as reliable as possible. + $ref: /schemas/types.yaml#/definitions/flag + + nand-is-boot-medium: + description: + Whether or not the NAND chip is a boot medium. Drivers might + use this information to select ECC algorithms supported by + the boot ROM or similar restrictions. + $ref: /schemas/types.yaml#/definitions/flag + + nand-rb: + description: + Contains the native Ready/Busy IDs. + $ref: /schemas/types.yaml#/definitions/uint32-array + + rb-gpios: + description: + Contains one or more GPIO descriptor (the numper of descriptor + depends on the number of R/B pins exposed by the flash) for the + Ready/Busy pins. Active state refers to the NAND ready state and + should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. + + wp-gpios: + description: + Contains one GPIO descriptor for the Write Protect pin. + Active state refers to the NAND Write Protect state and should be + set to GPIOD_ACTIVE_LOW unless the signal is inverted. + maxItems: 1 + +# This is a generic file other binding inherit from and extend +additionalProperties: true diff --git a/Documentation/devicetree/bindings/mux/mux-controller.yaml b/Documentation/devicetree/bindings/mux/mux-controller.yaml index 78340bbe4df6..6defb9da10f7 100644 --- a/Documentation/devicetree/bindings/mux/mux-controller.yaml +++ b/Documentation/devicetree/bindings/mux/mux-controller.yaml @@ -63,18 +63,12 @@ description: | select: anyOf: - - properties: - $nodename: - pattern: '^mux-controller' - required: - '#mux-control-cells' - required: - '#mux-state-cells' properties: - $nodename: - pattern: '^mux-controller(@.*|-([0-9]|[1-9][0-9]+))?$' - '#mux-control-cells': enum: [ 0, 1 ] diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml index 2d13638ebc6a..28e494262cd9 100644 --- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml +++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml @@ -44,6 +44,14 @@ properties: signals a pending RX interrupt. maxItems: 1 + microchip,xstbyen: + type: boolean + description: + If present, configure the INT0/GPIO0/XSTBY pin as transceiver standby + control. The pin is driven low when the controller is active and high + when it enters Sleep mode, allowing automatic standby control of an + external CAN transceiver connected to this pin. + spi-max-frequency: description: Must be half or less of "clocks" frequency. diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml index cb14c35ba996..2c8c080a3d88 100644 --- a/Documentation/devicetree/bindings/net/cdns,macb.yaml +++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml @@ -70,6 +70,14 @@ properties: - microchip,sama7d65-gem # Microchip SAMA7D65 gigabit ethernet interface - const: microchip,sama7g5-gem # Microchip SAMA7G5 gigabit ethernet interface + - items: + - const: microchip,pic64hpsc-gem # Microchip PIC64-HPSC + - const: cdns,gem + - items: + - const: microchip,pic64hx-gem # Microchip PIC64HX + - const: microchip,pic64hpsc-gem # Microchip PIC64-HPSC + - const: cdns,gem + reg: minItems: 1 items: @@ -122,10 +130,23 @@ properties: cdns,refclk-ext: type: boolean + deprecated: true + description: | + This selects if the REFCLK for RMII is provided by an external source. + For RGMII mode this selects if the 125MHz REF clock is provided by an external + source. + + This property has been replaced by cdns,refclk-source, as it only works + for devices that use an internal reference clock by default. + + cdns,refclk-source: + $ref: /schemas/types.yaml#/definitions/string + enum: + - internal + - external description: - This selects if the REFCLK for RMII is provided by an external source. - For RGMII mode this selects if the 125MHz REF clock is provided by an external - source. + Select whether or not the refclk for RGMII or RMII is provided by an + internal or external source. The default is device specific. cdns,rx-watermark: $ref: /schemas/types.yaml#/definitions/uint32 @@ -137,6 +158,12 @@ properties: that need to be filled, before the forwarding process is activated. Width of the SRAM is platform dependent, and can be 4, 8 or 16 bytes. + cdns,timer-adjust: + type: boolean + description: + Set when the hardware is operating in timer-adjust mode, where the timer + is controlled by the gem_tsu_inc_ctrl and gem_tsu_ms inputs. + '#address-cells': const: 1 @@ -186,6 +213,15 @@ allOf: properties: reg: maxItems: 1 + - if: + not: + properties: + compatible: + contains: + const: microchip,mpfs-macb + then: + properties: + cdns,timer-adjust: false - if: properties: @@ -196,6 +232,54 @@ allOf: required: - phys + - if: + properties: + compatible: + contains: + const: microchip,pic64hpsc-gem + then: + patternProperties: + "^ethernet-phy@[0-9a-f]$": false + properties: + mdio: false + + - if: + not: + properties: + compatible: + contains: + enum: + - microchip,sama7g5-gem + - microchip,sama7g5-emac + then: + properties: + cdns,refclk-source: false + + - if: + not: + properties: + compatible: + contains: + const: microchip,sama7g5-gem + then: + properties: + cdns,refclk-ext: false + + - if: + properties: + compatible: + contains: + enum: + - microchip,sama7g5-emac + then: + properties: + cdns,refclk-source: + default: external + else: + properties: + cdns,refclk-source: + default: internal + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/dsa/maxlinear,mxl862xx.yaml b/Documentation/devicetree/bindings/net/dsa/maxlinear,mxl862xx.yaml index f1d667f7a055..2f19c19c60f3 100644 --- a/Documentation/devicetree/bindings/net/dsa/maxlinear,mxl862xx.yaml +++ b/Documentation/devicetree/bindings/net/dsa/maxlinear,mxl862xx.yaml @@ -110,7 +110,6 @@ examples: port@9 { reg = <9>; - label = "cpu"; ethernet = <&gmac0>; phy-mode = "usxgmii"; diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml index 607b7fe8d28e..0486489114cd 100644 --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml @@ -143,8 +143,6 @@ allOf: else: properties: spi-cpha: false - required: - - spi-cpol unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 58634fee9fc4..21a1a63506f0 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -126,6 +126,20 @@ properties: e.g. wrong bootstrap configuration caused by issues in PCB layout design. + enet-phy-pair-order: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: + For normal (0) or reverse (1) order of the pairs (ABCD -> DCBA). + + enet-phy-pair-polarity: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 0xf + description: + A bitmap to describe pair polarity swap. Bit 0 to swap polarity of pair A, + bit 1 to swap polarity of pair B, bit 2 to swap polarity of pair C and bit + 3 to swap polarity of pair D. + eee-broken-100tx: $ref: /schemas/types.yaml#/definitions/flag description: diff --git a/Documentation/devicetree/bindings/net/micrel.yaml b/Documentation/devicetree/bindings/net/micrel.yaml index ecc00169ef80..6fa568057b92 100644 --- a/Documentation/devicetree/bindings/net/micrel.yaml +++ b/Documentation/devicetree/bindings/net/micrel.yaml @@ -51,9 +51,10 @@ properties: bits that are currently supported: KSZ8001: register 0x1e, bits 15..14 - KSZ8041: register 0x1e, bits 15..14 KSZ8021: register 0x1f, bits 5..4 KSZ8031: register 0x1f, bits 5..4 + KSZ8041: register 0x1e, bits 15..14 + KSZ8041RNLI: register 0x1e, bits 15..14 KSZ8051: register 0x1f, bits 5..4 KSZ8081: register 0x1f, bits 5..4 KSZ8091: register 0x1f, bits 5..4 @@ -80,9 +81,10 @@ allOf: contains: enum: - ethernet-phy-id0022.1510 + - ethernet-phy-id0022.1537 + - ethernet-phy-id0022.1550 - ethernet-phy-id0022.1555 - ethernet-phy-id0022.1556 - - ethernet-phy-id0022.1550 - ethernet-phy-id0022.1560 - ethernet-phy-id0022.161a then: diff --git a/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml new file mode 100644 index 000000000000..20f29b71566b --- /dev/null +++ b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/microchip,pic64hpsc-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip PIC64-HPSC/HX MDIO controller + +maintainers: + - Charles Perry <charles.perry@microchip.com> + +description: + This is the MDIO bus controller present in Microchip PIC64-HPSC/HX SoCs. It + supports C22 and C45 register access and is named "MDIO Initiator" in the + documentation. + +allOf: + - $ref: mdio.yaml# + +properties: + compatible: + oneOf: + - const: microchip,pic64hpsc-mdio + - items: + - const: microchip,pic64hx-mdio + - const: microchip,pic64hpsc-mdio + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-frequency: + default: 2500000 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + bus { + #address-cells = <2>; + #size-cells = <2>; + + mdio@4000c21e000 { + compatible = "microchip,pic64hpsc-mdio"; + reg = <0x400 0x0c21e000 0x0 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&svc_clk>; + interrupt-parent = <&saplic0>; + interrupts = <168 IRQ_TYPE_LEVEL_HIGH>; + + ethernet-phy@0 { + reg = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml b/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml index 364b36151180..4f3847f64983 100644 --- a/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml +++ b/Documentation/devicetree/bindings/net/nfc/nxp,nci.yaml @@ -18,6 +18,7 @@ properties: - nxp,nq310 - nxp,pn547 - nxp,pn553 + - nxp,pn557 - const: nxp,nxp-nci-i2c enable-gpios: diff --git a/Documentation/devicetree/bindings/net/nuvoton,ma35d1-dwmac.yaml b/Documentation/devicetree/bindings/net/nuvoton,ma35d1-dwmac.yaml new file mode 100644 index 000000000000..ab18702e53f9 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nuvoton,ma35d1-dwmac.yaml @@ -0,0 +1,140 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/nuvoton,ma35d1-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton DWMAC glue layer controller + +maintainers: + - Joey Lu <yclu4@nuvoton.com> + +description: + Nuvoton 10/100/1000Mbps Gigabit Ethernet MAC Controller is based on + Synopsys DesignWare MAC (version 3.73a). + +select: + properties: + compatible: + contains: + enum: + - nuvoton,ma35d1-dwmac + required: + - compatible + +allOf: + - $ref: snps,dwmac.yaml# + +properties: + compatible: + items: + - const: nuvoton,ma35d1-dwmac + - const: snps,dwmac-3.70a + + reg: + maxItems: 1 + description: + Register range should be one of the GMAC interface. + + interrupts: + maxItems: 1 + + clocks: + items: + - description: MAC clock + - description: PTP clock + + clock-names: + items: + - const: stmmaceth + - const: ptp_ref + + nuvoton,sys: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to access syscon registers. + - description: GMAC interface ID. + enum: + - 0 + - 1 + description: + A phandle to the syscon with one argument that configures system registers + for MA35D1's two GMACs. The argument specifies the GMAC interface ID. + + resets: + maxItems: 1 + + reset-names: + items: + - const: stmmaceth + + phy-mode: + enum: + - rmii + - rgmii + - rgmii-id + - rgmii-txid + - rgmii-rxid + + tx-internal-delay-ps: + default: 0 + minimum: 0 + maximum: 2000 + description: + RGMII TX path delay used only when PHY operates in RGMII mode with + internal delay (phy-mode is 'rgmii-id' or 'rgmii-txid') in pico-seconds. + Allowed values are from 0 to 2000. + + rx-internal-delay-ps: + default: 0 + minimum: 0 + maximum: 2000 + description: + RGMII RX path delay used only when PHY operates in RGMII mode with + internal delay (phy-mode is 'rgmii-id' or 'rgmii-rxid') in pico-seconds. + Allowed values are from 0 to 2000. + +required: + - clocks + - clock-names + - nuvoton,sys + - resets + - reset-names + - phy-mode + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h> + #include <dt-bindings/reset/nuvoton,ma35d1-reset.h> + ethernet@40120000 { + compatible = "nuvoton,ma35d1-dwmac", "snps,dwmac-3.70a"; + reg = <0x40120000 0x10000>; + interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq"; + clocks = <&clk EMAC0_GATE>, <&clk EPLL_DIV8>; + clock-names = "stmmaceth", "ptp_ref"; + + nuvoton,sys = <&sys 0>; + resets = <&sys MA35D1_RESET_GMAC0>; + reset-names = "stmmaceth"; + snps,multicast-filter-bins = <0>; + snps,perfect-filter-entries = <8>; + rx-fifo-depth = <4096>; + tx-fifo-depth = <2048>; + + phy-mode = "rgmii-id"; + phy-handle = <ð_phy0>; + mdio { + compatible = "snps,dwmac-mdio"; + #address-cells = <1>; + #size-cells = <0>; + + eth_phy0: ethernet-phy@0 { + reg = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml b/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml index 2bd3efff2485..215f14d1897d 100644 --- a/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml +++ b/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml @@ -42,7 +42,7 @@ properties: - const: mgbe - const: mac - const: mac-divider - - const: ptp-ref + - const: ptp_ref - const: rx-input-m - const: rx-input - const: tx @@ -133,7 +133,7 @@ examples: <&bpmp TEGRA234_CLK_MGBE0_RX_PCS_M>, <&bpmp TEGRA234_CLK_MGBE0_RX_PCS>, <&bpmp TEGRA234_CLK_MGBE0_TX_PCS>; - clock-names = "mgbe", "mac", "mac-divider", "ptp-ref", "rx-input-m", + clock-names = "mgbe", "mac", "mac-divider", "ptp_ref", "rx-input-m", "rx-input", "tx", "eee-pcs", "rx-pcs-input", "rx-pcs-m", "rx-pcs", "tx-pcs"; resets = <&bpmp TEGRA234_RESET_MGBE0_MAC>, diff --git a/Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml b/Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml index 1b2934f3c87c..753a04941659 100644 --- a/Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/nxp,s32-dwmac.yaml @@ -1,5 +1,5 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# Copyright 2021-2024 NXP +# Copyright 2021-2026 NXP %YAML 1.2 --- $id: http://devicetree.org/schemas/net/nxp,s32-dwmac.yaml# @@ -16,6 +16,8 @@ description: the SoC S32R45 has two instances. The devices can use RGMII/RMII/MII interface over Pinctrl device or the output can be routed to the embedded SerDes for SGMII connectivity. + The DWMAC instances have connected all RX/TX queues interrupts, + enabling load balancing of data traffic across all CPU cores. properties: compatible: @@ -45,10 +47,25 @@ properties: FlexTimer Modules connect to GMAC_0. interrupts: - maxItems: 1 + minItems: 1 + maxItems: 11 interrupt-names: - const: macirq + oneOf: + - items: + - const: macirq + - items: + - const: macirq + - const: tx-queue-0 + - const: rx-queue-0 + - const: tx-queue-1 + - const: rx-queue-1 + - const: tx-queue-2 + - const: rx-queue-2 + - const: tx-queue-3 + - const: rx-queue-3 + - const: tx-queue-4 + - const: rx-queue-4 clocks: items: @@ -88,8 +105,28 @@ examples: <0x0 0x4007c004 0x0 0x4>; /* GMAC_0_CTRL_STS */ nxp,phy-sel = <&gpr 0x4>; interrupt-parent = <&gic>; - interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "macirq"; + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>, + /* CHN 0: tx, rx */ + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>, + /* CHN 1: tx, rx */ + <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>, + /* CHN 2: tx, rx */ + <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>, + /* CHN 3: tx, rx */ + <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>, + /* CHN 4: tx, rx */ + <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq", + "tx-queue-0", "rx-queue-0", + "tx-queue-1", "rx-queue-1", + "tx-queue-2", "rx-queue-2", + "tx-queue-3", "rx-queue-3", + "tx-queue-4", "rx-queue-4"; snps,mtl-rx-config = <&mtl_rx_setup>; snps,mtl-tx-config = <&mtl_tx_setup>; clocks = <&clks 24>, <&clks 17>, <&clks 16>, <&clks 15>; diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index c7f5f2ef7452..fdeaa81b9645 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -44,6 +44,7 @@ properties: compatible: oneOf: - enum: + - qcom,milos-ipa - qcom,msm8998-ipa - qcom,sc7180-ipa - qcom,sc7280-ipa @@ -55,6 +56,10 @@ properties: - qcom,sm8550-ipa - items: - enum: + - qcom,qcm2290-ipa + - const: qcom,sc7180-ipa + - items: + - enum: - qcom,sm8650-ipa - const: qcom,sm8550-ipa @@ -165,6 +170,13 @@ properties: initializing IPA hardware. Optional, and only used when Trust Zone performs early initialization. + sram: + maxItems: 1 + description: + A reference to an additional region residing in IMEM (special + on-chip SRAM), which is accessed by the IPA firmware and needs + to be IOMMU-mapped from the OS. + required: - compatible - iommus diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml index 2b5697bd7c5d..45033c31a2d5 100644 --- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml @@ -40,15 +40,30 @@ properties: leds: true + realtek,aldps-enable: + type: boolean + description: + Enable ALDPS mode, ALDPS mode default is disabled after hardware reset. + realtek,clkout-disable: type: boolean description: Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset. - realtek,aldps-enable: + realtek,clkout-ssc-enable: type: boolean description: - Enable ALDPS mode, ALDPS mode default is disabled after hardware reset. + Enable CLKOUT SSC mode, CLKOUT SSC mode default is disabled after hardware reset. + + realtek,rxc-ssc-enable: + type: boolean + description: + Enable RXC SSC mode, RXC SSC mode default is disabled after hardware reset. + + realtek,sysclk-ssc-enable: + type: boolean + description: + Enable SYSCLK SSC mode, SYSCLK SSC mode default is disabled after hardware reset. wakeup-source: type: boolean diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 38bc34dc4f09..2449311c6d28 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -69,6 +69,7 @@ properties: - ingenic,x2000-mac - loongson,ls2k-dwmac - loongson,ls7a-dwmac + - nuvoton,ma35d1-dwmac - nxp,s32g2-dwmac - qcom,qcs404-ethqos - qcom,sa8775p-ethqos @@ -109,6 +110,7 @@ properties: - snps,dwmac-5.10a - snps,dwmac-5.20 - snps,dwmac-5.30a + - snps,dwmac-5.40a - snps,dwxgmac - snps,dwxgmac-2.10 - sophgo,sg2042-dwmac @@ -202,11 +204,8 @@ properties: * snps,xit_frm, unlock on WoL * snps,wr_osr_lmt, max write outstanding req. limit * snps,rd_osr_lmt, max read outstanding req. limit - * snps,kbbe, do not cross 1KiB boundary. * snps,blen, this is a vector of supported burst length. * snps,fb, fixed-burst - * snps,mb, mixed-burst - * snps,rb, rebuild INCRx Burst snps,mtl-rx-config: $ref: /schemas/types.yaml#/definitions/phandle @@ -586,11 +585,6 @@ properties: description: max read outstanding req. limit - snps,kbbe: - $ref: /schemas/types.yaml#/definitions/flag - description: - do not cross 1KiB boundary. - snps,blen: $ref: /schemas/types.yaml#/definitions/uint32-array description: @@ -603,16 +597,6 @@ properties: description: fixed-burst - snps,mb: - $ref: /schemas/types.yaml#/definitions/flag - description: - mixed-burst - - snps,rb: - $ref: /schemas/types.yaml#/definitions/flag - description: - rebuild INCRx Burst - required: - compatible - reg @@ -656,6 +640,7 @@ allOf: - snps,dwmac-5.10a - snps,dwmac-5.20 - snps,dwmac-5.30a + - snps,dwmac-5.40a - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac diff --git a/Documentation/devicetree/bindings/net/spacemit,k3-dwmac.yaml b/Documentation/devicetree/bindings/net/spacemit,k3-dwmac.yaml new file mode 100644 index 000000000000..678eccf044f9 --- /dev/null +++ b/Documentation/devicetree/bindings/net/spacemit,k3-dwmac.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/spacemit,k3-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Spacemit K3 DWMAC glue layer + +maintainers: + - Inochi Amaoto <inochiama@gmail.com> + +select: + properties: + compatible: + contains: + const: spacemit,k3-dwmac + required: + - compatible + +properties: + compatible: + items: + - const: spacemit,k3-dwmac + - const: snps,dwmac-5.40a + + reg: + maxItems: 1 + + clocks: + items: + - description: GMAC application clock + - description: PTP clock + - description: TX clock + + clock-names: + items: + - const: stmmaceth + - const: ptp_ref + - const: tx + + interrupts: + minItems: 1 + items: + - description: MAC interrupt + - description: MAC wake interrupt + + interrupt-names: + minItems: 1 + items: + - const: macirq + - const: eth_wake_irq + + resets: + maxItems: 1 + + reset-names: + const: stmmaceth + + spacemit,apmu: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to the syscon node which control the glue register + - description: offset of the control register + - description: offset of the dline register + description: + A phandle to syscon with offset to control registers for this MAC + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - interrupt-names + - resets + - reset-names + - spacemit,apmu + +allOf: + - $ref: snps,dwmac.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + ethernet@cac80000 { + compatible = "spacemit,k3-dwmac", "snps,dwmac-5.40a"; + reg = <0xcac80000 0x2000>; + clocks = <&syscon_apmu 66>, <&syscon_apmu 68>, + <&syscon_apmu 69>; + clock-names = "stmmaceth", "ptp_ref", "tx"; + interrupts = <131 IRQ_TYPE_LEVEL_HIGH>, <276 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq", "eth_wake_irq"; + phy-mode = "rgmii-id"; + phy-handle = <&phy0>; + resets = <&syscon_apmu 67>; + reset-names = "stmmaceth"; + spacemit,apmu = <&syscon_apmu 0x384 0x38c>; + }; 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 a959c1d7e643..c409c6310ed4 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml @@ -53,13 +53,18 @@ properties: "#size-cells": true compatible: - enum: - - ti,am642-cpsw-nuss - - ti,am654-cpsw-nuss - - ti,j7200-cpswxg-nuss - - ti,j721e-cpsw-nuss - - ti,j721e-cpswxg-nuss - - ti,j784s4-cpswxg-nuss + oneOf: + - enum: + - ti,am642-cpsw-nuss + - ti,am654-cpsw-nuss + - ti,j7200-cpswxg-nuss + - ti,j721e-cpsw-nuss + - ti,j721e-cpswxg-nuss + - ti,j784s4-cpswxg-nuss + - items: + - enum: + - ti,j722s-cpsw-nuss + - const: ti,am642-cpsw-nuss reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml index 3be757678764..81fd3e37452a 100644 --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm4329-fmac.yaml @@ -42,6 +42,7 @@ properties: - brcm,bcm4356-fmac - brcm,bcm4359-fmac - brcm,bcm4366-fmac + - brcm,bcm43752-fmac - cypress,cyw4373-fmac - cypress,cyw43012-fmac - infineon,cyw43439-fmac diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml index f2440d39b7eb..c21d66c7cd55 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml @@ -171,6 +171,12 @@ properties: Quirk specifying that the firmware expects the 8bit version of the host capability QMI request + qcom,snoc-host-cap-skip-quirk: + type: boolean + description: + Quirk specifying that the firmware wants to skip the host + capability QMI request + qcom,xo-cal-data: $ref: /schemas/types.yaml#/definitions/uint32 description: @@ -292,6 +298,11 @@ allOf: required: - interrupts + - not: + required: + - qcom,snoc-host-cap-8bit-quirk + - qcom,snoc-host-cap-skip-quirk + examples: # SNoC - | diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml index 363a0ecb6ad9..37d8a0da7780 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - qcom,ipq5332-wifi + - qcom,ipq5424-wifi reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/npu/arm,ethos.yaml b/Documentation/devicetree/bindings/npu/arm,ethos.yaml index 716c4997f976..d5a1fae4db9d 100644 --- a/Documentation/devicetree/bindings/npu/arm,ethos.yaml +++ b/Documentation/devicetree/bindings/npu/arm,ethos.yaml @@ -30,7 +30,7 @@ properties: - fsl,imx93-npu - const: arm,ethos-u65 - items: - - {} + - const: arm,corstone1000-ethos-u85 - const: arm,ethos-u85 reg: diff --git a/Documentation/devicetree/bindings/opp/opp-v2.yaml b/Documentation/devicetree/bindings/opp/opp-v2.yaml index 6972d76233aa..10000a758572 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2.yaml @@ -172,7 +172,7 @@ examples: cpu@0 { compatible = "arm,cortex-a7"; device_type = "cpu"; - reg = <0>; + reg = <0x0>; next-level-cache = <&L2>; clocks = <&clk_controller 0>; clock-names = "cpu"; @@ -183,7 +183,7 @@ examples: cpu@1 { compatible = "arm,cortex-a7"; device_type = "cpu"; - reg = <1>; + reg = <0x1>; next-level-cache = <&L2>; clocks = <&clk_controller 0>; clock-names = "cpu"; @@ -194,7 +194,7 @@ examples: cpu@100 { compatible = "arm,cortex-a15"; device_type = "cpu"; - reg = <100>; + reg = <0x100>; next-level-cache = <&L2>; clocks = <&clk_controller 1>; clock-names = "cpu"; @@ -205,7 +205,7 @@ examples: cpu@101 { compatible = "arm,cortex-a15"; device_type = "cpu"; - reg = <101>; + reg = <0x101>; next-level-cache = <&L2>; clocks = <&clk_controller 1>; clock-names = "cpu"; diff --git a/Documentation/devicetree/bindings/pci/andestech,qilai-pcie.yaml b/Documentation/devicetree/bindings/pci/andestech,qilai-pcie.yaml new file mode 100644 index 000000000000..97ba97fdc5a9 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/andestech,qilai-pcie.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/andestech,qilai-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Andes QiLai PCIe host controller + +description: + Andes QiLai PCIe host controller is based on the Synopsys DesignWare + PCI core. + +maintainers: + - Randolph Lin <randolph@andestech.com> + +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + +properties: + compatible: + const: andestech,qilai-pcie + + reg: + items: + - description: Data Bus Interface (DBI) registers. + - description: APB registers. + - description: PCIe configuration space region. + + reg-names: + items: + - const: dbi + - const: apb + - const: config + + dma-coherent: true + + ranges: + maxItems: 2 + + interrupts: + maxItems: 1 + + interrupt-names: + items: + - const: msi + +required: + - reg + - reg-names + - interrupts + - interrupt-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pcie@80000000 { + compatible = "andestech,qilai-pcie"; + device_type = "pci"; + reg = <0x0 0x80000000 0x0 0x20000000>, + <0x0 0x04000000 0x0 0x00001000>, + <0x0 0x00000000 0x0 0x00010000>; + reg-names = "dbi", "apb", "config"; + dma-coherent; + + linux,pci-domain = <0>; + #address-cells = <3>; + #size-cells = <2>; + ranges = <0x02000000 0x00 0x10000000 0x00 0x10000000 0x00 0xf0000000>, + <0x43000000 0x01 0x00000000 0x01 0x00000000 0x02 0x00000000>; + + #interrupt-cells = <1>; + interrupts = <0xf>; + interrupt-names = "msi"; + interrupt-parent = <&plic0>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 1 &plic0 0xf IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 2 &plic0 0xf IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 3 &plic0 0xf IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 4 &plic0 0xf IRQ_TYPE_LEVEL_HIGH>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml b/Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml deleted file mode 100644 index 8eaa07ae9774..000000000000 --- a/Documentation/devicetree/bindings/pci/baikal,bt1-pcie.yaml +++ /dev/null @@ -1,168 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/pci/baikal,bt1-pcie.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Baikal-T1 PCIe Root Port Controller - -maintainers: - - Serge Semin <fancer.lancer@gmail.com> - -description: - Embedded into Baikal-T1 SoC Root Complex controller with a single port - activated. It's based on the DWC RC PCIe v4.60a IP-core, which is configured - to have just a single Root Port function and is capable of establishing the - link up to Gen.3 speed on x4 lanes. It doesn't have embedded clock and reset - control module, so the proper interface initialization is supposed to be - performed by software. There four in- and four outbound iATU regions - which can be used to emit all required TLP types on the PCIe bus. - -allOf: - - $ref: /schemas/pci/snps,dw-pcie.yaml# - -properties: - compatible: - const: baikal,bt1-pcie - - reg: - description: - DBI, DBI2 and at least 4KB outbound iATU-capable region for the - peripheral devices CFG-space access. - maxItems: 3 - - reg-names: - items: - - const: dbi - - const: dbi2 - - const: config - - interrupts: - description: - MSI, AER, PME, Hot-plug, Link Bandwidth Management, Link Equalization - request and eight Read/Write eDMA IRQ lines are available. - maxItems: 14 - - interrupt-names: - items: - - const: dma0 - - const: dma1 - - const: dma2 - - const: dma3 - - const: dma4 - - const: dma5 - - const: dma6 - - const: dma7 - - const: msi - - const: aer - - const: pme - - const: hp - - const: bw_mg - - const: l_eq - - clocks: - description: - DBI (attached to the APB bus), AXI-bus master and slave interfaces - are fed up by the dedicated application clocks. A common reference - clock signal is supposed to be attached to the corresponding Ref-pad - of the SoC. It will be redistributed amongst the controller core - sub-modules (pipe, core, aux, etc). - maxItems: 4 - - clock-names: - items: - - const: dbi - - const: mstr - - const: slv - - const: ref - - resets: - description: - A comprehensive controller reset logic is supposed to be implemented - by software, so almost all the possible application and core reset - signals are exposed via the system CCU module. - maxItems: 9 - - reset-names: - items: - - const: mstr - - const: slv - - const: pwr - - const: hot - - const: phy - - const: core - - const: pipe - - const: sticky - - const: non-sticky - - baikal,bt1-syscon: - $ref: /schemas/types.yaml#/definitions/phandle - description: - Phandle to the Baikal-T1 System Controller DT node. It's required to - access some additional PM, Reset-related and LTSSM signals. - - num-lanes: - maximum: 4 - - max-link-speed: - maximum: 3 - -required: - - compatible - - reg - - reg-names - - interrupts - - interrupt-names - -unevaluatedProperties: false - -examples: - - | - #include <dt-bindings/interrupt-controller/mips-gic.h> - #include <dt-bindings/gpio/gpio.h> - - pcie@1f052000 { - compatible = "baikal,bt1-pcie"; - device_type = "pci"; - reg = <0x1f052000 0x1000>, <0x1f053000 0x1000>, <0x1bdbf000 0x1000>; - reg-names = "dbi", "dbi2", "config"; - #address-cells = <3>; - #size-cells = <2>; - ranges = <0x81000000 0 0x00000000 0x1bdb0000 0 0x00008000>, - <0x82000000 0 0x20000000 0x08000000 0 0x13db0000>; - bus-range = <0x0 0xff>; - - interrupts = <GIC_SHARED 80 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 81 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 82 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 83 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 84 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 85 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 86 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 87 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 88 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 89 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 90 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 91 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 92 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SHARED 93 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "dma0", "dma1", "dma2", "dma3", - "dma4", "dma5", "dma6", "dma7", - "msi", "aer", "pme", "hp", "bw_mg", - "l_eq"; - - clocks = <&ccu_sys 1>, <&ccu_axi 6>, <&ccu_axi 7>, <&clk_pcie>; - clock-names = "dbi", "mstr", "slv", "ref"; - - resets = <&ccu_axi 6>, <&ccu_axi 7>, <&ccu_sys 7>, <&ccu_sys 10>, - <&ccu_sys 4>, <&ccu_sys 6>, <&ccu_sys 5>, <&ccu_sys 8>, - <&ccu_sys 9>; - reset-names = "mstr", "slv", "pwr", "hot", "phy", "core", "pipe", - "sticky", "non-sticky"; - - reset-gpios = <&port0 0 GPIO_ACTIVE_LOW>; - - num-lanes = <4>; - max-link-speed = <3>; - }; -... diff --git a/Documentation/devicetree/bindings/pci/cix,sky1-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cix,sky1-pcie-host.yaml index b910a42e0843..d55d165f1e94 100644 --- a/Documentation/devicetree/bindings/pci/cix,sky1-pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/cix,sky1-pcie-host.yaml @@ -38,6 +38,9 @@ properties: ranges: maxItems: 3 + power-domains: + maxItems: 1 + required: - compatible - ranges diff --git a/Documentation/devicetree/bindings/pci/eswin,pcie.yaml b/Documentation/devicetree/bindings/pci/eswin,pcie.yaml new file mode 100644 index 000000000000..057e1f363dde --- /dev/null +++ b/Documentation/devicetree/bindings/pci/eswin,pcie.yaml @@ -0,0 +1,166 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/eswin,pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ESWIN PCIe Root Complex + +maintainers: + - Yu Ning <ningyu@eswincomputing.com> + - Senchuan Zhang <zhangsenchuan@eswincomputing.com> + - Yanghui Ou <ouyanghui@eswincomputing.com> + +description: + ESWIN SoCs PCIe Root Complex is based on the Synopsys DesignWare PCIe IP. + +properties: + compatible: + const: eswin,eic7700-pcie + + reg: + maxItems: 3 + + reg-names: + items: + - const: dbi + - const: config + - const: elbi + + ranges: + maxItems: 3 + + '#interrupt-cells': + const: 1 + + interrupt-names: + items: + - const: msi + - const: inta + - const: intb + - const: intc + - const: intd + + interrupt-map: + maxItems: 4 + + interrupt-map-mask: + items: + - const: 0 + - const: 0 + - const: 0 + - const: 7 + + clocks: + maxItems: 4 + + clock-names: + items: + - const: mstr + - const: dbi + - const: phy_reg + - const: aux + + resets: + maxItems: 2 + + reset-names: + items: + - const: dbi + - const: pwr + +patternProperties: + "^pcie@": + type: object + $ref: /schemas/pci/pci-pci-bridge.yaml# + + properties: + reg: + maxItems: 1 + + num-lanes: + maximum: 4 + + resets: + maxItems: 1 + + reset-names: + items: + - const: perst + + required: + - reg + - ranges + - num-lanes + - resets + - reset-names + + unevaluatedProperties: false + +required: + - compatible + - reg + - ranges + - interrupts + - interrupt-names + - interrupt-map-mask + - interrupt-map + - '#interrupt-cells' + - clocks + - clock-names + - resets + - reset-names + +allOf: + - $ref: /schemas/pci/snps,dw-pcie.yaml# + +unevaluatedProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + pcie@54000000 { + compatible = "eswin,eic7700-pcie"; + reg = <0x0 0x54000000 0x0 0x4000000>, + <0x0 0x40000000 0x0 0x800000>, + <0x0 0x50000000 0x0 0x100000>; + reg-names = "dbi", "config", "elbi"; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges = <0x01000000 0x0 0x40800000 0x0 0x40800000 0x0 0x800000>, + <0x02000000 0x0 0x41000000 0x0 0x41000000 0x0 0xf000000>, + <0x43000000 0x80 0x00000000 0x80 0x00000000 0x2 0x00000000>; + bus-range = <0x00 0xff>; + clocks = <&clock 144>, + <&clock 145>, + <&clock 146>, + <&clock 147>; + clock-names = "mstr", "dbi", "phy_reg", "aux"; + resets = <&reset 97>, + <&reset 98>; + reset-names = "dbi", "pwr"; + interrupts = <220>, <179>, <180>, <181>, <182>, <183>, <184>, <185>, <186>; + interrupt-names = "msi", "inta", "intb", "intc", "intd"; + interrupt-parent = <&plic>; + interrupt-map-mask = <0x0 0x0 0x0 0x7>; + interrupt-map = <0x0 0x0 0x0 0x1 &plic 179>, + <0x0 0x0 0x0 0x2 &plic 180>, + <0x0 0x0 0x0 0x3 &plic 181>, + <0x0 0x0 0x0 0x4 &plic 182>; + device_type = "pci"; + pcie@0 { + reg = <0x0 0x0 0x0 0x0 0x0>; + #address-cells = <3>; + #size-cells = <2>; + ranges; + device_type = "pci"; + num-lanes = <4>; + resets = <&reset 99>; + reset-names = "perst"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml index cddbe21f99f2..0488c942092d 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml @@ -17,11 +17,11 @@ description: properties: clocks: minItems: 3 - maxItems: 5 + maxItems: 6 clock-names: minItems: 3 - maxItems: 5 + maxItems: 6 num-lanes: const: 1 diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml index 0b3526de1d62..e4e30da0acb0 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml @@ -18,12 +18,18 @@ description: |+ properties: compatible: - enum: - - fsl,imx8mm-pcie-ep - - fsl,imx8mq-pcie-ep - - fsl,imx8mp-pcie-ep - - fsl,imx8q-pcie-ep - - fsl,imx95-pcie-ep + oneOf: + - enum: + - fsl,imx8mm-pcie-ep + - fsl,imx8mp-pcie-ep + - fsl,imx8mq-pcie-ep + - fsl,imx8q-pcie-ep + - fsl,imx95-pcie-ep + - items: + - enum: + - fsl,imx94-pcie-ep + - fsl,imx943-pcie-ep + - const: fsl,imx95-pcie-ep clocks: minItems: 3 diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index 12a01f7a5744..9d1349855b42 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -21,16 +21,22 @@ description: |+ properties: compatible: - enum: - - fsl,imx6q-pcie - - fsl,imx6sx-pcie - - fsl,imx6qp-pcie - - fsl,imx7d-pcie - - fsl,imx8mq-pcie - - fsl,imx8mm-pcie - - fsl,imx8mp-pcie - - fsl,imx95-pcie - - fsl,imx8q-pcie + oneOf: + - enum: + - fsl,imx6q-pcie + - fsl,imx6qp-pcie + - fsl,imx6sx-pcie + - fsl,imx7d-pcie + - fsl,imx8mm-pcie + - fsl,imx8mp-pcie + - fsl,imx8mq-pcie + - fsl,imx8q-pcie + - fsl,imx95-pcie + - items: + - enum: + - fsl,imx94-pcie + - fsl,imx943-pcie + - const: fsl,imx95-pcie clocks: minItems: 3 @@ -40,7 +46,8 @@ properties: - description: PCIe PHY clock. - description: Additional required clock entry for imx6sx-pcie, imx6sx-pcie-ep, imx8mq-pcie, imx8mq-pcie-ep. - - description: PCIe reference clock. + - description: PCIe internal reference clock. + - description: PCIe additional external reference clock. clock-names: minItems: 3 diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml index 6d6052a2748f..7805757f2e2d 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie-ep.yaml @@ -55,12 +55,16 @@ properties: - const: intr clocks: + minItems: 1 items: - - description: module clock + - description: core clock + - description: monitor clock clock-names: + minItems: 1 items: - const: core + - const: core_m resets: items: diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml index fe81d52c7277..41041ae7e0a4 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.yaml @@ -58,12 +58,16 @@ properties: - const: msi clocks: + minItems: 1 items: - - description: module clock + - description: core clock + - description: monitor clock clock-names: + minItems: 1 items: - const: core + - const: core_m resets: items: diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml new file mode 100644 index 000000000000..dc4f8725c9f5 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml @@ -0,0 +1,149 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/nvidia,tegra264-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra264 PCIe controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra264-pcie + + reg: + description: | + Of the six PCIe controllers found on Tegra264, one (C0) is used for the + internal GPU and the other five (C1-C5) are routed to connectors such as + PCI or M.2 slots. Therefore the UPHY registers (XPL) exist only for C1 + through C5, but not for C0. + minItems: 4 + items: + - description: ECAM-compatible configuration space + - description: application layer registers + - description: transaction layer registers + - description: privileged transaction layer registers + - description: data link/physical layer registers (not available on C0) + + reg-names: + minItems: 4 + items: + - const: ecam + - const: xal + - const: xtl + - const: xtl-pri + - const: xpl + + interrupts: + minItems: 1 + maxItems: 4 + + dma-coherent: true + + nvidia,bpmp: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + Must contain a pair of phandle (to the BPMP controller node) and + controller ID. The following are the controller IDs for each controller: + + 0: C0 + 1: C1 + 2: C2 + 3: C3 + 4: C4 + 5: C5 + items: + - items: + - description: phandle to the BPMP controller node + - description: PCIe controller ID + maximum: 5 + +required: + - interrupt-map + - interrupt-map-mask + - iommu-map + - msi-map + - nvidia,bpmp + +allOf: + - $ref: /schemas/pci/pci-host-bridge.yaml# + +unevaluatedProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + pci@c000000 { + compatible = "nvidia,tegra264-pcie"; + reg = <0xd0 0xb0000000 0x0 0x10000000>, + <0x00 0x0c000000 0x0 0x00004000>, + <0x00 0x0c004000 0x0 0x00001000>, + <0x00 0x0c005000 0x0 0x00001000>; + reg-names = "ecam", "xal", "xtl", "xtl-pri"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + linux,pci-domain = <0x00>; + #interrupt-cells = <0x1>; + + interrupt-map-mask = <0x0 0x0 0x0 0x7>; + interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0x0 0x0 155 4>, + <0x0 0x0 0x0 0x2 &gic 0x0 0x0 0x0 156 4>, + <0x0 0x0 0x0 0x3 &gic 0x0 0x0 0x0 157 4>, + <0x0 0x0 0x0 0x4 &gic 0x0 0x0 0x0 158 4>; + + iommu-map = <0x0 &smmu2 0x10000 0x10000>; + msi-map = <0x0 &its 0x210000 0x10000>; + dma-coherent; + + ranges = <0x81000000 0x00 0x84000000 0xd0 0x84000000 0x00 0x00200000>, + <0x82000000 0x00 0x20000000 0x00 0x20000000 0x00 0x08000000>, + <0xc3000000 0xd0 0xc0000000 0xd0 0xc0000000 0x07 0xc0000000>; + bus-range = <0x0 0xff>; + + nvidia,bpmp = <&bpmp 0>; + }; + }; + + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + pci@8400000 { + compatible = "nvidia,tegra264-pcie"; + reg = <0xa8 0xb0000000 0x0 0x10000000>, + <0x00 0x08400000 0x0 0x00004000>, + <0x00 0x08404000 0x0 0x00001000>, + <0x00 0x08405000 0x0 0x00001000>, + <0x00 0x08410000 0x0 0x00010000>; + reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + linux,pci-domain = <0x01>; + #interrupt-cells = <1>; + interrupt-map-mask = <0x0 0x0 0x0 0x7>; + interrupt-map = <0x0 0x0 0x0 0x1 &gic 0x0 0x0 0x0 908 4>, + <0x0 0x0 0x0 0x2 &gic 0x0 0x0 0x0 909 4>, + <0x0 0x0 0x0 0x3 &gic 0x0 0x0 0x0 910 4>, + <0x0 0x0 0x0 0x4 &gic 0x0 0x0 0x0 911 4>; + + iommu-map = <0x0 &smmu1 0x10000 0x10000>; + msi-map = <0x0 &its 0x110000 0x10000>; + dma-coherent; + + ranges = <0x81000000 0x00 0x84000000 0xa8 0x84000000 0x00 0x00200000>, + <0x82000000 0x00 0x28000000 0x00 0x28000000 0x00 0x08000000>, + <0xc3000000 0xa8 0xc0000000 0xa8 0xc0000000 0x07 0xc0000000>; + bus-range = <0x00 0xff>; + + nvidia,bpmp = <&bpmp 1>; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml b/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml index d668782546a2..a67108c48feb 100644 --- a/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml @@ -10,17 +10,21 @@ maintainers: - Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> description: - Renesas RZ/G3S PCIe host controller complies with PCIe Base Specification - 4.0 and supports up to 5 GT/s (Gen2). + Renesas RZ/G3{E,S} PCIe host controllers comply with PCIe + Base Specification 4.0 and support up to 5 GT/s (Gen2) for RZ/G3S and + up to 8 GT/s (Gen3) for RZ/G3E. properties: compatible: - const: renesas,r9a08g045-pcie # RZ/G3S + enum: + - renesas,r9a08g045-pcie # RZ/G3S + - renesas,r9a09g047-pcie # RZ/G3E reg: maxItems: 1 interrupts: + minItems: 16 items: - description: System error interrupt - description: System error on correctable error interrupt @@ -38,39 +42,55 @@ properties: - description: PCIe event interrupt - description: Message interrupt - description: All interrupts + - description: Link equalization request interrupt + - description: Turn off event interrupt + - description: PMU power off interrupt + - description: D3 event function 0 interrupt + - description: D3 event function 1 interrupt + - description: Configuration PMCSR write clear function 0 interrupt + - description: Configuration PMCSR write clear function 1 interrupt interrupt-names: + minItems: 16 items: - - description: serr - - description: ser_cor - - description: serr_nonfatal - - description: serr_fatal - - description: axi_err - - description: inta - - description: intb - - description: intc - - description: intd - - description: msi - - description: link_bandwidth - - description: pm_pme - - description: dma - - description: pcie_evt - - description: msg - - description: all + - const: serr + - const: serr_cor + - const: serr_nonfatal + - const: serr_fatal + - const: axi_err + - const: inta + - const: intb + - const: intc + - const: intd + - const: msi + - const: link_bandwidth + - const: pm_pme + - const: dma + - const: pcie_evt + - const: msg + - const: all + - const: link_equalization_request + - const: turn_off_event + - const: pmu_poweroff + - const: d3_event_f0 + - const: d3_event_f1 + - const: cfg_pmcsr_writeclear_f0 + - const: cfg_pmcsr_writeclear_f1 interrupt-controller: true clocks: items: - description: System clock - - description: PM control clock + - description: PM control clock or clock for L1 substate handling clock-names: items: - - description: aclk - - description: pm + - const: aclk + - enum: [pm, pmu] resets: + minItems: 1 items: - description: AXI2PCIe Bridge reset - description: Data link layer/transaction layer reset @@ -81,14 +101,15 @@ properties: - description: Configuration register reset reset-names: + minItems: 1 items: - - description: aresetn - - description: rst_b - - description: rst_gp_b - - description: rst_ps_b - - description: rst_rsm_b - - description: rst_cfg_b - - description: rst_load_b + - const: aresetn + - const: rst_b + - const: rst_gp_b + - const: rst_ps_b + - const: rst_rsm_b + - const: rst_cfg_b + - const: rst_load_b power-domains: maxItems: 1 @@ -128,7 +149,9 @@ patternProperties: const: 0x1912 device-id: - const: 0x0033 + enum: + - 0x0033 + - 0x0039 clocks: items: @@ -167,6 +190,44 @@ required: allOf: - $ref: /schemas/pci/pci-host-bridge.yaml# + - if: + properties: + compatible: + contains: + const: renesas,r9a08g045-pcie + then: + properties: + interrupts: + maxItems: 16 + interrupt-names: + maxItems: 16 + clock-names: + items: + - const: aclk + - const: pm + resets: + minItems: 7 + reset-names: + minItems: 7 + - if: + properties: + compatible: + contains: + const: renesas,r9a09g047-pcie + then: + properties: + interrupts: + minItems: 23 + interrupt-names: + minItems: 23 + clock-names: + items: + - const: aclk + - const: pmu + resets: + maxItems: 1 + reset-names: + maxItems: 1 unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml b/Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml new file mode 100644 index 000000000000..b959b381c44c --- /dev/null +++ b/Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/canaan,k230-usb-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Canaan K230 USB2.0 PHY + +maintainers: + - Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn> + +properties: + compatible: + const: canaan,k230-usb-phy + + reg: + maxItems: 1 + + "#phy-cells": + const: 1 + +required: + - compatible + - reg + - "#phy-cells" + +additionalProperties: false + +examples: + - | + usbphy: usb-phy@91585000 { + compatible = "canaan,k230-usb-phy"; + reg = <0x91585000 0x400>; + #phy-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/phy/eswin,eic7700-sata-phy.yaml b/Documentation/devicetree/bindings/phy/eswin,eic7700-sata-phy.yaml new file mode 100644 index 000000000000..fc7dbac77acf --- /dev/null +++ b/Documentation/devicetree/bindings/phy/eswin,eic7700-sata-phy.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/eswin,eic7700-sata-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Eswin EIC7700 SoC SATA PHY + +maintainers: + - Yulin Lu <luyulin@eswincomputing.com> + - Huan He <hehuan1@eswincomputing.com> + +properties: + compatible: + const: eswin,eic7700-sata-phy + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: phy + + resets: + maxItems: 2 + + reset-names: + items: + - const: port + - const: phy + + eswin,tx-amplitude-tuning: + description: This adjusts the transmitter amplitude signal, and its value + is derived from eye diagram tuning. The three values correspond to Gen1, + Gen2, and Gen3 parameters respectively. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: Gen1 parameter. + minimum: 0 + maximum: 0x7f + - description: Gen2 parameter. + minimum: 0 + maximum: 0x7f + - description: Gen3 parameter. + minimum: 0 + maximum: 0x7f + default: [0, 0, 0] + + eswin,tx-preemph-tuning: + description: This adjusts the transmitter de-emphasis signal, and its value + is derived from eye diagram tuning. The three values correspond to Gen1, + Gen2, and Gen3 parameters respectively. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: Gen1 parameter. + minimum: 0 + maximum: 0x3f + - description: Gen2 parameter. + minimum: 0 + maximum: 0x3f + - description: Gen3 parameter. + minimum: 0 + maximum: 0x3f + default: [0, 0, 0] + + "#phy-cells": + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - "#phy-cells" + +additionalProperties: false + +examples: + - | + sata-phy@50440300 { + compatible = "eswin,eic7700-sata-phy"; + reg = <0x50440300 0x40>; + clocks = <&hspcrg 17>; + clock-names = "phy"; + resets = <&hspcrg 0>, <&hspcrg 1>; + reset-names = "port", "phy"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml index acdbce937b0a..c6d0bbdbe0e2 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml @@ -23,6 +23,7 @@ properties: - items: - enum: - mediatek,mt7623-mipi-tx + - mediatek,mt8167-mipi-tx - const: mediatek,mt2701-mipi-tx - items: - enum: diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml index 6e3398399628..d8de900a4fce 100644 --- a/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml @@ -230,6 +230,10 @@ properties: connector: type: object + port: + description: connection to a USB Type C controller + $ref: /schemas/graph.yaml#/properties/port + mode: description: A string that determines the mode in which to run the port. @@ -256,7 +260,12 @@ properties: voltage. dependencies: - usb-role-switch: [ connector ] + usb-role-switch: + oneOf: + - required: + - connector + - required: + - port usb2-1: type: object @@ -268,6 +277,10 @@ properties: connector: type: object + port: + description: connection to a USB Type C controller + $ref: /schemas/graph.yaml#/properties/port + mode: description: A string that determines the mode in which to run the port. @@ -306,6 +319,10 @@ properties: connector: type: object + port: + description: connection to a USB Type C controller + $ref: /schemas/graph.yaml#/properties/port + mode: description: A string that determines the mode in which to run the port. @@ -344,6 +361,10 @@ properties: connector: type: object + port: + description: connection to a USB Type C controller + $ref: /schemas/graph.yaml#/properties/port + mode: description: A string that determines the mode in which to run the port. @@ -405,6 +426,10 @@ properties: description: A phandle to the regulator supplying the VBUS voltage. + port: + description: connection to a USB Type C controller + $ref: /schemas/graph.yaml#/properties/port + usb3-1: type: object additionalProperties: false @@ -438,6 +463,10 @@ properties: description: A phandle to the regulator supplying the VBUS voltage. + port: + description: connection to a USB Type C controller + $ref: /schemas/graph.yaml#/properties/port + usb3-2: type: object additionalProperties: false @@ -471,6 +500,10 @@ properties: description: A phandle to the regulator supplying the VBUS voltage. + port: + description: connection to a USB Type C controller + $ref: /schemas/graph.yaml#/properties/port + usb3-3: type: object additionalProperties: false @@ -504,6 +537,10 @@ properties: description: A phandle to the regulator supplying the VBUS voltage. + port: + description: connection to a USB Type C controller + $ref: /schemas/graph.yaml#/properties/port + additionalProperties: false required: diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml index d61585c96e31..a37e8322dc50 100644 --- a/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.yaml @@ -16,6 +16,7 @@ properties: oneOf: - items: - enum: + - nvidia,tegra210-usb-phy - nvidia,tegra124-usb-phy - nvidia,tegra114-usb-phy - enum: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-10nm.yaml index fc9abf090f0d..d98217747ad1 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-10nm.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/display/msm/dsi-phy-10nm.yaml# +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-10nm.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Display DSI 10nm PHY @@ -10,7 +10,7 @@ maintainers: - Krishna Manikandan <quic_mkrishn@quicinc.com> allOf: - - $ref: dsi-phy-common.yaml# + - $ref: qcom,dsi-phy-common.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-14nm.yaml index 206a9a4b3845..be31b9bac9d5 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-14nm.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/display/msm/dsi-phy-14nm.yaml# +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-14nm.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Display DSI 14nm PHY @@ -10,7 +10,7 @@ maintainers: - Krishna Manikandan <quic_mkrishn@quicinc.com> allOf: - - $ref: dsi-phy-common.yaml# + - $ref: qcom,dsi-phy-common.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-20nm.yaml index 93570052992a..1d135419d015 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-20nm.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/display/msm/dsi-phy-20nm.yaml# +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-20nm.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Display DSI 20nm PHY @@ -10,7 +10,7 @@ maintainers: - Krishna Manikandan <quic_mkrishn@quicinc.com> allOf: - - $ref: dsi-phy-common.yaml# + - $ref: qcom,dsi-phy-common.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-28nm.yaml index 371befa9f9d2..f8fe75fa29d7 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-28nm.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/display/msm/dsi-phy-28nm.yaml# +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-28nm.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Display DSI 28nm PHY @@ -10,7 +10,7 @@ maintainers: - Krishna Manikandan <quic_mkrishn@quicinc.com> allOf: - - $ref: dsi-phy-common.yaml# + - $ref: qcom,dsi-phy-common.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-7nm.yaml index 9a9a6c4abf43..966c70d746aa 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-7nm.yaml @@ -1,7 +1,7 @@ # 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# +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-7nm.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Display DSI 7nm PHY @@ -10,7 +10,7 @@ maintainers: - Jonathan Marek <jonathan@marek.ca> allOf: - - $ref: dsi-phy-common.yaml# + - $ref: qcom,dsi-phy-common.yaml# properties: compatible: @@ -31,7 +31,12 @@ properties: - qcom,sm8750-dsi-phy-3nm - items: - enum: + - qcom,eliza-dsi-phy-4nm + - const: qcom,sm8650-dsi-phy-4nm + - items: + - enum: - qcom,qcs8300-dsi-phy-5nm + - qcom,sc8280xp-dsi-phy-5nm - const: qcom,sa8775p-dsi-phy-5nm reg: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-common.yaml index d0ce85a08b6d..849321e56b2f 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-common.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/display/msm/dsi-phy-common.yaml# +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-common.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Display DSI PHY Common Properties diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml index a1731b08c9d1..9616c736b6d4 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml @@ -18,6 +18,10 @@ properties: oneOf: - items: - enum: + - qcom,qcs8300-qmp-ufs-phy + - const: qcom,sa8775p-qmp-ufs-phy + - items: + - enum: - qcom,qcs615-qmp-ufs-phy - const: qcom,sm6115-qmp-ufs-phy - items: @@ -26,8 +30,8 @@ properties: - const: qcom,sm8550-qmp-ufs-phy - items: - enum: - - qcom,qcs8300-qmp-ufs-phy - - const: qcom,sa8775p-qmp-ufs-phy + - qcom,eliza-qmp-ufs-phy + - const: qcom,sm8650-qmp-ufs-phy - items: - enum: - qcom,kaanapali-qmp-ufs-phy diff --git a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml index 665ec79a69f1..41073176bc69 100644 --- a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml @@ -18,7 +18,9 @@ properties: compatible: oneOf: - items: - - const: apple,t6020-pinctrl + - enum: + - apple,t6020-pinctrl + - apple,t8122-pinctrl - const: apple,t8103-pinctrl - items: # Do not add additional SoC to this list. diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx27-iomuxc.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx27-iomuxc.yaml new file mode 100644 index 000000000000..1254bfcaa7cb --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx27-iomuxc.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/fsl,imx27-iomuxc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX1/i.MX25/i.MX27 IOMUX Controller + +maintainers: + - Frank Li <Frank.Li@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: + enum: + - fsl,imx1-iomuxc + - fsl,imx27-iomuxc + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + ranges: true + +patternProperties: + '^gpio@[0-9a-f]+$': + type: object + $ref: /schemas/gpio/fsl-imx-gpio.yaml + unevaluatedProperties: false + + '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: + three integers array, represents a group of pins mux and config + setting. The format is fsl,pins = <PIN MUX_ID CONFIG>. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: + PIN is an integer between 0 and 0xbf. imx27 has 6 ports with 32 + configurable pins each. PIN is PORT * 32 + PORT_PIN, PORT_PIN + is the pin number on the specific port (between 0 and 31) + - description: | + MUX_ID is function + (direction << 2) + (gpio_oconf << 4) + + (gpio_iconfa << 8) + (gpio_iconfb << 10) + + function value is used to select the pin function. + Possible values: + 0 - Primary function + 1 - Alternate function + 2 - GPIO + Registers: GIUS (GPIO In Use), GPR (General Purpose Register) + + direction defines the data direction of the pin. + Possible values: + 0 - Input + 1 - Output + Register: DDIR + + gpio_oconf configures the gpio submodule output signal. + This does not have any effect unless GPIO function is + selected. A/B/C_IN are output signals of function blocks + A,B and C. Specific function blocks are described in the + reference manual. + Possible values: + 0 - A_IN + 1 - B_IN + 2 - C_IN + 3 - Data Register + Registers: OCR1, OCR2 + + gpio_iconfa/b configures the gpio submodule input to + functionblocks A and B. GPIO function should be selected if + this is configured. + Possible values: + 0 - GPIO_IN + 1 - Interrupt Status Register + 2 - Pulldown + 3 - Pullup + Registers ICONFA1, ICONFA2, ICONFB1 and ICONFB2 + + - description: + CONFIG can be 0 or 1, meaning Pullup disable/enable. + required: + - fsl,pins + + additionalProperties: false + +required: + - compatible + - reg + +allOf: + - $ref: pinctrl.yaml# + +unevaluatedProperties: false + +examples: + - | + pinmux@10015000 { + compatible = "fsl,imx27-iomuxc"; + reg = <0x10015000 0x600>; + + uartgrp { + fsl,pins = < + 0x8c 0x004 0x0 /* UART1_TXD__UART1_TXD */ + 0x8d 0x000 0x0 /* UART1_RXD__UART1_RXD */ + 0x8e 0x004 0x0 /* UART1_CTS__UART1_CTS */ + 0x8f 0x000 0x0 /* UART1_RTS__UART1_RTS */ + >; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt deleted file mode 100644 index d1706ea82572..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt +++ /dev/null @@ -1,121 +0,0 @@ -* Freescale IMX27 IOMUX Controller - -Required properties: -- compatible: "fsl,imx27-iomuxc" - -The iomuxc driver node should define subnodes containing of pinctrl configuration subnodes. - -Required properties for pin configuration node: -- fsl,pins: three integers array, represents a group of pins mux and config - setting. The format is fsl,pins = <PIN MUX_ID CONFIG>. - - PIN is an integer between 0 and 0xbf. imx27 has 6 ports with 32 configurable - configurable pins each. PIN is PORT * 32 + PORT_PIN, PORT_PIN is the pin - number on the specific port (between 0 and 31). - - MUX_ID is - function + (direction << 2) + (gpio_oconf << 4) + (gpio_iconfa << 8) + (gpio_iconfb << 10) - - function value is used to select the pin function. - Possible values: - 0 - Primary function - 1 - Alternate function - 2 - GPIO - Registers: GIUS (GPIO In Use), GPR (General Purpose Register) - - direction defines the data direction of the pin. - Possible values: - 0 - Input - 1 - Output - Register: DDIR - - gpio_oconf configures the gpio submodule output signal. This does not - have any effect unless GPIO function is selected. A/B/C_IN are output - signals of function blocks A,B and C. Specific function blocks are - described in the reference manual. - Possible values: - 0 - A_IN - 1 - B_IN - 2 - C_IN - 3 - Data Register - Registers: OCR1, OCR2 - - gpio_iconfa/b configures the gpio submodule input to functionblocks A and - B. GPIO function should be selected if this is configured. - Possible values: - 0 - GPIO_IN - 1 - Interrupt Status Register - 2 - Pulldown - 3 - Pullup - Registers ICONFA1, ICONFA2, ICONFB1 and ICONFB2 - - CONFIG can be 0 or 1, meaning Pullup disable/enable. - - -The iomux controller has gpio child nodes which are embedded in the iomux -control registers. They have to be defined as child nodes of the iomux device -node. If gpio subnodes are defined "#address-cells", "#size-cells" and "ranges" -properties for the iomux device node are required. - -Example: - -iomuxc: iomuxc@10015000 { - compatible = "fsl,imx27-iomuxc"; - reg = <0x10015000 0x600>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - gpio1: gpio@10015000 { - ... - }; - - ... - - uart { - pinctrl_uart1: uart-1 { - fsl,pins = < - 0x8c 0x004 0x0 /* UART1_TXD__UART1_TXD */ - 0x8d 0x000 0x0 /* UART1_RXD__UART1_RXD */ - 0x8e 0x004 0x0 /* UART1_CTS__UART1_CTS */ - 0x8f 0x000 0x0 /* UART1_RTS__UART1_RTS */ - >; - }; - - ... - }; -}; - - -For convenience there are macros defined in imx27-pinfunc.h which provide PIN -and MUX_ID. They are structured as MX27_PAD_<Pad name>__<Signal name>. The names -are defined in the i.MX27 reference manual. - -The above example using macros: - -iomuxc: iomuxc@10015000 { - compatible = "fsl,imx27-iomuxc"; - reg = <0x10015000 0x600>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - gpio1: gpio@10015000 { - ... - }; - - ... - - uart { - pinctrl_uart1: uart-1 { - fsl,pins = < - MX27_PAD_UART1_TXD__UART1_TXD 0x0 - MX27_PAD_UART1_RXD__UART1_RXD 0x0 - MX27_PAD_UART1_CTS__UART1_CTS 0x0 - MX27_PAD_UART1_RTS__UART1_RTS 0x0 - >; - }; - - ... - }; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml index 265c43ab76f4..846e110062b2 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx35-pinctrl.yaml @@ -20,6 +20,7 @@ properties: compatible: oneOf: - enum: + - fsl,imx25-iomuxc - fsl,imx35-iomuxc - fsl,imx51-iomuxc - fsl,imx53-iomuxc diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada3710-xb-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/marvell,armada3710-xb-pinctrl.yaml index 4f9013d36874..727da7fb490c 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,armada3710-xb-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada3710-xb-pinctrl.yaml @@ -84,11 +84,12 @@ patternProperties: properties: groups: - enum: [ emmc_nb, i2c1, i2c2, jtag, mii_col, onewire, pcie1, - pcie1_clkreq, pcie1_wakeup, pmic0, pmic1, ptp, ptp_clk, - ptp_trig, pwm0, pwm1, pwm2, pwm3, rgmii, sdio0, sdio_sb, smi, - spi_cs1, spi_cs2, spi_cs3, spi_quad, uart1, uart2, - usb2_drvvbus1, usb32_drvvbus0 ] + items: + enum: [ emmc_nb, i2c1, i2c2, jtag, mii_col, onewire, pcie1, + pcie1_clkreq, pcie1_wakeup, pmic0, pmic1, ptp, ptp_clk, + ptp_trig, pwm0, pwm1, pwm2, pwm3, rgmii, sdio0, sdio_sb, + smi, spi_cs1, spi_cs2, spi_cs3, spi_quad, uart1, uart2, + usb2_drvvbus1, usb32_drvvbus0 ] function: enum: [ drvbus, emmc, gpio, i2c, jtag, led, mii, mii_err, onewire, diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml new file mode 100644 index 000000000000..b3ea36474317 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Pinmux controller function for Maxim MAX77620 Power management IC + +maintainers: + - Svyatoslav Ryhel <clamor95@gmail.com> + +description: + Device has 8 GPIO pins which can be configured as GPIO as well as the + special IO functions. + +allOf: + - $ref: /schemas/pinctrl/pincfg-node.yaml + - $ref: /schemas/pinctrl/pinmux-node.yaml + +patternProperties: + "^(pin|gpio).": + type: object + additionalProperties: false + + properties: + pins: + items: + enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7 ] + + function: + items: + enum: [ gpio, lpm-control-in, fps-out, 32k-out1, sd0-dvs-in, sd1-dvs-in, + reference-out ] + + drive-push-pull: true + drive-open-drain: true + bias-pull-up: true + bias-pull-down: true + + maxim,active-fps-source: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + FPS source for the GPIOs to get enabled/disabled when system is in + active state. Valid values are: + - MAX77620_FPS_SRC_0: FPS source is FPS0. + - MAX77620_FPS_SRC_1: FPS source is FPS1 + - MAX77620_FPS_SRC_2: FPS source is FPS2 + - MAX77620_FPS_SRC_NONE: GPIO is not controlled by FPS events and + it gets enabled/disabled by register access. + Absence of this property will leave the FPS configuration register + for that GPIO to default configuration. + + maxim,active-fps-power-up-slot: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Sequencing event slot number on which the GPIO get enabled when + master FPS input event set to HIGH. This is applicable if FPS source + is selected as FPS0, FPS1 or FPS2. + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + maxim,active-fps-power-down-slot: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Sequencing event slot number on which the GPIO get disabled when + master FPS input event set to LOW. This is applicable if FPS source + is selected as FPS0, FPS1 or FPS2. + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + maxim,suspend-fps-source: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + This is same as property "maxim,active-fps-source" but value get + configured when system enters in to suspend state. + + maxim,suspend-fps-power-up-slot: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + This is same as property "maxim,active-fps-power-up-slot" but this + value get configured into FPS configuration register when system + enters into suspend. This is applicable if suspend state FPS source + is selected as FPS0, FPS1 or FPS2. + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + maxim,suspend-fps-power-down-slot: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + This is same as property "maxim,active-fps-power-down-slot" but this + value get configured into FPS configuration register when system + enters into suspend. This is applicable if suspend state FPS source + is selected as FPS0, FPS1 or FPS2. + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + required: + - pins + +additionalProperties: false + +# see maxim,max77620.yaml for an example diff --git a/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml b/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml index a916d0fc79a9..97dbce8a261f 100644 --- a/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml @@ -162,12 +162,105 @@ properties: this affects the expected delay in ps before latching a value to an output pin. -if: - required: - - skew-delay -then: - properties: - skew-delay-input-ps: false - skew-delay-output-ps: false + input-threshold-voltage-microvolt: + description: Specifies the input voltage level of the pin in microvolts. + This defines the reference for VIH (Input High Voltage) and VIL + (Input Low Voltage) thresholds for proper signal detection. + +allOf: + - if: + required: + - skew-delay + then: + properties: + skew-delay-input-ps: false + skew-delay-output-ps: false + + - if: + required: + - input-disable + then: + properties: + input-enable: false + input-threshold-voltage-microvolt: false + + - if: + required: + - output-disable + then: + properties: + output-enable: false + output-impedance-ohms: false + + - if: + required: + - output-low + then: + properties: + output-high: false + + - if: + required: + - low-power-enable + then: + properties: + low-power-disable: false + + - if: + required: + - input-schmitt-disable + then: + properties: + input-schmitt-enable: false + input-schmitt-microvolt: false + + - if: + required: + - drive-strength + then: + properties: + drive-strength-microamp: false + + - if: + anyOf: + - required: + - drive-open-source + - required: + - drive-open-drain + - required: + - drive-push-pull + then: + oneOf: + - required: + - drive-open-source + - required: + - drive-open-drain + - required: + - drive-push-pull + + - if: + anyOf: + - required: + - bias-disable + - required: + - bias-bus-hold + - required: + - bias-pull-up + - required: + - bias-pull-down + - required: + - bias-pull-pin-default + then: + oneOf: + - required: + - bias-disable + - required: + - bias-bus-hold + - required: + - bias-pull-up + - required: + - bias-pull-down + - required: + - bias-pull-pin-default additionalProperties: true diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt deleted file mode 100644 index 28fbca180068..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt +++ /dev/null @@ -1,127 +0,0 @@ -Pincontrol driver for MAX77620 Power management IC from Maxim Semiconductor. - -Device has 8 GPIO pins which can be configured as GPIO as well as the -special IO functions. - -Please refer file <devicetree/bindings/pinctrl/pinctrl-bindings.txt> -for details of the common pinctrl bindings used by client devices, -including the meaning of the phrase "pin configuration node". - -Optional Pinmux properties: --------------------------- -Following properties are required if default setting of pins are required -at boot. -- pinctrl-names: A pinctrl state named per <pinctrl-bindings.txt>. -- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per - <pinctrl-bindings.txt>. - -The pin configurations are defined as child of the pinctrl states node. Each -sub-node have following properties: - -Required properties: ------------------- -- pins: List of pins. Valid values of pins properties are: - gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7. - -Optional properties: -------------------- -Following are optional properties defined as pinmux DT binding document -<pinctrl-bindings.txt>. Absence of properties will leave the configuration -on default. - function, - drive-push-pull, - drive-open-drain, - bias-pull-up, - bias-pull-down. - -Valid values for function properties are: - gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in, - reference-out - -There are also customised properties for the GPIO1, GPIO2 and GPIO3. These -customised properties are required to configure FPS configuration parameters -of these GPIOs. Please refer <devicetree/bindings/mfd/max77620.txt> for more -detail of Flexible Power Sequence (FPS). - -- maxim,active-fps-source: FPS source for the GPIOs to get - enabled/disabled when system is in - active state. Valid values are: - - MAX77620_FPS_SRC_0, - FPS source is FPS0. - - MAX77620_FPS_SRC_1, - FPS source is FPS1 - - MAX77620_FPS_SRC_2 and - FPS source is FPS2 - - MAX77620_FPS_SRC_NONE. - GPIO is not controlled - by FPS events and it gets - enabled/disabled by register - access. - Absence of this property will leave - the FPS configuration register for that - GPIO to default configuration. - -- maxim,active-fps-power-up-slot: Sequencing event slot number on which - the GPIO get enabled when - master FPS input event set to HIGH. - Valid values are 0 to 7. - This is applicable if FPS source is - selected as FPS0, FPS1 or FPS2. - -- maxim,active-fps-power-down-slot: Sequencing event slot number on which - the GPIO get disabled when master - FPS input event set to LOW. - Valid values are 0 to 7. - This is applicable if FPS source is - selected as FPS0, FPS1 or FPS2. - -- maxim,suspend-fps-source: This is same as property - "maxim,active-fps-source" but value - get configured when system enters in - to suspend state. - -- maxim,suspend-fps-power-up-slot: This is same as property - "maxim,active-fps-power-up-slot" but - this value get configured into FPS - configuration register when system - enters into suspend. - This is applicable if suspend state - FPS source is selected as FPS0, FPS1 or - -- maxim,suspend-fps-power-down-slot: This is same as property - "maxim,active-fps-power-down-slot" but - this value get configured into FPS - configuration register when system - enters into suspend. - This is applicable if suspend state - FPS source is selected as FPS0, FPS1 or - FPS2. - -Example: --------- -#include <dt-bindings/mfd/max77620.h> -... -max77620@3c { - - pinctrl-names = "default"; - pinctrl-0 = <&spmic_default>; - - spmic_default: pinmux@0 { - pin_gpio0 { - pins = "gpio0"; - function = "gpio"; - }; - - pin_gpio1 { - pins = "gpio1"; - function = "fps-out"; - maxim,active-fps-source = <MAX77620_FPS_SRC_0>; - }; - - pin_gpio2 { - pins = "gpio2"; - function = "fps-out"; - maxim,active-fps-source = <MAX77620_FPS_SRC_1>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml index 9135788cf62e..afe7329a1df2 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml @@ -38,6 +38,10 @@ properties: - enum: - marvell,pxa1908-padconf - const: pinconf-single + - items: + - enum: + - brcm,bcm7038-padconf + - const: pinctrl-single reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml new file mode 100644 index 000000000000..282650426487 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml @@ -0,0 +1,138 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,eliza-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. Eliza TLMM block + +maintainers: + - Abel Vesa <abel.vesa@oss.qualcomm.com> + +description: + Top Level Mode Multiplexer pin controller in Qualcomm Eliza SoC. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,eliza-tlmm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + gpio-reserved-ranges: + minItems: 1 + maxItems: 93 + + gpio-line-names: + maxItems: 185 + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-eliza-tlmm-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-eliza-tlmm-state" + additionalProperties: false + +$defs: + qcom-eliza-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 + unevaluatedProperties: false + + 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]|1[0-7][0-9]|18[0-4])$" + - enum: [ ufs_reset ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + enum: [ gpio, aoss_cti, atest_char, atest_usb, audio_ext_mclk0, + audio_ref_clk, cam_mclk, cci_async_in, cci_i2c_scl, + cci_i2c_sda, cci_timer, coex_uart1_rx, coex_uart1_tx, + coex_uart2_rx, coex_uart2_tx, dbg_out_clk, + ddr_bist_complete, ddr_bist_fail, ddr_bist_start, + ddr_bist_stop, ddr_pxi0, ddr_pxi1, dp0_hot, egpio, + gcc_gp1, gcc_gp2, gcc_gp3, gnss_adc0, gnss_adc1, + hdmi_ddc_scl, hdmi_ddc_sda, hdmi_dtest0, hdmi_dtest1, + hdmi_hot_plug, hdmi_pixel_clk, hdmi_rcv_det, hdmi_tx_cec, + host2wlan_sol, i2s0_data0, i2s0_data1, i2s0_sck, i2s0_ws, + ibi_i3c, jitter_bist, mdp_esync0_out, mdp_esync1_out, + mdp_vsync, mdp_vsync0_out, mdp_vsync11_out, + mdp_vsync1_out, mdp_vsync2_out, mdp_vsync3_out, + mdp_vsync_e, nav_gpio0, nav_gpio1, nav_gpio2, nav_gpio3, + pcie0_clk_req_n, pcie1_clk_req_n, phase_flag, + pll_bist_sync, pll_clk_aux, prng_rosc0, prng_rosc1, + prng_rosc2, prng_rosc3, qdss_cti, qdss_gpio_traceclk, + qdss_gpio_tracectl, qdss_gpio_tracedata, qlink_big_enable, + qlink_big_request, qlink_little_enable, + qlink_little_request, qlink_wmss, qspi0, qspi_clk, + qspi_cs, qup1_se0, qup1_se1, qup1_se2, qup1_se3, qup1_se4, + qup1_se5, qup1_se6, qup1_se7, qup2_se0, qup2_se1, + qup2_se2, qup2_se3, qup2_se4, qup2_se5, qup2_se6, + qup2_se7, resout_gpio, sd_write_protect, sdc1, sdc2, + sdc2_fb_clk, tb_trig_sdc1, tb_trig_sdc2, tmess_prng0, + tmess_prng1, tmess_prng2, tmess_prng3, tsense_pwm1, + tsense_pwm2, tsense_pwm3, tsense_pwm4, uim0_clk, + uim0_data, uim0_present, uim0_reset, uim1_clk, uim1_data, + uim1_present, uim1_reset, usb0_hs, usb_phy, vfr_0, vfr_1, + vsense_trigger_mirnat, wcn_sw_ctrl ] + required: + - pins + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + tlmm: pinctrl@f100000 { + compatible = "qcom,eliza-tlmm"; + reg = <0x0f100000 0x300000>; + + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + + gpio-ranges = <&tlmm 0 0 186>; + + gpio-wo-state { + pins = "gpio1"; + function = "gpio"; + }; + + qup-uart14-default-state { + pins = "gpio18", "gpio19"; + function = "qup2_se5"; + drive-strength = <2>; + bias-disable; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,hawi-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,hawi-tlmm.yaml new file mode 100644 index 000000000000..3b3961789860 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,hawi-tlmm.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,hawi-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. Hawi TLMM block + +maintainers: + - Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> + +description: + Top Level Mode Multiplexer pin controller in Qualcomm Hawi SoC. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,hawi-tlmm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + gpio-reserved-ranges: + minItems: 1 + maxItems: 113 + + gpio-line-names: + maxItems: 226 + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-hawi-tlmm-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-hawi-tlmm-state" + additionalProperties: false + +$defs: + qcom-hawi-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 + unevaluatedProperties: false + + 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]|1[0-9][0-9]|20[0-9]|21[0-9]|22[0-5])$" + - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + enum: [ gpio, aoss_cti, atest_char, atest_usb, audio_ext_mclk, + audio_ref_clk, cam_mclk, cci_async_in, cci_i2c0, cci_i2c1, + cci_i2c2, cci_i2c3, cci_i2c4, cci_i2c5, cci_timer, coex_espmi, + coex_uart1_rx, coex_uart1_tx, dbg_out_clk, ddr_bist, ddr_pxi, + dp_hot, egpio, gcc_gp, gnss_adc, host_rst, i2chub0_se0, + i2chub0_se1, i2chub0_se2, i2chub0_se3, i2chub0_se4, i2s0, i2s1, + ibi_i3c, jitter_bist, mdp_esync0, mdp_esync1, mdp_esync2, + mdp_vsync, mdp_vsync_e, mdp_vsync_p, mdp_vsync0_out, + mdp_vsync1_out, mdp_vsync2_out, mdp_vsync3_out, mdp_vsync5_out, + modem_pps_in, modem_pps_out, nav_gpio, nav_gpio0, nav_gpio3, + nav_rffe, pcie0_clk_req_n, pcie0_rst_n, pcie1_clk_req_n, + phase_flag, pll_bist_sync, pll_clk_aux, qdss_cti, qlink, + qspi, qspi_clk, qspi_cs, qup1_se0, qup1_se1, qup1_se2, + qup1_se3, qup1_se4, qup1_se5, qup1_se6, qup1_se7, qup2_se0, + qup2_se1, qup2_se2, qup2_se3, qup2_se4_01, qup2_se4_23, + qup3_se0_01, qup3_se0_23, qup3_se1, qup3_se2, qup3_se3, + qup3_se4, qup3_se5, qup4_se0, qup4_se1, qup4_se2, qup4_se3_01, + qup4_se3_23, qup4_se3_l3, qup4_se4_01, qup4_se4_23, qup4_se4_l3, + rng_rosc, sd_write_protect, sdc4_clk, sdc4_cmd, sdc4_data, + sys_throttle, tb_trig_sdc, tmess_rng, tsense_clm, tsense_pwm, + uim0, uim1, usb0_hs, usb_phy, vfr, vsense_trigger_mirnat, + wcn_sw_ctrl ] + + required: + - pins + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + tlmm: pinctrl@f100000 { + compatible = "qcom,hawi-tlmm"; + reg = <0x0f100000 0x300000>; + interrupts = <GIC_ESPI 272 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&tlmm 0 0 227>; + interrupt-controller; + #interrupt-cells = <2>; + + qup-uart7-state { + pins = "gpio62", "gpio63"; + function = "qup1_se7"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq5210-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5210-tlmm.yaml new file mode 100644 index 000000000000..12c5e76235a3 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq5210-tlmm.yaml @@ -0,0 +1,123 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,ipq5210-tlmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm IPQ5210 TLMM pin controller + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + - Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> + +description: + Top Level Mode Multiplexer pin controller in Qualcomm IPQ5210 SoC. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,ipq5210-tlmm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + gpio-reserved-ranges: + minItems: 1 + maxItems: 27 + + gpio-line-names: + maxItems: 54 + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-ipq5210-tlmm-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-ipq5210-tlmm-state" + additionalProperties: false + +$defs: + qcom-ipq5210-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 + unevaluatedProperties: false + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + pattern: "^gpio([0-9]|[1-4][0-9]|5[0-3])$" + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ atest_char_start, atest_char_status0, atest_char_status1, + atest_char_status2, atest_char_status3, atest_tic_en, audio_pri, + audio_pri_mclk_out0, audio_pri_mclk_in0, audio_pri_mclk_out1, + audio_pri_mclk_in1, audio_pri_mclk_out2, audio_pri_mclk_in2, + audio_pri_mclk_out3, audio_pri_mclk_in3, audio_sec, + audio_sec_mclk_out0, audio_sec_mclk_in0, audio_sec_mclk_out1, + audio_sec_mclk_in1, audio_sec_mclk_out2, audio_sec_mclk_in2, + audio_sec_mclk_out3, audio_sec_mclk_in3, core_voltage_0, + cri_trng0, cri_trng1, cri_trng2, cri_trng3, dbg_out_clk, dg_out, + gcc_plltest_bypassnl, gcc_plltest_resetn, gcc_tlmm, gpio, led0, + led1, led2, mdc_mst, mdc_slv0, mdc_slv1, mdc_slv2, mdio_mst, + mdio_slv0, mdio_slv1, mdio_slv2, mux_tod_out, pcie0_clk_req_n, + pcie0_wake, pcie1_clk_req_n, pcie1_wake, pll_test, + pon_active_led, pon_mux_sel, pon_rx, pon_rx_los, pon_tx, + pon_tx_burst, pon_tx_dis, pon_tx_fault, pon_tx_sd, gpn_rx_los, + gpn_tx_burst, gpn_tx_dis, gpn_tx_fault, gpn_tx_sd, pps, pwm0, + pwm1, pwm2, pwm3, 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_tracectl_a, + qdss_tracedata_a, qrng_rosc0, qrng_rosc1, qrng_rosc2, + qspi_data, qspi_clk, qspi_cs_n, qup_se0, qup_se1, qup_se2, + qup_se3, qup_se4, qup_se5, qup_se5_l1, resout, rx_los0, rx_los1, + rx_los2, sdc_clk, sdc_cmd, sdc_data, tsens_max ] + + required: + - pins + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + tlmm: pinctrl@1000000 { + compatible = "qcom,ipq5210-tlmm"; + reg = <0x01000000 0x300000>; + gpio-controller; + #gpio-cells = <0x2>; + gpio-ranges = <&tlmm 0 0 54>; + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <0x2>; + + qup-uart1-default-state { + pins = "gpio38", "gpio39"; + function = "qup_se1"; + drive-strength = <6>; + bias-pull-down; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml index 619341dd637c..30f93b8159fd 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml @@ -27,6 +27,14 @@ properties: gpio-ranges: maxItems: 1 + gpio-reserved-ranges: + minItems: 1 + maxItems: 30 + description: + Pins can be reserved for trusted applications or for LPASS, thereby + inaccessible from the OS. This property can be used to mark the pins + which resources should not be accessed by the OS. + required: - gpio-controller - "#gpio-cells" diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,milos-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,milos-lpass-lpi-pinctrl.yaml new file mode 100644 index 000000000000..73e84f188591 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,milos-lpass-lpi-pinctrl.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,milos-lpass-lpi-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Milos SoC LPASS LPI TLMM + +maintainers: + - Luca Weiss <luca.weiss@fairphone.com> + +description: + Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem + (LPASS) Low Power Island (LPI) of Qualcomm Milos SoC. + +properties: + compatible: + const: qcom,milos-lpass-lpi-pinctrl + + reg: + items: + - description: LPASS LPI TLMM Control and Status registers + - description: LPASS LPI MCC registers + + clocks: + items: + - description: LPASS Core voting clock + - description: LPASS Audio voting clock + + clock-names: + items: + - const: core + - const: audio + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-milos-lpass-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-milos-lpass-state" + additionalProperties: false + +$defs: + qcom-milos-lpass-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + pattern: "^gpio([0-9]|1[0-9]|2[0-2])$" + + function: + enum: [ dmic1_clk, dmic1_data, dmic2_clk, dmic2_data, dmic3_clk, + dmic3_data, dmic4_clk, dmic4_data, ext_mclk1_a, ext_mclk1_b, + ext_mclk1_c, ext_mclk1_d, ext_mclk1_e, gpio, i2s0_clk, + i2s0_data, i2s0_ws, i2s1_clk, i2s1_data, i2s1_ws, i2s2_clk, + i2s2_data, i2s2_ws, i2s3_clk, i2s3_data, i2s3_ws, qca_swr_clk, + qca_swr_data, slimbus_clk, slimbus_data, swr_rx_clk, + swr_rx_data, swr_tx_clk, swr_tx_data, wsa_swr_clk, + wsa_swr_data ] + description: + Specify the alternative function to be configured for the specified + pins. + +allOf: + - $ref: qcom,lpass-lpi-common.yaml# + +required: + - compatible + - reg + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h> + + pinctrl@3440000 { + compatible = "qcom,milos-lpass-lpi-pinctrl"; + reg = <0x03440000 0x20000>, + <0x034d0000 0x10000>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&lpass_tlmm 0 0 23>; + + clocks = <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>, + <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>; + clock-names = "core", + "audio"; + + tx-swr-active-clk-state { + pins = "gpio0"; + function = "swr_tx_clk"; + drive-strength = <4>; + slew-rate = <1>; + bias-disable; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml new file mode 100644 index 000000000000..c76ad70e6b9f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SDM670 SoC LPASS LPI TLMM + +maintainers: + - Richard Acayan <mailingradian@gmail.com> + +description: + Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem + (LPASS) Low Power Island (LPI) of Qualcomm SDM670 SoC. + +properties: + compatible: + const: qcom,sdm670-lpass-lpi-pinctrl + + reg: + items: + - description: LPASS LPI TLMM Control and Status registers + +patternProperties: + "-state$": + oneOf: + - $ref: "#/$defs/qcom-sdm670-lpass-state" + - patternProperties: + "-pins$": + $ref: "#/$defs/qcom-sdm670-lpass-state" + additionalProperties: false + +$defs: + qcom-sdm670-lpass-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state + unevaluatedProperties: false + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + pattern: "^gpio([0-9]|1[0-9]|2[0-9]|3[0-1])$" + + function: + enum: [ gpio, comp_rx, dmic1_clk, dmic1_data, dmic2_clk, dmic2_data, + i2s1_clk, i2s_data, i2s_ws, lpi_cdc_rst, mclk0, pdm_rx, + pdm_sync, pdm_tx, slimbus_clk ] + description: + Specify the alternative function to be configured for the specified + pins. + +allOf: + - $ref: qcom,lpass-lpi-common.yaml# + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + lpi_tlmm: pinctrl@62b40000 { + compatible = "qcom,sdm670-lpass-lpi-pinctrl"; + reg = <0x62b40000 0x20000>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&lpi_tlmm 0 0 32>; + + cdc_comp_default: cdc-comp-default-state { + pins = "gpio22", "gpio24"; + function = "comp_rx"; + drive-strength = <4>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml index e7565592da86..541c1c54ddb0 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-lpass-lpi-pinctrl.yaml @@ -15,7 +15,13 @@ description: properties: compatible: - const: qcom,sm8450-lpass-lpi-pinctrl + oneOf: + - const: qcom,sm8450-lpass-lpi-pinctrl + - items: + - enum: + - qcom,qcs8300-lpass-lpi-pinctrl + - qcom,sa8775p-lpass-lpi-pinctrl + - const: qcom,sm8450-lpass-lpi-pinctrl reg: items: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8650-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8650-lpass-lpi-pinctrl.yaml index 74df912e60ad..1bf08860a4ba 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8650-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8650-lpass-lpi-pinctrl.yaml @@ -19,7 +19,9 @@ properties: oneOf: - const: qcom,sm8650-lpass-lpi-pinctrl - items: - - const: qcom,sm8750-lpass-lpi-pinctrl + - enum: + - qcom,glymur-lpass-lpi-pinctrl + - qcom,sm8750-lpass-lpi-pinctrl - const: qcom,sm8650-lpass-lpi-pinctrl reg: diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml index 90bd49d87d2e..2a640e495cc7 100644 --- a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1315e-pinctrl.yaml @@ -135,8 +135,11 @@ patternProperties: realtek,duty-cycle: description: | - An integer describing the level to adjust output duty cycle, controlling - the proportion of positive and negative waveforms in nanoseconds. + An integer describing the level to adjust the output pulse width, it + provides a fixed nanosecond-level adjustment to the rising/falling + edges of an existing signal. It is used for Signal Integrity tuning + (adding/subtracting delay to fine-tune the high/low duration), rather + than generating a specific PWM frequency. Valid arguments are described as below: 0: 0ns 2: + 0.25ns diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml index b6211c8544ca..2136546adec8 100644 --- a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1319d-pinctrl.yaml @@ -134,8 +134,11 @@ patternProperties: realtek,duty-cycle: description: | - An integer describing the level to adjust output duty cycle, controlling - the proportion of positive and negative waveforms in nanoseconds. + An integer describing the level to adjust the output pulse width, it + provides a fixed nanosecond-level adjustment to the rising/falling + edges of an existing signal. It is used for Signal Integrity tuning + (adding/subtracting delay to fine-tune the high/low duration), rather + than generating a specific PWM frequency. Valid arguments are described as below: 0: 0ns 2: + 0.25ns diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml index e88bc649cc73..e8ea1362b16d 100644 --- a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1619b-pinctrl.yaml @@ -133,8 +133,11 @@ patternProperties: realtek,duty-cycle: description: | - An integer describing the level to adjust output duty cycle, controlling - the proportion of positive and negative waveforms in nanoseconds. + An integer describing the level to adjust the output pulse width, it + provides a fixed nanosecond-level adjustment to the rising/falling + edges of an existing signal. It is used for Signal Integrity tuning + (adding/subtracting delay to fine-tune the high/low duration), rather + than generating a specific PWM frequency. Valid arguments are described as below: 0: 0ns 2: + 0.25ns diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd1625-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1625-pinctrl.yaml new file mode 100644 index 000000000000..9562a043707e --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd1625-pinctrl.yaml @@ -0,0 +1,260 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2025 Realtek Semiconductor Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/realtek,rtd1625-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek DHC RTD1625 Pin Controller + +maintainers: + - Tzuyi Chang <tychang@realtek.com> + - Yu-Chun Lin <eleanor.lin@realtek.com> + +description: + The Realtek DHC RTD1625 is a high-definition media processor SoC. The + RTD1625 pin controller is used to control pin function, pull-up/down + resistors, drive strength, slew rate, Schmitt trigger, power source + (I/O output voltage), input threshold domain selection and a higher-VIL mode. + +properties: + compatible: + items: + - enum: + - realtek,rtd1625-iso-pinctrl + - realtek,rtd1625-main2-pinctrl + - realtek,rtd1625-isom-pinctrl + - realtek,rtd1625-ve4-pinctrl + + reg: + maxItems: 1 + +patternProperties: + '-pins$': + type: object + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + properties: + pins: + items: + enum: [gpio_0, gpio_1, gpio_2, gpio_3, gpio_4, gpio_5, gpio_6, + gpio_7, gpio_8, gpio_9, gpio_10, gpio_11, gpio_12, gpio_13, + gpio_14, gpio_15, gpio_16, gpio_17, gpio_18, gpio_19, gpio_20, + gpio_21, gpio_22, gpio_23, gpio_24, gpio_25, gpio_28, gpio_29, + gpio_30, gpio_31, gpio_32, gpio_33, gpio_34, gpio_35, gpio_40, + gpio_41, gpio_42, gpio_43, gpio_44, gpio_45, gpio_46, gpio_47, + gpio_48, gpio_49, gpio_50, gpio_51, gpio_52, gpio_53, gpio_54, + gpio_55, gpio_56, gpio_57, gpio_58, gpio_59, gpio_60, gpio_61, + gpio_62, gpio_63, gpio_64, gpio_65, gpio_66, gpio_67, gpio_80, + gpio_81, gpio_82, gpio_83, gpio_84, gpio_85, gpio_86, gpio_87, + gpio_88, gpio_89, gpio_90, gpio_91, gpio_92, gpio_93, gpio_94, + gpio_95, gpio_96, gpio_97, gpio_98, gpio_99, gpio_100, + gpio_101, gpio_102, gpio_103, gpio_104, gpio_105, gpio_106, + gpio_107, gpio_108, gpio_109, gpio_110, gpio_111, gpio_112, + gpio_128, gpio_129, gpio_130, gpio_131, gpio_132, gpio_133, + gpio_134, gpio_135, gpio_136, gpio_137, gpio_138, gpio_139, + gpio_140, gpio_141, gpio_142, gpio_143, gpio_144, gpio_145, + gpio_146, gpio_147, gpio_148, gpio_149, gpio_150, gpio_151, + gpio_152, gpio_153, gpio_154, gpio_155, gpio_156, gpio_157, + gpio_158, gpio_159, gpio_160, gpio_161, gpio_162, gpio_163, + gpio_164, gpio_165, ai_i2s1_loc, ao_i2s1_loc, arm_trace_dbg_en, + csi_vdsel, ejtag_acpu_loc, ejtag_aucpu0_loc, ejtag_aucpu1_loc, + ejtag_pcpu_loc, ejtag_scpu_loc, ejtag_ve2_loc, emmc_clk, + emmc_cmd, emmc_data_0, emmc_data_1, emmc_data_2, emmc_data_3, + emmc_data_4, emmc_data_5, emmc_data_6, emmc_data_7, + emmc_dd_sb, emmc_rst_n, etn_phy_loc, hif_clk, hif_data, + hif_en, hif_rdy, hi_width, i2c6_loc, ir_rx_loc, rgmii_vdsel, + sf_en, spdif_in_mode, spdif_loc, uart0_loc, usb_cc1, usb_cc2, + ve4_uart_loc] + + function: + enum: [gpio, ai_i2s0, ai_i2s2, ai_tdm0, ai_tdm1, ai_tdm2, ao_i2s0, + ao_i2s2, ao_tdm0, ao_tdm1, ao_tdm2, csi0, csi1, csi_1v2, csi_1v8, + csi_2v5, csi_3v3, dmic0, dmic1, dmic2, dptx_hpd, edptx_hdp, emmc, + gspi0, gspi1, gspi2, hi_width_1bit, hi_width_disable, i2c0, i2c1, + i2c3, i2c4, i2c5, i2c7, iso_tristate, pcie0, pcie1, pcm, pctrl, + pwm4, pwm5, pwm6, rgmii, rgmii_1v2, rgmii_1v8, rgmii_2v5, + rgmii_3v3, rmii, sd, sdio, sf_disable, sf_enable, + spdif_in_coaxial, spdif_in_gpio, spdif_out, spi, ts0, ts1, uart1, + uart2, uart3, uart4, uart5, uart6, uart7, uart8, uart9, uart10, + usb_cc1, usb_cc2, vi0_dtv, vi1_dtv, vtc_ao_i2s, vtc_dmic, + vtc_i2s, ai_i2s1_loc0, ai_i2s1_loc1, ao_i2s0_loc0, ao_i2s0_loc1, + ao_i2s1_loc0, ao_i2s1_loc1, ao_tdm1_loc0, ao_tdm1_loc1, + etn_led_loc0, etn_led_loc1, etn_phy_loc0, etn_phy_loc1, + i2c6_loc0, i2c6_loc1, ir_rx_loc0, ir_rx_loc1, pwm0_loc0, + pwm0_loc1, pwm0_loc2, pwm0_loc3, pwm1_loc0, pwm1_loc1, pwm2_loc0, + pwm2_loc1, pwm3_loc0, pwm3_loc1, spdif_loc0, spdif_loc1, + uart0_loc0, uart0_loc1, ve4_uart_loc0, ve4_uart_loc1, + ve4_uart_loc2, acpu_ejtag_loc0, acpu_ejtag_loc1, acpu_ejtag_loc2, + aucpu0_ejtag_loc0, aucpu0_ejtag_loc1, aucpu0_ejtag_loc2, + aucpu1_ejtag_loc0, aucpu1_ejtag_loc1, aucpu1_ejtag_loc2, + aupu0_ejtag_loc1, aupu1_ejtag_loc1, gpu_ejtag_loc0, + pcpu_ejtag_loc0, pcpu_ejtag_loc1, pcpu_ejtag_loc2, + scpu_ejtag_loc0, scpu_ejtag_loc1, scpu_ejtag_loc2, + ve2_ejtag_loc0, ve2_ejtag_loc1, ve2_ejtag_loc2, pll_test_loc0, + pll_test_loc1, dbg_out1, isom_dbg_out, arm_trace_debug_disable, + arm_trace_debug_enable] + + drive-strength: + enum: [4, 8] + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + input-voltage-microvolt: + description: | + Select the input receiver voltage domain for the pin. + Valid arguments are: + - 1800000: 1.8V input logic level + - 3300000: 3.3V input logic level + enum: [1800000, 3300000] + + drive-push-pull: true + + power-source: + description: | + Valid arguments are described as below: + 0: power supply of 1.8V + 1: power supply of 3.3V + enum: [0, 1] + + slew-rate: + description: | + Valid arguments are described as below: + 1: ~1ns falling time + 10: ~10ns falling time + 20: ~20ns falling time + 30: ~30ns falling time + enum: [1, 10, 20, 30] + + realtek,drive-strength-p: + description: | + Some of pins can be driven using the P-MOS and N-MOS transistor to + achieve finer adjustments. The block-diagram representation is as + follows: + VDD + | + ||--+ + +-----o|| P-MOS-FET + | ||--+ + IN --+ +----- out + | ||--+ + +------|| N-MOS-FET + ||--+ + | + GND + The driving strength of the P-MOS/N-MOS transistors impacts the + waveform's rise/fall times. Greater driving strength results in + shorter rise/fall times. Each P-MOS and N-MOS transistor offers + 8 configurable levels (0 to 7), with higher values indicating + greater driving strength, contributing to achieving the desired + speed. + + The realtek,drive-strength-p is used to control the driving strength + of the P-MOS output. + + This value is not a simple count of transistors. Instead, it + represents a weighted configuration. There is a base driving + capability (even at value 0), and each bit adds a different weight to + the total strength. The resulting current is non-linear and varies + significantly based on the IO voltage (1.8V vs 3.3V) and the specific + pad group. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + + realtek,drive-strength-n: + description: | + Similar to the realtek,drive-strength-p, the realtek,drive-strength-n + is used to control the driving strength of the N-MOS output. + + This property uses the same weighted configuration logic where values + 0-7 represent non-linear strength adjustments rather than a transistor + count. + + Higher values indicate greater driving strength, resulting in shorter + fall times. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + + realtek,duty-cycle: + description: | + An integer describing the level to adjust the output pulse width, it + provides a fixed nanosecond-level adjustment to the rising/falling + edges of an existing signal. It is used for Signal Integrity tuning + (adding/subtracting delay to fine-tune the high/low duration), rather + than generating a specific PWM frequency. + + Valid arguments are described as below: + 0: 0ns + 2: + 0.25ns + 3: + 0.5ns + 4: -0.25ns + 5: -0.5ns + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 2, 3, 4, 5] + + realtek,high-vil-microvolt: + description: | + The threshold value for the input receiver's LOW recognition (VIL). + + This property is used to address specific HDMI I2C compatibility + issues where some sinks (TVs) have weak pull-down capabilities and + fail to pull the bus voltage below the standard VIL threshold + (~0.7V). + + Setting this property to 1100000 (1.1V) enables a specialized input + receiver mode that raises the effective VIL threshold to improve + detection. + enum: [1100000] + + required: + - pins + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pinctrl@4e000 { + compatible = "realtek,rtd1625-iso-pinctrl"; + reg = <0x4e000 0x130>; + + emmc-hs200-pins { + pins = "emmc_clk", + "emmc_cmd", + "emmc_data_0", + "emmc_data_1", + "emmc_data_2", + "emmc_data_3", + "emmc_data_4", + "emmc_data_5", + "emmc_data_6", + "emmc_data_7"; + function = "emmc"; + realtek,drive-strength-p = <2>; + realtek,drive-strength-n = <2>; + }; + + i2c-0-pins { + pins = "gpio_12", + "gpio_13"; + function = "i2c0"; + drive-strength = <4>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml index f049013a4e0c..63993b20524f 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml @@ -83,6 +83,23 @@ definitions: input: true input-enable: true output-enable: true + bias-disable: true + bias-pull-down: true + bias-pull-up: true + input-schmitt-enable: true + input-schmitt-disable: true + slew-rate: + description: 0 is slow slew rate, 1 is fast slew rate + enum: [0, 1] + drive-strength-microamp: + description: | + Four discrete levels are supported (via registers DRCTLm), corresponding + to the following nominal values: + - 2500 (Low strength) + - 5000 (Middle strength) + - 9000 (High strength) + - 11800 (Ultra High strength) + enum: [2500, 5000, 9000, 11800] oneOf: - required: [pinmux] - required: [pins] diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml index 76e607281716..9b3cbeb54fed 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml @@ -50,6 +50,7 @@ properties: - rockchip,rk3568-pinctrl - rockchip,rk3576-pinctrl - rockchip,rk3588-pinctrl + - rockchip,rv1103b-pinctrl - rockchip,rv1108-pinctrl - rockchip,rv1126-pinctrl diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-hdp.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-hdp.yaml index 845b6b7b7552..8f8b4b68aaa3 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-hdp.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-hdp.yaml @@ -27,6 +27,12 @@ properties: clocks: maxItems: 1 + access-controllers: + minItems: 1 + items: + - description: debug configuration access controller + - description: access controller that manages the HDP as a peripheral + patternProperties: "^hdp[0-7]-pins$": type: object diff --git a/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml b/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml index a28e75a9cb6a..b97361ce2a00 100644 --- a/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml +++ b/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml @@ -20,6 +20,7 @@ properties: - allwinner,sun20i-d1-ppu - allwinner,sun55i-a523-pck-600 - allwinner,sun55i-a523-ppu + - allwinner,sun60i-a733-pck-600 reg: maxItems: 1 @@ -38,9 +39,23 @@ required: - compatible - reg - clocks - - resets - '#power-domain-cells' +allOf: + - if: + properties: + compatible: + contains: + enum: + - allwinner,sun8i-v853-ppu + - allwinner,sun20i-d1-ppu + - allwinner,sun55i-a523-pck-600 + - allwinner,sun55i-a523-ppu + + then: + required: + - resets + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml b/Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml index b9e43abaf8a4..66fc59b3c8b4 100644 --- a/Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml +++ b/Documentation/devicetree/bindings/power/mediatek,mt8196-gpufreq.yaml @@ -74,9 +74,18 @@ properties: "#clock-cells": const: 1 + "#nvmem-cell-cells": + const: 0 + "#power-domain-cells": const: 0 + shader-present: + type: object + +dependencies: + shader-present: [ "#nvmem-cell-cells" ] + required: - compatible - reg @@ -113,5 +122,9 @@ examples: "ccf", "fast-dvfs"; memory-region = <&gpueb_shared_memory>; #clock-cells = <1>; + #nvmem-cell-cells = <0>; #power-domain-cells = <0>; + + shader-present { + }; }; diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml index 9507b342a7ee..07f046277f8a 100644 --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml @@ -31,6 +31,7 @@ properties: - mediatek,mt8183-power-controller - mediatek,mt8186-power-controller - mediatek,mt8188-power-controller + - mediatek,mt8189-power-controller - mediatek,mt8192-power-controller - mediatek,mt8195-power-controller - mediatek,mt8196-hwv-hfrp-power-controller diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index 27af5b8aa134..0bf1e13a9964 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -17,7 +17,9 @@ properties: compatible: oneOf: - enum: + - qcom,eliza-rpmhpd - qcom,glymur-rpmhpd + - qcom,hawi-rpmhpd - qcom,kaanapali-rpmhpd - qcom,mdm9607-rpmpd - qcom,milos-rpmhpd diff --git a/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml new file mode 100644 index 000000000000..ef5e04f86be1 --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/cortina,gemini-power-controller.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/cortina,gemini-power-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cortina Systems Gemini Poweroff Controller + +maintainers: + - Linus Walleij <linusw@kernel.org> + +description: | + The Gemini power controller is a dedicated IP block in the Cortina Gemini SoC that + controls system power-down operations. + +properties: + compatible: + const: cortina,gemini-power-controller + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + poweroff@4b000000 { + compatible = "cortina,gemini-power-controller"; + reg = <0x4b000000 0x100>; + interrupts = <26 IRQ_TYPE_EDGE_FALLING>; + }; +... diff --git a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt deleted file mode 100644 index 7fec3e100214..000000000000 --- a/Documentation/devicetree/bindings/power/reset/gemini-poweroff.txt +++ /dev/null @@ -1,17 +0,0 @@ -* Device-Tree bindings for Cortina Systems Gemini Poweroff - -This is a special IP block in the Cortina Gemini SoC that only -deals with different ways to power the system down. - -Required properties: -- compatible: should be "cortina,gemini-power-controller" -- reg: should contain the physical memory base and size -- interrupts: should contain the power management interrupt - -Example: - -power-controller@4b000000 { - compatible = "cortina,gemini-power-controller"; - reg = <0x4b000000 0x100>; - interrupts = <26 IRQ_TYPE_EDGE_FALLING>; -}; diff --git a/Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml b/Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml index 694bfdb5815c..6dcca55d6d90 100644 --- a/Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml @@ -55,6 +55,7 @@ properties: - const: chg_isense - const: batti + monitored-battery: true power-supplies: true required: diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml index 14242de7fc08..242b33f2bcba 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17042.yaml @@ -20,6 +20,7 @@ properties: - maxim,max17050 - maxim,max17055 - maxim,max77705-battery + - maxim,max77759-fg - maxim,max77849-battery reg: @@ -27,36 +28,42 @@ properties: interrupts: maxItems: 1 - description: | - The ALRT pin, an open-drain interrupt. + description: + The ALRT pin (or FG_INTB pin on MAX77759), an open-drain interrupt. + + shunt-resistor-micro-ohms: + description: + Resistance of rsns resistor in micro Ohms (datasheet-recommended value is 10000). + Defining this property enables current-sense functionality. maxim,rsns-microohm: + deprecated: true $ref: /schemas/types.yaml#/definitions/uint32 - description: | + description: Resistance of rsns resistor in micro Ohms (datasheet-recommended value is 10000). Defining this property enables current-sense functionality. maxim,cold-temp: $ref: /schemas/types.yaml#/definitions/uint32 - description: | + description: Temperature threshold to report battery as cold (in tenths of degree Celsius). Default is not to report cold events. maxim,over-heat-temp: $ref: /schemas/types.yaml#/definitions/uint32 - description: | + description: Temperature threshold to report battery as over heated (in tenths of degree Celsius). Default is not to report over heating events. maxim,dead-volt: $ref: /schemas/types.yaml#/definitions/uint32 - description: | + description: Voltage threshold to report battery as dead (in mV). Default is not to report dead battery events. maxim,over-volt: $ref: /schemas/types.yaml#/definitions/uint32 - description: | + description: Voltage threshold to report battery as over voltage (in mV). Default is not to report over-voltage events. diff --git a/Documentation/devicetree/bindings/power/supply/samsung,s2mu005-fuel-gauge.yaml b/Documentation/devicetree/bindings/power/supply/samsung,s2mu005-fuel-gauge.yaml new file mode 100644 index 000000000000..05e420316a26 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/samsung,s2mu005-fuel-gauge.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/samsung,s2mu005-fuel-gauge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Battery Fuel Gauge for Samsung S2M series PMICs + +maintainers: + - Kaustabh Chakraborty <kauschluss@disroot.org> + +allOf: + - $ref: power-supply.yaml# + +properties: + compatible: + enum: + - samsung,s2mu005-fuel-gauge + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + fuel-gauge@3b { + compatible = "samsung,s2mu005-fuel-gauge"; + reg = <0x3b>; + + interrupt-parent = <&gpa0>; + interrupts = <3 IRQ_TYPE_EDGE_BOTH>; + + monitored-battery = <&battery>; + }; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml index cc3ebd4deeb6..c337d85da40f 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-amlogic.yaml @@ -39,7 +39,10 @@ properties: - amlogic,meson-s4-pwm - items: - enum: + - amlogic,a4-pwm + - amlogic,a5-pwm - amlogic,c3-pwm + - amlogic,t7-pwm - amlogic,meson-a1-pwm - const: amlogic,meson-s4-pwm - items: diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt deleted file mode 100644 index 36f5e2f5cc0f..000000000000 --- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt +++ /dev/null @@ -1,35 +0,0 @@ -Motorola CPCAP PMIC voltage regulators ------------------------------------- - -Requires node properties: -- "compatible" value one of: - "motorola,cpcap-regulator" - "motorola,mapphone-cpcap-regulator" - "motorola,xoom-cpcap-regulator" - -Required regulator properties: -- "regulator-name" -- "regulator-enable-ramp-delay" -- "regulator-min-microvolt" -- "regulator-max-microvolt" - -Optional regulator properties: -- "regulator-boot-on" - -See Documentation/devicetree/bindings/regulator/regulator.txt -for more details about the regulator properties. - -Example: - -cpcap_regulator: regulator { - compatible = "motorola,cpcap-regulator"; - - cpcap_regulators: regulators { - sw5: SW5 { - regulator-min-microvolt = <5050000>; - regulator-max-microvolt = <5050000>; - regulator-enable-ramp-delay = <50000>; - regulator-boot-on; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml index 13b3f75f8e5e..ce76eb5b85bd 100644 --- a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml +++ b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml @@ -81,6 +81,14 @@ properties: Specify the polling period, measured in milliseconds, between interrupt status update checks. Range 1000-10000 ms. + dlg,no-gpio-control: + type: boolean + description: | + Available GPIO input pins of the regulator are strapped to fixed levels, therefore + GPIO configurable input functions, DVC/RELOAD/EN, cannot dynamically update BUCK + registers. GPIO pins connected as output pins are not required to be strapped to a + fixed level. Not allowed together with enable-gpios. + regulators: type: object additionalProperties: false @@ -134,6 +142,17 @@ allOf: properties: buck2: false + - if: + required: + - dlg,no-gpio-control + then: + properties: + regulators: + patternProperties: + "^buck([1-2])$": + properties: + enable-gpios: false + additionalProperties: false examples: @@ -169,6 +188,36 @@ examples: }; - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/regulator/dlg,da9121-regulator.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + pmic@68 { + compatible = "dlg,da9121"; + reg = <0x68>; + + interrupt-parent = <&gpio6>; + interrupts = <11 IRQ_TYPE_LEVEL_LOW>; + + dlg,irq-polling-delay-passive-ms = <2000>; + dlg,no-gpio-control; + + regulators { + DA9121_BUCK: buck1 { + regulator-name = "BUCK1"; + regulator-min-microvolt = <300000>; + regulator-max-microvolt = <1900000>; + regulator-min-microamp = <7000000>; + regulator-max-microamp = <20000000>; + regulator-boot-on; + regulator-initial-mode = <DA9121_BUCK_MODE_AUTO>; + }; + }; + }; + }; + + - | #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/regulator/dlg,da9121-regulator.h> diff --git a/Documentation/devicetree/bindings/regulator/fitipower,fp9931.yaml b/Documentation/devicetree/bindings/regulator/fitipower,fp9931.yaml index c6585e3bacbe..00d66b923047 100644 --- a/Documentation/devicetree/bindings/regulator/fitipower,fp9931.yaml +++ b/Documentation/devicetree/bindings/regulator/fitipower,fp9931.yaml @@ -66,6 +66,7 @@ properties: required: - compatible - reg + - vin-supply - pg-gpios - enable-gpios diff --git a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml index 5a6491a81fda..c2bafbc1e9e1 100644 --- a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml @@ -24,6 +24,9 @@ properties: maxItems: 1 description: Identifier for the voltage regulator to ChromeOS EC. + vin-supply: + description: Input supply phandle + required: - compatible - reg @@ -48,6 +51,7 @@ examples: regulator-min-microvolt = <1800000>; regulator-max-microvolt = <3300000>; reg = <0>; + vin-supply = <&pp4200_s5>; }; }; }; diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml new file mode 100644 index 000000000000..7118c34961ba --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max77620-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Regulator for MAX77620 Power management IC from Maxim Semiconductor. + +maintainers: + - Svyatoslav Ryhel <clamor95@gmail.com> + +description: + Device has multiple DCDC(sd[0-3]) and LDOs(ldo[0-8]). The input supply + of these regulators are defined under parent device node. Details of + regulator properties are defined as child node under sub-node "regulators" + which is child node of device node. + +patternProperties: + "^in-(sd[0-3]|ldo(0-1|2|3-5|4-6|7-8))-supply$": + $ref: /schemas/types.yaml#/definitions/phandle + description: Input supply for DCDC or LDO + + "^(sd[0-3]|ldo[0-8])$": + type: object + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + + properties: + maxim,active-fps-source: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + FPS source for the GPIOs to get enabled/disabled when system is in + active state. Valid values are: + - MAX77620_FPS_SRC_0: FPS source is FPS0. + - MAX77620_FPS_SRC_1: FPS source is FPS1 + - MAX77620_FPS_SRC_2: FPS source is FPS2 + - MAX77620_FPS_SRC_NONE: GPIO is not controlled by FPS events and + it gets enabled/disabled by register access. + Absence of this property will leave the FPS configuration register + for that GPIO to default configuration. + + maxim,active-fps-power-up-slot: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Sequencing event slot number on which the GPIO get enabled when + master FPS input event set to HIGH. This is applicable if FPS source + is selected as FPS0, FPS1 or FPS2. + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + maxim,active-fps-power-down-slot: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Sequencing event slot number on which the GPIO get disabled when + master FPS input event set to LOW. This is applicable if FPS source + is selected as FPS0, FPS1 or FPS2. + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + maxim,suspend-fps-source: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + This is same as property "maxim,active-fps-source" but value get + configured when system enters in to suspend state. + + maxim,suspend-fps-power-up-slot: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + This is same as property "maxim,active-fps-power-up-slot" but this + value get configured into FPS configuration register when system + enters into suspend. This is applicable if suspend state FPS source + is selected as FPS0, FPS1 or FPS2. + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + maxim,suspend-fps-power-down-slot: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + This is same as property "maxim,active-fps-power-down-slot" but this + value get configured into FPS configuration register when system + enters into suspend. This is applicable if suspend state FPS source + is selected as FPS0, FPS1 or FPS2. + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + maxim,ramp-rate-setting: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Ramp rate(uV/us) setting to be configured to the device. The platform + may have different ramp rate than advertised ramp rate if it has design + variation from Maxim's recommended. On this case, platform specific + ramp rate is used for ramp time calculation and this property is used + for device register configurations. The measured ramp rate of platform + is provided by the regulator-ramp-delay. + + Maxim Max77620 supports following ramp delay: + SD: 13.75mV/us, 27.5mV/us, 55mV/us + LDOs: 5mV/us, 100mV/us + enum: [5000, 13750, 27500, 55000, 100000] + +additionalProperties: false + +# see maxim,max77620.yaml for an example diff --git a/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml new file mode 100644 index 000000000000..1a44c8e61243 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/motorola,cpcap-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Motorola CPCAP PMIC regulators + +maintainers: + - Svyatoslav Ryhel <clamor95@gmail.com> + +description: + This module is part of the Motorola CPCAP MFD device. For more details + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The + regulator controller is represented as a sub-node of the PMIC node + on the device tree. + +properties: + compatible: + enum: + - motorola,cpcap-regulator + - motorola,mapphone-cpcap-regulator + - motorola,mot-cpcap-regulator + - motorola,xoom-cpcap-regulator + + regulators: + type: object + + patternProperties: + "^(SW[1-6]|V(CAM|CSI|DAC|DIG|FUSE|HVIO|SDIO|PLL|RF[12]|RFREF|WLAN[12]|SIM|SIMCARD|VIB|USB|AUDIO))$": + $ref: /schemas/regulator/regulator.yaml# + type: object + + required: + - regulator-name + - regulator-enable-ramp-delay + - regulator-min-microvolt + - regulator-max-microvolt + + unevaluatedProperties: false + +required: + - compatible + +additionalProperties: false + +... diff --git a/Documentation/devicetree/bindings/regulator/mp8859.txt b/Documentation/devicetree/bindings/regulator/mp8859.txt deleted file mode 100644 index 74ad69730989..000000000000 --- a/Documentation/devicetree/bindings/regulator/mp8859.txt +++ /dev/null @@ -1,22 +0,0 @@ -Monolithic Power Systems MP8859 voltage regulator - -Required properties: -- compatible: "mps,mp8859"; -- reg: I2C slave address. - -Optional subnode for regulator: "mp8859_dcdc", using common regulator -bindings given in <Documentation/devicetree/bindings/regulator/regulator.txt>. - -Example: - - mp8859: regulator@66 { - compatible = "mps,mp8859"; - reg = <0x66>; - dc_12v: mp8859_dcdc { - regulator-name = "dc_12v"; - regulator-min-microvolt = <12000000>; - regulator-max-microvolt = <12000000>; - regulator-boot-on; - regulator-always-on; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/mps,mp8859.yaml b/Documentation/devicetree/bindings/regulator/mps,mp8859.yaml new file mode 100644 index 000000000000..523498adf003 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/mps,mp8859.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/mps,mp8859.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Monolithic Power Systems MP8859 Voltage Regulator + +maintainers: + - Markus Reichl <reichl@t-online.de> + +description: + The MP8859 is a synchronous, 4-switch, integrated buck-boost converter + capable of regulating the output voltage from 2.8V to 22V wide input voltage + range with high efficiency. + +properties: + compatible: + const: mps,mp8859 + + reg: + maxItems: 1 + + mp8859_dcdc: + $ref: /schemas/regulator/regulator.yaml# + type: object + description: DCDC regulator subnode + unevaluatedProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@66 { + compatible = "mps,mp8859"; + reg = <0x66>; + + mp8859_dcdc { + regulator-name = "dc_12v"; + regulator-min-microvolt = <12000000>; + regulator-max-microvolt = <12000000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml index fa6743bb269d..1c63265907f1 100644 --- a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml @@ -25,6 +25,15 @@ properties: reg: maxItems: 1 + pvdd1-supply: + description: Supply for regulator vbuck1 + pvdd2-supply: + description: Supply for regulator vbuck2 + pvdd3-supply: + description: Supply for regulator vbuck3 + pvdd4-supply: + description: Supply for regulator vbuck4 + regulators: type: object description: List of regulators and its properties @@ -49,8 +58,11 @@ examples: pmic@6 { compatible = "mediatek,mt6315-regulator"; reg = <0x6 0>; + pvdd1-supply = <&pp4200_z2>; + pvdd3-supply = <&pp4200_z2>; regulators { + vbuck1 { regulator-min-microvolt = <300000>; regulator-max-microvolt = <1193750>; diff --git a/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml b/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml index 47c425c9fff1..105174df7df2 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,qca6390-pmu.yaml @@ -16,11 +16,17 @@ description: properties: compatible: - enum: - - qcom,qca6390-pmu - - qcom,wcn6750-pmu - - qcom,wcn6855-pmu - - qcom,wcn7850-pmu + oneOf: + - items: + - enum: + - qcom,wcn6755-pmu + - const: qcom,wcn6750-pmu + + - enum: + - qcom,qca6390-pmu + - qcom,wcn6750-pmu + - qcom,wcn6855-pmu + - qcom,wcn7850-pmu vdd-supply: description: VDD supply regulator handle diff --git a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt b/Documentation/devicetree/bindings/regulator/regulator-max77620.txt deleted file mode 100644 index bcf788897e44..000000000000 --- a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt +++ /dev/null @@ -1,222 +0,0 @@ -Regulator DT binding for MAX77620 Power management IC from Maxim Semiconductor. - -Device has multiple DCDC(sd[0-3] and LDOs(ldo[0-8]). The input supply -of these regulators are defined under parent device node. -Details of regulator properties are defined as child node under -sub-node "regulators" which is child node of device node. - -Please refer file <Documentation/devicetree/bindings/regulator/regulator.txt> -for common regulator bindings used by client. - -Following are properties of parent node related to regulators. - -Optional properties: -------------------- -The input supply of regulators are the optional properties on the -parent device node. The input supply of these regulators are provided -through following properties: -in-sd0-supply: Input supply for SD0, INA-SD0 or INB-SD0 pins. -in-sd1-supply: Input supply for SD1. -in-sd2-supply: Input supply for SD2. -in-sd3-supply: Input supply for SD3. -in-ldo0-1-supply: Input supply for LDO0 and LDO1. -in-ldo2-supply: Input supply for LDO2. -in-ldo3-5-supply: Input supply for LDO3 and LDO5 -in-ldo4-6-supply: Input supply for LDO4 and LDO6. -in-ldo7-8-supply: Input supply for LDO7 and LDO8. - -Optional sub nodes for regulators under "regulators" subnode: ------------------------------------------------------------- -The subnodes name is the name of regulator and it must be one of: - sd[0-3], ldo[0-8] - -Each sub-node should contain the constraints and initialization -information for that regulator. The definition for each of these -nodes is defined using the standard binding for regulators found at -<Documentation/devicetree/bindings/regulator/regulator.txt>. - -There are also additional properties for SD/LDOs. These additional properties -are required to configure FPS configuration parameters for SDs and LDOs. -Please refer <devicetree/bindings/mfd/max77620.txt> for more detail of Flexible -Power Sequence (FPS). -Following are additional properties: - -- maxim,active-fps-source: FPS source for the regulators to get - enabled/disabled when system is in - active state. Valid values are: - - MAX77620_FPS_SRC_0, - FPS source is FPS0. - - MAX77620_FPS_SRC_1, - FPS source is FPS1 - - MAX77620_FPS_SRC_2 and - FPS source is FPS2 - - MAX77620_FPS_SRC_NONE. - Regulator is not controlled - by FPS events and it gets - enabled/disabled by register - access. - Absence of this property will leave - the FPS configuration register for that - regulator to default configuration. - -- maxim,active-fps-power-up-slot: Sequencing event slot number on which - the regulator get enabled when - master FPS input event set to HIGH. - Valid values are 0 to 7. - This is applicable if FPS source is - selected as FPS0, FPS1 or FPS2. - -- maxim,active-fps-power-down-slot: Sequencing event slot number on which - the regulator get disabled when master - FPS input event set to LOW. - Valid values are 0 to 7. - This is applicable if FPS source is - selected as FPS0, FPS1 or FPS2. - -- maxim,suspend-fps-source: This is same as property - "maxim,active-fps-source" but value - get configured when system enters in - to suspend state. - -- maxim,suspend-fps-power-up-slot: This is same as property - "maxim,active-fps-power-up-slot" but - this value get configured into FPS - configuration register when system - enters into suspend. - This is applicable if suspend state - FPS source is selected as FPS0, FPS1 or - -- maxim,suspend-fps-power-down-slot: This is same as property - "maxim,active-fps-power-down-slot" but - this value get configured into FPS - configuration register when system - enters into suspend. - This is applicable if suspend state - FPS source is selected as FPS0, FPS1 or - FPS2. -- maxim,ramp-rate-setting: integer, ramp rate(uV/us) setting to be - configured to the device. - The platform may have different ramp - rate than advertised ramp rate if it has - design variation from Maxim's - recommended. On this case, platform - specific ramp rate is used for ramp time - calculation and this property is used - for device register configurations. - The measured ramp rate of platform is - provided by the regulator-ramp-delay - as described in <devicetree/bindings/ - regulator/regulator.txt>. - Maxim Max77620 supports following ramp - delay: - SD: 13.75mV/us, 27.5mV/us, 55mV/us - LDOs: 5mV/us, 100mV/us - -Note: If the measured ramp delay is same as advertised ramp delay then it is not -required to provide the ramp delay with property "maxim,ramp-rate-setting". The -ramp rate can be provided by the regulator-ramp-delay which will be used for -ramp time calculation for voltage change as well as for device configuration. - -Example: --------- -#include <dt-bindings/mfd/max77620.h> -... -max77620@3c { - in-ldo0-1-supply = <&max77620_sd2>; - in-ldo7-8-supply = <&max77620_sd2>; - regulators { - sd0 { - regulator-name = "vdd-core"; - regulator-min-microvolt = <600000>; - regulator-max-microvolt = <1400000>; - regulator-boot-on; - regulator-always-on; - maxim,active-fps-source = <MAX77620_FPS_SRC_1>; - }; - - sd1 { - regulator-name = "vddio-ddr"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <1200000>; - regulator-always-on; - regulator-boot-on; - maxim,active-fps-source = <MAX77620_FPS_SRC_0>; - }; - - sd2 { - regulator-name = "vdd-pre-reg"; - regulator-min-microvolt = <1350000>; - regulator-max-microvolt = <1350000>; - }; - - sd3 { - regulator-name = "vdd-1v8"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-always-on; - regulator-boot-on; - }; - - ldo0 { - regulator-name = "avdd-sys"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <1200000>; - regulator-always-on; - regulator-boot-on; - }; - - ldo1 { - regulator-name = "vdd-pex"; - regulator-min-microvolt = <1050000>; - regulator-max-microvolt = <1050000>; - }; - - ldo2 { - regulator-name = "vddio-sdmmc3"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - }; - - ldo3 { - regulator-name = "vdd-cam-hv"; - regulator-min-microvolt = <2800000>; - regulator-max-microvolt = <2800000>; - }; - - ldo4 { - regulator-name = "vdd-rtc"; - regulator-min-microvolt = <1250000>; - regulator-max-microvolt = <1250000>; - regulator-always-on; - regulator-boot-on; - }; - - ldo5 { - regulator-name = "avdd-ts-hv"; - regulator-min-microvolt = <3000000>; - regulator-max-microvolt = <3000000>; - }; - - ldo6 { - regulator-name = "vdd-ts"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-always-on; - regulator-boot-on; - }; - - ldo7 { - regulator-name = "vdd-gen-pll-edp"; - regulator-min-microvolt = <1050000>; - regulator-max-microvolt = <1050000>; - regulator-always-on; - regulator-boot-on; - }; - - ldo8 { - regulator-name = "vdd-hdmi-dp"; - regulator-min-microvolt = <1050000>; - regulator-max-microvolt = <1050000>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,milos-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,milos-pas.yaml index c47d97004b33..e5cce0d05fc6 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,milos-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,milos-pas.yaml @@ -16,6 +16,7 @@ description: properties: compatible: enum: + - qcom,eliza-adsp-pas - qcom,milos-adsp-pas - qcom,milos-cdsp-pas - qcom,milos-mpss-pas @@ -69,6 +70,7 @@ allOf: properties: compatible: enum: + - qcom,eliza-adsp-pas - qcom,milos-adsp-pas - qcom,milos-cdsp-pas then: @@ -89,6 +91,7 @@ allOf: compatible: contains: enum: + - qcom,eliza-adsp-pas - qcom,milos-adsp-pas then: properties: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml index c179b560572b..faf2712e3d27 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml @@ -17,10 +17,14 @@ properties: compatible: oneOf: - enum: + - qcom,mdm9607-mss-pil - qcom,msm8226-mss-pil - qcom,msm8909-mss-pil - qcom,msm8916-mss-pil + - qcom,msm8917-mss-pil - qcom,msm8926-mss-pil + - qcom,msm8937-mss-pil + - qcom,msm8940-mss-pil - qcom,msm8953-mss-pil - qcom,msm8974-mss-pil @@ -89,7 +93,7 @@ properties: description: PLL proxy supply (control handed over after startup) mss-supply: - description: MSS power domain supply (only valid for qcom,msm8974-mss-pil) + description: MSS power domain supply resets: items: @@ -137,7 +141,6 @@ properties: - description: MPSS reserved region firmware-name: - $ref: /schemas/types.yaml#/definitions/string-array items: - description: Name of MBA firmware - description: Name of modem firmware @@ -226,8 +229,12 @@ allOf: compatible: contains: enum: + - qcom,mdm9607-mss-pil - qcom,msm8909-mss-pil - qcom,msm8916-mss-pil + - qcom,msm8917-mss-pil + - qcom,msm8937-mss-pil + - qcom,msm8940-mss-pil then: properties: power-domains: @@ -271,6 +278,9 @@ allOf: contains: enum: - qcom,msm8926-mss-pil + - qcom,msm8917-mss-pil + - qcom,msm8937-mss-pil + - qcom,msm8940-mss-pil - qcom,msm8974-mss-pil then: required: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml index 4d2055f283ac..1b65813cc8ad 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml @@ -126,7 +126,6 @@ properties: - description: Metadata reserved region firmware-name: - $ref: /schemas/types.yaml#/definitions/string-array items: - description: Name of MBA firmware - description: Name of modem firmware diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml index 188a25194000..bcd2bcf96e24 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sa8775p-pas.yaml @@ -51,7 +51,6 @@ properties: description: Reference to the AOSS side-channel message RAM. firmware-name: - $ref: /schemas/types.yaml#/definitions/string-array items: - description: Firmware name of the Hexagon core diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml index b1402bef0ebe..7c9accac92d0 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml @@ -98,7 +98,6 @@ properties: - description: metadata reserved region firmware-name: - $ref: /schemas/types.yaml#/definitions/string-array items: - description: Name of MBA firmware - description: Name of modem firmware diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml index 005cb21732af..f349c303fa07 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml @@ -98,7 +98,6 @@ properties: - description: metadata reserved region firmware-name: - $ref: /schemas/types.yaml#/definitions/string-array items: - description: Name of MBA firmware - description: Name of modem firmware diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml index 5dbda3a55047..8227527c1d77 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc8280xp-pas.yaml @@ -42,7 +42,7 @@ properties: description: Reference to the reserved-memory for the Hexagon core firmware-name: - $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 description: Firmware name for the Hexagon core required: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml index 5d463272165f..8c4abde74915 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdx55-pas.yaml @@ -56,7 +56,7 @@ properties: smd-edge: false firmware-name: - $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 description: Firmware name for the Hexagon core required: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml index 11b056d6a480..1e4db0c9fcf9 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml @@ -28,9 +28,17 @@ properties: - qcom,x1e80100-adsp-pas - qcom,x1e80100-cdsp-pas - items: - - const: qcom,sm8750-adsp-pas + - enum: + - qcom,glymur-adsp-pas + - qcom,kaanapali-adsp-pas + - qcom,sm8750-adsp-pas - const: qcom,sm8550-adsp-pas - items: + - enum: + - qcom,glymur-cdsp-pas + - qcom,kaanapali-cdsp-pas + - const: qcom,sm8550-cdsp-pas + - items: - const: qcom,sm8750-cdsp-pas - const: qcom,sm8650-cdsp-pas @@ -52,7 +60,6 @@ properties: smd-edge: false firmware-name: - $ref: /schemas/types.yaml#/definitions/string-array items: - description: Firmware name of the Hexagon core - description: Firmware name of the Hexagon Devicetree @@ -95,6 +102,10 @@ allOf: compatible: contains: enum: + - qcom,glymur-adsp-pas + - qcom,glymur-cdsp-pas + - qcom,kaanapali-adsp-pas + - qcom,kaanapali-cdsp-pas - qcom,sm8750-adsp-pas then: properties: diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index a927551356e6..775e9b3a1938 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -154,17 +154,44 @@ patternProperties: memory-region: description: | phandle to the reserved memory nodes to be associated with the - remoteproc device. There should be at least two reserved memory nodes - defined. The reserved memory nodes should be carveout nodes, and - should be defined with a "no-map" property as per the bindings in + remoteproc device. There should be two reserved memory nodes defined + for the basic layout or 6 partitions for a detailed layout. The + reserved memory nodes should be carveout nodes, and should be defined + with a "no-map" property as per the bindings in Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt - minItems: 2 - maxItems: 8 - items: - - description: region used for dynamic DMA allocations like vrings and - vring buffers - - description: region reserved for firmware image sections - additionalItems: true + oneOf: + - description: Basic layout + items: + - description: region used for dynamic DMA allocations like vrings and + vring buffers + - description: region reserved for firmware image sections + - description: Detailed layout + items: + - description: region used for dynamic DMA allocations like vrings and + vring buffers + - description: region reserved for IPC resources + - description: LPM FS stub binary + - description: LPM metadata + - description: LPM FS context data and reserved sections + - description: DM RM/PM trace and firmware code/data + + memory-region-names: + description: | + Names for the memory regions specified in the memory-region property. + The names must correspond with the entries in memory-region. + oneOf: + - description: Basic layout + items: + - const: dma + - const: firmware + - description: Detailed layout + items: + - const: dma + - const: ipc + - const: lpm-stub + - const: lpm-metadata + - const: lpm-context + - const: dm-firmware # Optional properties: # -------------------- @@ -218,6 +245,13 @@ patternProperties: - resets - firmware-name + if: + required: + - memory-region + then: + required: + - memory-region-names + unevaluatedProperties: false allOf: @@ -321,6 +355,7 @@ examples: mboxes = <&mailbox0 &mbox_mcu_r5fss0_core0>; memory-region = <&mcu_r5fss0_core0_dma_memory_region>, <&mcu_r5fss0_core0_memory_region>; + memory-region-names = "dma", "firmware"; sram = <&mcu_r5fss0_core0_sram>; }; diff --git a/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml b/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml index c1b800a10b53..66650ef8f772 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml +++ b/Documentation/devicetree/bindings/reset/renesas,rzv2h-usb2phy-reset.yaml @@ -17,7 +17,9 @@ properties: compatible: oneOf: - items: - - const: renesas,r9a09g056-usb2phy-reset # RZ/V2N + - enum: + - renesas,r9a09g047-usb2phy-reset # RZ/G3E + - renesas,r9a09g056-usb2phy-reset # RZ/V2N - const: renesas,r9a09g057-usb2phy-reset - const: renesas,r9a09g057-usb2phy-reset # RZ/V2H(P) @@ -37,6 +39,9 @@ properties: '#reset-cells': const: 0 + '#mux-state-cells': + const: 1 + required: - compatible - reg @@ -44,6 +49,7 @@ required: - resets - power-domains - '#reset-cells' + - '#mux-state-cells' additionalProperties: false @@ -58,4 +64,5 @@ examples: resets = <&cpg 0xaf>; power-domains = <&cpg>; #reset-cells = <0>; + #mux-state-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml index c6ec9290fe07..2b0a8a93bb21 100644 --- a/Documentation/devicetree/bindings/riscv/extensions.yaml +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml @@ -262,6 +262,23 @@ properties: ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87 ("Updated to ratified state.") + - const: supm + description: | + The standard Supm extension for pointer masking support in user + mode (U-mode) as ratified at commit d70011dde6c2 ("Update to + ratified state") of riscv-j-extension. + + Supm represents a combination of underlying hardware capability + (Smnpm or Ssnpm), U-mode consumer privilege level, and M/S-mode + software configuration that enables pointer masking for U-mode. + + DO NOT include this property in device trees targeting privileged + system software (S-mode or M-mode). + + This property is only appropriate in device trees provided to + U-mode software where the next-higher-privilege-mode supports + Smnpm or Ssnpm and enables it for U-mode. + - const: svade description: | The standard Svade supervisor-level extension for SW-managed PTE A/D @@ -907,6 +924,16 @@ properties: then: contains: const: b + # Supm depends on Smnpm or Ssnpm + - if: + contains: + const: supm + then: + oneOf: + - contains: + const: smnpm + - contains: + const: ssnpm # Za64rs and Ziccrse depend on Zalrsc or A - if: contains: diff --git a/Documentation/devicetree/bindings/riscv/microchip.yaml b/Documentation/devicetree/bindings/riscv/microchip.yaml index 381d6eb6672e..137a6f413430 100644 --- a/Documentation/devicetree/bindings/riscv/microchip.yaml +++ b/Documentation/devicetree/bindings/riscv/microchip.yaml @@ -4,14 +4,14 @@ $id: http://devicetree.org/schemas/riscv/microchip.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Microchip PolarFire SoC-based boards +title: Microchip SoC-based boards maintainers: - Conor Dooley <conor.dooley@microchip.com> - Daire McNamara <daire.mcnamara@microchip.com> description: - Microchip PolarFire SoC-based boards + Microchip SoC-based boards properties: $nodename: @@ -46,6 +46,9 @@ properties: - microchip,mpfs-sev-kit - sundance,polarberry - const: microchip,mpfs + - items: + - const: microchip,pic64gx-curiosity-kit + - const: microchip,pic64gx additionalProperties: true diff --git a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml index f78614100ea8..3628251b8c51 100644 --- a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml +++ b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml @@ -19,6 +19,7 @@ properties: - microchip,sam9x60-trng - items: - enum: + - microchip,lan9691-trng - microchip,sama7g5-trng - const: atmel,at91sam9g45-trng - items: diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index 73851f19330d..bb7b9c87a807 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -63,7 +63,9 @@ allOf: properties: compatible: contains: - const: spacemit,k1-uart + enum: + - spacemit,k1-uart + - spacemit,k3-uart then: properties: clock-names: @@ -76,6 +78,7 @@ allOf: contains: enum: - spacemit,k1-uart + - spacemit,k3-uart - nxp,lpc1850-uart then: required: @@ -179,6 +182,7 @@ properties: - const: ns16550a - items: - enum: + - loongson,ls3a4000-uart - loongson,ls3a5000-uart - loongson,ls3a6000-uart - loongson,ls2k2000-uart diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml index d8ad1bb6172d..a2702319685d 100644 --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml @@ -56,6 +56,7 @@ properties: items: - enum: - amlogic,a4-uart + - amlogic,a9-uart - amlogic,s6-uart - amlogic,s7-uart - amlogic,s7d-uart diff --git a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml index 087a8926f8b4..375cd50bc5cc 100644 --- a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml +++ b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml @@ -24,6 +24,7 @@ properties: - const: atmel,at91sam9260-usart - items: - enum: + - microchip,lan9691-usart - microchip,sam9x60-usart - microchip,sam9x7-usart - microchip,sama7d65-usart diff --git a/Documentation/devicetree/bindings/serial/renesas,rsci.yaml b/Documentation/devicetree/bindings/serial/renesas,rsci.yaml index e059b14775eb..85ebb3056066 100644 --- a/Documentation/devicetree/bindings/serial/renesas,rsci.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,rsci.yaml @@ -14,6 +14,7 @@ properties: compatible: oneOf: - enum: + - renesas,r9a08g046-rsci # RZ/G3L - renesas,r9a09g047-rsci # RZ/G3E - renesas,r9a09g077-rsci # RZ/T2H @@ -145,6 +146,31 @@ allOf: - resets - reset-names + - if: + properties: + compatible: + contains: + const: renesas,r9a08g046-rsci + then: + properties: + interrupts: + minItems: 6 + + interrupt-names: + minItems: 6 + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + maxItems: 3 + + required: + - resets + - reset-names + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml index 6aa9cfae417b..96eb1de8771e 100644 --- a/Documentation/devicetree/bindings/serial/serial.yaml +++ b/Documentation/devicetree/bindings/serial/serial.yaml @@ -87,6 +87,9 @@ properties: description: TX FIFO threshold configuration (in bytes). + port: + $ref: /schemas/graph.yaml#/properties/port + patternProperties: "^(bluetooth|bluetooth-gnss|embedded-controller|gnss|gps|mcu|onewire)$": if: diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 6efe43089a74..685c1eceb782 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -71,6 +71,7 @@ properties: - rockchip,rk3568-uart - rockchip,rk3576-uart - rockchip,rk3588-uart + - rockchip,rv1103b-uart - rockchip,rv1108-uart - rockchip,rv1126-uart - sophgo,sg2044-uart diff --git a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml new file mode 100644 index 000000000000..a01a515222c6 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/cix/cix,sky1-system-control.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cix Sky1 SoC system control register region + +maintainers: + - Gary Yang <gary.yang@cixtech.com> + +description: + An wide assortment of registers of the system controller on Sky1 SoC, + including resets, usb, wakeup sources and so on. + +properties: + compatible: + items: + - enum: + - cix,sky1-system-control + - cix,sky1-s5-system-control + - const: syscon + + reg: + maxItems: 1 + + '#reset-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + syscon@4160000 { + compatible = "cix,sky1-system-control", "syscon"; + reg = <0x4160000 0x100>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml index 34aea58094e5..d828c2e82965 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml @@ -40,6 +40,58 @@ properties: minItems: 8 maxItems: 10 + dpi-bridge: + type: object + additionalProperties: false + + properties: + compatible: + enum: + - nxp,imx91-pdfc + - nxp,imx93-pdfc + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input port node to receive pixel data. + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: Output port node to downstream pixel data receivers. + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + bus-width: + enum: [ 16, 18, 24 ] + description: + Specify the physical parallel bus width. + + This property is optional if the display bus-width + matches the SoC bus-width, e.g. a 18-bit RGB666 (display) + is connected and all 18-bit data lines are muxed to the + parallel-output pads. + + This property must be set to 18 to cut only the LSBs + instead of the MSBs in case a 24-bit RGB888 display is + connected and only the lower 18-bit data lanes are muxed + to the parallel-output pads. + + required: + - port@0 + - port@1 + + required: + - compatible + - ports + allOf: - if: properties: @@ -112,4 +164,30 @@ examples: clock-names = "apb", "axi", "nic", "disp", "cam", "pxp", "lcdif", "isi", "csi", "dsi"; #power-domain-cells = <1>; + + dpi-bridge { + compatible = "nxp,imx93-pdfc"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + pdfc_from_lcdif: endpoint { + remote-endpoint = <&lcdif_to_pdfc>; + }; + }; + + port@1 { + reg = <1>; + + pdfc_to_panel: endpoint { + remote-endpoint = <&panel_from_pdfc>; + bus-width = <18>; + }; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-irqmux.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-irqmux.yaml new file mode 100644 index 000000000000..51164772724f --- /dev/null +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-irqmux.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/microchip/microchip,mpfs-irqmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Polarfire SoC GPIO Interrupt Mux + +maintainers: + - Conor Dooley <conor.dooley@microchip.com> + +description: | + There are 3 GPIO controllers on this SoC, of which: + - GPIO controller 0 has 14 GPIOs + - GPIO controller 1 has 24 GPIOs + - GPIO controller 2 has 32 GPIOs + + All GPIOs are capable of generating interrupts, for a total of 70. + There are only 41 IRQs available however, so a configurable mux is used to + ensure all GPIOs can be used for interrupt generation. + 38 of the 41 interrupts are in what the documentation calls "direct mode", + as they provide an exclusive connection from a GPIO to the PLIC. + Lines 18 to 23 on GPIO controller 1 are always in "direct mode". + The 3 remaining interrupts are used to mux the interrupts which do not have + a exclusive connection, one for each GPIO controller. + +properties: + compatible: + const: microchip,mpfs-irqmux + + reg: + maxItems: 1 + + "#address-cells": + const: 0 + + "#interrupt-cells": + const: 1 + + interrupt-map-mask: + items: + - const: 0x7f + + interrupt-map: + description: | + Specifies the mapping from GPIO interrupt lines to plic interrupts. + + The child interrupt number set in arrays items is computed using the + following formula: + gpio_bank * 32 + gpio_number + with: + - gpio_bank: The GPIO bank number + - 0 for GPIO0, + - 1 for GPIO1, + - 2 for GPIO2 + - gpio_number: Number of the gpio in the bank (0..31) + maxItems: 70 + +required: + - compatible + - reg + - "#address-cells" + - "#interrupt-cells" + - interrupt-map-mask + - interrupt-map + +additionalProperties: false + +examples: + - | + interrupt-controller@54 { + compatible = "microchip,mpfs-irqmux"; + reg = <0x54 0x4>; + #address-cells = <0>; + #interrupt-cells = <1>; + interrupt-map-mask = <0x7f>; + interrupt-map = <0 &plic 13>, <1 &plic 14>, <2 &plic 15>, + <3 &plic 16>, <4 &plic 17>, <5 &plic 18>, + <6 &plic 19>, <7 &plic 20>, <8 &plic 21>, + <9 &plic 22>, <10 &plic 23>, <11 &plic 24>, + <12 &plic 25>, <13 &plic 26>, + + <32 &plic 27>, <33 &plic 28>, <34 &plic 29>, + <35 &plic 30>, <36 &plic 31>, <37 &plic 32>, + <38 &plic 33>, <39 &plic 34>, <40 &plic 35>, + <41 &plic 36>, <42 &plic 37>, <43 &plic 38>, + <44 &plic 39>, <45 &plic 40>, <46 &plic 41>, + <47 &plic 42>, <48 &plic 43>, <49 &plic 44>, + <50 &plic 45>, <51 &plic 46>, <52 &plic 47>, + <53 &plic 48>, <54 &plic 49>, <55 &plic 50>, + + <64 &plic 53>, <65 &plic 53>, <66 &plic 53>, + <67 &plic 53>, <68 &plic 53>, <69 &plic 53>, + <70 &plic 53>, <71 &plic 53>, <72 &plic 53>, + <73 &plic 53>, <74 &plic 53>, <75 &plic 53>, + <76 &plic 53>, <77 &plic 53>, <78 &plic 53>, + <79 &plic 53>, <80 &plic 53>, <81 &plic 53>, + <82 &plic 53>, <83 &plic 53>, <84 &plic 53>, + <85 &plic 53>, <86 &plic 53>, <87 &plic 53>, + <88 &plic 53>, <89 &plic 53>, <90 &plic 53>, + <91 &plic 53>, <92 &plic 53>, <93 &plic 53>, + <94 &plic 53>, <95 &plic 53>; + }; diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml index 44e4a50c3155..1e3725335b2c 100644 --- a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml @@ -15,10 +15,16 @@ description: properties: compatible: - items: - - const: microchip,mpfs-mss-top-sysreg - - const: syscon - - const: simple-mfd + oneOf: + - items: + - const: microchip,mpfs-mss-top-sysreg + - const: syscon + - const: simple-mfd + - items: + - const: microchip,pic64gx-mss-top-sysreg + - const: microchip,mpfs-mss-top-sysreg + - const: syscon + - const: simple-mfd reg: maxItems: 1 @@ -38,6 +44,10 @@ properties: of PolarFire clock/reset IDs. const: 1 + interrupt-controller@54: + type: object + $ref: /schemas/soc/microchip/microchip,mpfs-irqmux.yaml + pinctrl@200: type: object $ref: /schemas/pinctrl/microchip,mpfs-pinctrl-iomux0.yaml diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml index a3fa04f3a1bd..6cebc19db4f5 100644 --- a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml @@ -24,7 +24,9 @@ properties: maxItems: 1 compatible: - const: microchip,mpfs-sys-controller + enum: + - microchip,mpfs-sys-controller + - microchip,pic64gx-sys-controller microchip,bitstream-flash: $ref: /schemas/types.yaml#/definitions/phandle diff --git a/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.yaml b/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.yaml index 6d11472ba5a7..56401d76a9b5 100644 --- a/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.yaml +++ b/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq5-olb.yaml @@ -51,6 +51,9 @@ properties: clock-names: const: ref + '#phy-cells': + const: 1 + patternProperties: '-pins?$': type: object @@ -310,7 +313,7 @@ allOf: properties: '#reset-cells': false - # Only EyeQ5 has pinctrl in OLB. + # Only EyeQ5 has pinctrl and PHY in OLB. - if: not: properties: @@ -320,6 +323,8 @@ allOf: then: patternProperties: '-pins?$': false + properties: + '#phy-cells': false examples: - | diff --git a/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq6lplus-olb.yaml b/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq6lplus-olb.yaml new file mode 100644 index 000000000000..8334876cf4e6 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/mobileye/mobileye,eyeq6lplus-olb.yaml @@ -0,0 +1,208 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/mobileye/mobileye,eyeq6lplus-olb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mobileye EyeQ6Lplus SoC system controller + +maintainers: + - Benoît Monin <benoit.monin@bootlin.com> + - Grégory Clement <gregory.clement@bootlin.com> + - Théo Lebrun <theo.lebrun@bootlin.com> + - Vladimir Kondratiev <vladimir.kondratiev@mobileye.com> + +description: + OLB ("Other Logic Block") is a hardware block grouping smaller blocks. + Clocks, resets, pinctrl are being handled from here. EyeQ6Lplus hosts + a single instance providing 22 clocks, two reset domains and one bank + of 32 pins. + +properties: + compatible: + items: + - const: mobileye,eyeq6lplus-olb + - const: syscon + + reg: + maxItems: 1 + + '#reset-cells': + description: + First cell is reset domain index. + Second cell is reset index inside that domain. + const: 2 + + '#clock-cells': + const: 1 + + clocks: + maxItems: 1 + description: + Input parent clock to all PLLs. Expected to be the main crystal. + + clock-names: + const: ref + +patternProperties: + '-pins?$': + type: object + description: Pin muxing configuration. + $ref: /schemas/pinctrl/pinmux-node.yaml# + additionalProperties: false + properties: + pins: true + function: + enum: [gpio, timer0, timer1, uart_ssi, spi0, uart0, timer2, timer3, + timer_ext0, spi1, timer_ext1, ext_ref_clk, mipi_ref_clk] + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength: true + required: + - pins + - function + allOf: + - if: + properties: + function: + const: gpio + then: + properties: + pins: + items: # PA0 - PA31 + pattern: '^(PA[1,2]?[0-9]|PA3[0,1])$' + - if: + properties: + function: + const: timer0 + then: + properties: + pins: + items: + enum: [PA0, PA1] + - if: + properties: + function: + const: timer1 + then: + properties: + pins: + items: + enum: [PA2, PA3] + - if: + properties: + function: + const: uart_ssi + then: + properties: + pins: + items: + enum: [PA4, PA5] + - if: + properties: + function: + const: spi0 + then: + properties: + pins: + items: + enum: [PA6, PA7, PA8, PA9, PA10] + - if: + properties: + function: + const: uart0 + then: + properties: + pins: + items: + enum: [PA11, PA12] + - if: + properties: + function: + const: timer2 + then: + properties: + pins: + items: + enum: [PA13, PA14] + - if: + properties: + function: + const: timer3 + then: + properties: + pins: + items: + enum: [PA15, PA16] + - if: + properties: + function: + const: timer_ext0 + then: + properties: + pins: + items: + enum: [PA17, PA18, PA19, PA20] + - if: + properties: + function: + const: spi1 + then: + properties: + pins: + items: + enum: [PA21, PA22, PA23, PA24, PA25] + - if: + properties: + function: + const: timer_ext1 + then: + properties: + pins: + items: + enum: [PA26, PA27, PA28, PA29] + - if: + properties: + function: + const: ext_ref_clk + then: + properties: + pins: + items: + enum: [PA30] + - if: + properties: + function: + const: mipi_ref_clk + then: + properties: + pins: + items: + enum: [PA31] + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + - '#reset-cells' + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + system-controller@e8400000 { + compatible = "mobileye,eyeq6lplus-olb", "syscon"; + reg = <0 0xe8400000 0x0 0x80000>; + #reset-cells = <2>; + #clock-cells = <1>; + clocks = <&xtal>; + clock-names = "ref"; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml index 7085bf88afab..ff01d2f3ee5b 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml @@ -23,6 +23,8 @@ properties: oneOf: - items: - enum: + - qcom,glymur-pmic-glink + - qcom,kaanapali-pmic-glink - qcom,qcm6490-pmic-glink - qcom,sc8180x-pmic-glink - qcom,sc8280xp-pmic-glink diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml index 4386b2c3fa4d..94ae72eb8fb6 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,rzg2l-sysc.yaml @@ -24,6 +24,7 @@ properties: - renesas,r9a07g044-sysc # RZ/G2{L,LC} - renesas,r9a07g054-sysc # RZ/V2L - renesas,r9a08g045-sysc # RZ/G3S + - renesas,r9a08g046-sysc # RZ/G3L reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index f4947ac65460..5c22c51b1533 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -548,6 +548,19 @@ properties: - const: renesas,r9a08g045s33 # PCIe support - const: renesas,r9a08g045 + - description: RZ/G3L (R9A08G046) + items: + - enum: + - renesas,smarc2-evk # RZ SMARC Carrier-II EVK + - enum: + - renesas,rzg3l-smarcm # RZ/G3L SMARC Module (SoM) + - enum: + - renesas,r9a08g046l26 # Dual Cortex-A55 + Cortex-M33 + GE3D/VCP (14mm LFBGA) + - renesas,r9a08g046l28 # Dual Cortex-A55 + Cortex-M33 + GE3D/VCP (17mm LFBGA) + - renesas,r9a08g046l46 # Quad Cortex-A55 + Cortex-M33 + GE3D/VCP (14mm LFBGA) + - renesas,r9a08g046l48 # Quad Cortex-A55 + Cortex-M33 + GE3D/VCP (17mm LFBGA) + - const: renesas,r9a08g046 + - description: RZ/V2M (R9A09G011) items: - enum: diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 0b8e3294c83e..2cc43742b8e3 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -63,6 +63,7 @@ properties: - rockchip,rk3588-vo0-grf - rockchip,rk3588-vo1-grf - rockchip,rk3588-vop-grf + - rockchip,rv1103b-ioc - rockchip,rv1108-usbgrf - const: syscon - items: @@ -98,6 +99,7 @@ properties: - rockchip,rk3576-pmu0-grf - rockchip,rk3576-usb2phy-grf - rockchip,rk3588-usb2phy-grf + - rockchip,rv1103b-pmu-grf - rockchip,rv1108-grf - rockchip,rv1108-pmugrf - rockchip,rv1126-grf @@ -231,6 +233,7 @@ allOf: - rockchip,rk3036-grf - rockchip,rk3308-grf - rockchip,rk3368-pmugrf + - rockchip,rv1103b-pmu-grf then: properties: diff --git a/Documentation/devicetree/bindings/sound/adi,ssm2305.txt b/Documentation/devicetree/bindings/sound/adi,ssm2305.txt deleted file mode 100644 index a9c9d83c8a30..000000000000 --- a/Documentation/devicetree/bindings/sound/adi,ssm2305.txt +++ /dev/null @@ -1,14 +0,0 @@ -Analog Devices SSM2305 Speaker Amplifier -======================================== - -Required properties: - - compatible : "adi,ssm2305" - - shutdown-gpios : The gpio connected to the shutdown pin. - The gpio signal is ACTIVE_LOW. - -Example: - -ssm2305: analog-amplifier { - compatible = "adi,ssm2305"; - shutdown-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>; -}; diff --git a/Documentation/devicetree/bindings/sound/adi,ssm2305.yaml b/Documentation/devicetree/bindings/sound/adi,ssm2305.yaml new file mode 100644 index 000000000000..b841da2dc284 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/adi,ssm2305.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/adi,ssm2305.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices SSM2305 Class-D Speaker Amplifier + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + +description: + The SSM2305 is a filterless, high efficiency, mono 2.8 W Class-D + audio amplifier with a micropower shutdown mode controlled via a + dedicated active-low GPIO pin. + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: adi,ssm2305 + + shutdown-gpios: + maxItems: 1 + description: + GPIO connected to the shutdown pin (SD) of the SSM2305. + The pin is active-low; asserting it puts the device into + micropower shutdown mode. + +required: + - compatible + - shutdown-gpios + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + analog-amplifier { + compatible = "adi,ssm2305"; + shutdown-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml index 994d68c074a9..b9abb10942ba 100644 --- a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml +++ b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml @@ -35,6 +35,10 @@ properties: dvdd-supply: true + firmware-name: + maxItems: 1 + description: Name of the *_acf.bin file used for amplifier initialization + awinic,audio-channel: description: It is used to distinguish multiple PA devices, so that different diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml index 99a536601cc7..376928d1f64b 100644 --- a/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml +++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml @@ -16,6 +16,8 @@ description: | DAC for headphone output, two integrated Class D amplifiers for loudspeakers, and two ADCs for wired headset microphone input or stereo line input. PDM inputs are provided for digital microphones. + CS42L43B variant adds dedicated PDM interface, SoundWire Clock Gearing + support and more decimators to ISRCs. allOf: - $ref: dai-common.yaml# @@ -24,6 +26,7 @@ properties: compatible: enum: - cirrus,cs42l43 + - cirrus,cs42l43b reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/hisilicon,hi6210-i2s.txt b/Documentation/devicetree/bindings/sound/hisilicon,hi6210-i2s.txt deleted file mode 100644 index 7a296784eb37..000000000000 --- a/Documentation/devicetree/bindings/sound/hisilicon,hi6210-i2s.txt +++ /dev/null @@ -1,42 +0,0 @@ -* Hisilicon 6210 i2s controller - -Required properties: - -- compatible: should be one of the following: - - "hisilicon,hi6210-i2s" -- reg: physical base address of the i2s controller unit and length of - memory mapped region. -- interrupts: should contain the i2s interrupt. -- clocks: a list of phandle + clock-specifier pairs, one for each entry - in clock-names. -- clock-names: should contain following: - - "dacodec" - - "i2s-base" -- dmas: DMA specifiers for tx dma. See the DMA client binding, - Documentation/devicetree/bindings/dma/dma.txt -- dma-names: should be "tx" and "rx" -- hisilicon,sysctrl-syscon: phandle to sysctrl syscon -- #sound-dai-cells: Should be set to 1 (for multi-dai) - - The dai cell indexes reference the following interfaces: - 0: S2 interface - (Currently that is the only one available, but more may be - supported in the future) - -Example for the hi6210 i2s controller: - -i2s0: i2s@f7118000{ - compatible = "hisilicon,hi6210-i2s"; - reg = <0x0 0xf7118000 0x0 0x8000>; /* i2s unit */ - interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>; /* 155 "DigACodec_intr"-32 */ - clocks = <&sys_ctrl HI6220_DACODEC_PCLK>, - <&sys_ctrl HI6220_BBPPLL0_DIV>; - clock-names = "dacodec", "i2s-base"; - dmas = <&dma0 15 &dma0 14>; - dma-names = "rx", "tx"; - hisilicon,sysctrl-syscon = <&sys_ctrl>; - #sound-dai-cells = <1>; -}; - -Then when referencing the i2s controller: - sound-dai = <&i2s0 0>; /* index 0 => S2 interface */ - diff --git a/Documentation/devicetree/bindings/sound/hisilicon,hi6210-i2s.yaml b/Documentation/devicetree/bindings/sound/hisilicon,hi6210-i2s.yaml new file mode 100644 index 000000000000..5171f984630b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/hisilicon,hi6210-i2s.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/hisilicon,hi6210-i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HiSilicon hi6210 I2S controller + +maintainers: + - John Stultz <john.stultz@linaro.org> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: hisilicon,hi6210-i2s + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: dacodec + - const: i2s-base + + dmas: + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + hisilicon,sysctrl-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to sysctrl syscon + + "#sound-dai-cells": + const: 1 + description: | + The dai cell indexes reference the following interfaces: + 0: S2 interface + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + - hisilicon,sysctrl-syscon + - "#sound-dai-cells" + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/hi6220-clock.h> + + i2s@f7118000 { + compatible = "hisilicon,hi6210-i2s"; + reg = <0xf7118000 0x8000>; + interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&sys_ctrl HI6220_DACODEC_PCLK>, + <&sys_ctrl HI6220_BBPPLL0_DIV>; + clock-names = "dacodec", "i2s-base"; + dmas = <&dma0 14>, <&dma0 15>; + dma-names = "tx", "rx"; + hisilicon,sysctrl-syscon = <&sys_ctrl>; + #sound-dai-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml index 3c75c8c78987..5424d4f16f52 100644 --- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml @@ -24,6 +24,7 @@ patternProperties: cpu/codec dais. type: object + $ref: tdm-slot.yaml# properties: link-name: @@ -38,13 +39,9 @@ patternProperties: - i2s - dsp_b - dai-tdm-slot-num: - description: see tdm-slot.txt. - $ref: /schemas/types.yaml#/definitions/uint32 + dai-tdm-slot-num: true - dai-tdm-slot-width: - description: see tdm-slot.txt. - $ref: /schemas/types.yaml#/definitions/uint32 + dai-tdm-slot-width: true playback-only: description: link is used only for playback diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml index cf985461a995..bb6a405b263e 100644 --- a/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml +++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml @@ -28,8 +28,6 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle description: The phandle of the WM8960 audio codec. -unevaluatedProperties: false - required: - compatible - mediatek,platform @@ -38,6 +36,8 @@ required: - pinctrl-names - pinctrl-0 +additionalProperties: false + examples: - | sound { diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml index 09247ceea3f7..f21cad4bae15 100644 --- a/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml +++ b/Documentation/devicetree/bindings/sound/mediatek,mt7986-wm8960.yaml @@ -36,14 +36,14 @@ properties: required: - sound-dai -unevaluatedProperties: false - required: - compatible - audio-routing - platform - codec +unevaluatedProperties: false + examples: - | sound { diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml new file mode 100644 index 000000000000..ed698c9ff42b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8173-rt5650-rt5514.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mediatek,mt8173-rt5650-rt5514.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT8173 with RT5650 and RT5514 audio codecs + +maintainers: + - Koro Chen <koro.chen@mediatek.com> + +properties: + compatible: + const: mediatek,mt8173-rt5650-rt5514 + + mediatek,audio-codec: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: Phandles of rt5650 and rt5514 codecs + items: + - description: phandle of rt5650 codec + - description: phandle of rt5514 codec + + mediatek,platform: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of MT8173 ASoC platform. + +required: + - compatible + - mediatek,audio-codec + - mediatek,platform + +additionalProperties: false + +examples: + - | + sound { + compatible = "mediatek,mt8173-rt5650-rt5514"; + mediatek,audio-codec = <&rt5650>, <&rt5514>; + mediatek,platform = <&afe>; + }; +... diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml index 7ba2ea2dfa0b..539de75eb20d 100644 --- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml @@ -105,12 +105,12 @@ patternProperties: required: - link-name -unevaluatedProperties: false - required: - compatible - mediatek,platform +unevaluatedProperties: false + examples: - | sound { diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt deleted file mode 100644 index e8b3c80c6fff..000000000000 --- a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt +++ /dev/null @@ -1,15 +0,0 @@ -MT8173 with RT5650 RT5514 CODECS - -Required properties: -- compatible : "mediatek,mt8173-rt5650-rt5514" -- mediatek,audio-codec: the phandles of rt5650 and rt5514 codecs -- mediatek,platform: the phandle of MT8173 ASoC platform - -Example: - - sound { - compatible = "mediatek,mt8173-rt5650-rt5514"; - mediatek,audio-codec = <&rt5650 &rt5514>; - mediatek,platform = <&afe>; - }; - diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-cpcap.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-cpcap.yaml new file mode 100644 index 000000000000..69af2022d0fa --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-cpcap.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-cpcap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with CPCAP CODEC + +maintainers: + - Svyatoslav Ryhel <clamor95@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + items: + - pattern: '^motorola,tegra-audio-cpcap(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-cpcap + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. Valid names for sources and sinks are + the pins (documented in the binding document), and the jacks on the + board. + minItems: 2 + items: + enum: + # Board Connectors + - Speakers + - Int Spk + - Earpiece + - Int Mic + - Headset Mic + - Internal Mic 1 + - Internal Mic 2 + - Headphone + - Headphones + - Headphone Jack + - Mic Jack + + # CODEC Pins + - MICR + - HSMIC + - EMUMIC + - MICL + - EXTR + - EXTL + - EP + - SPKR + - SPKL + - LINER + - LINEL + - HSR + - HSL + - EMUR + - EMUL + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + #include <dt-bindings/soc/tegra-pmc.h> + sound { + compatible = "motorola,tegra-audio-cpcap-olympus", + "nvidia,tegra-audio-cpcap"; + nvidia,model = "Motorola Atrix 4G (MB860) CPCAP"; + + nvidia,audio-routing = + "Headphones", "HSR", + "Headphones", "HSL", + "Int Spk", "SPKR", + "Int Spk", "SPKL", + "Earpiece", "EP", + "HSMIC", "Mic Jack", + "MICR", "Internal Mic 1", + "MICL", "Internal Mic 2"; + + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&cpcap_audio>; + + clocks = <&tegra_car TEGRA20_CLK_PLL_A>, + <&tegra_car TEGRA20_CLK_PLL_A_OUT0>, + <&tegra_car TEGRA20_CLK_CDEV1>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml index 241d20f3aad0..4957645a8e03 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml @@ -35,10 +35,15 @@ properties: items: enum: # Board Connectors + - Speakers - Int Spk + - Headphone + - Headphones - Headphone Jack - Earpiece - Headset Mic + - Mic Jack + - Int Mic - Internal Mic 1 - Internal Mic 2 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8962.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8962.yaml new file mode 100644 index 000000000000..2c3bf5a02a34 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8962.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-wm8962.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with WM8962 CODEC + +maintainers: + - Svyatoslav Ryhel <clamor95@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + items: + - pattern: '^[a-z0-9]+,tegra-audio-wm8962(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-wm8962 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. Valid names for sources and sinks are + the pins (documented in the binding document), and the jacks on the + board. + minItems: 2 + items: + enum: + # Board Connectors + - Speakers + - Int Spk + - Earpiece + - Int Mic + - Headset Mic + - Internal Mic 1 + - Internal Mic 2 + - Headphone + - Headphones + - Headphone Jack + - Mic Jack + + # CODEC Pins + - IN1L + - IN1R + - IN2L + - IN2R + - IN3L + - IN3R + - IN4L + - IN4R + - DMICDAT + - HPOUTL + - HPOUTR + - SPKOUT + - SPKOUTL + - SPKOUTR + +required: + - nvidia,i2s-controller + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra30-car.h> + #include <dt-bindings/soc/tegra-pmc.h> + sound { + compatible = "microsoft,tegra-audio-wm8962-surface-rt", + "nvidia,tegra-audio-wm8962"; + nvidia,model = "Microsoft Surface RT WM8962"; + + nvidia,audio-routing = + "Headphone Jack", "HPOUTR", + "Headphone Jack", "HPOUTL", + "Int Spk", "SPKOUTR", + "Int Spk", "SPKOUTL"; + + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&wm8962>; + + clocks = <&tegra_car TEGRA30_CLK_PLL_A>, + <&tegra_car TEGRA30_CLK_PLL_A_OUT0>, + <&tegra_pmc TEGRA_PMC_CLK_OUT_1>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml index 08c618e7e428..2b27d6c8f58f 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,q6dsp-lpass-ports.yaml @@ -126,13 +126,16 @@ patternProperties: reg: contains: # MI2S DAI ID range PRIMARY_MI2S_RX - QUATERNARY_MI2S_TX and - # QUINARY_MI2S_RX - QUINARY_MI2S_TX + # QUINARY_MI2S_RX - QUINARY_MI2S_TX and + # LPI_MI2S_RX_0 - SENARY_MI2S_TX items: oneOf: - minimum: 16 maximum: 23 - minimum: 127 maximum: 128 + - minimum: 137 + maximum: 148 then: required: - qcom,sd-lines diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt deleted file mode 100644 index 72d3cf4c2606..000000000000 --- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt +++ /dev/null @@ -1,22 +0,0 @@ -ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards - -Required properties: -- compatible: "rockchip,rk3399-gru-sound" -- rockchip,cpu: The phandle of the Rockchip I2S controller that's - connected to the codecs -- rockchip,codec: The phandle of the audio codecs - -Optional properties: -- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready. - If this option is specified, which means it's required dmic need - delay for DMIC to ready so that rt5514 can avoid recording before - DMIC send valid data - -Example: - -sound { - compatible = "rockchip,rk3399-gru-sound"; - rockchip,cpu = <&i2s0>; - rockchip,codec = <&max98357a &rt5514 &da7219>; - dmic-wakeup-delay-ms = <20>; -}; diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml new file mode 100644 index 000000000000..e9d13695cc77 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/rockchip,rk3399-gru-sound.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip with MAX98357A/RT5514/DA7219 codecs on GRU boards + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + const: rockchip,rk3399-gru-sound + + rockchip,cpu: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + List of phandles to the Rockchip CPU DAI controllers connected to codecs + minItems: 1 + items: + - items: + - description: Phandle to the Rockchip I2S controllers + - items: + - description: | + Phandle to the Rockchip SPDIF controller. Required when a + DisplayPort audio codec is referenced in rockchip,codec + + rockchip,codec: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + The phandles of the audio codecs connected to the Rockchip CPU DAI + controllers + minItems: 1 + maxItems: 6 + items: + maxItems: 1 + + dmic-wakeup-delay-ms: + description: | + specify delay time (ms) for DMIC ready. + If this option is specified, a delay is required for DMIC to get ready + so that rt5514 can avoid recording before DMIC sends valid data + +required: + - compatible + - rockchip,cpu + - rockchip,codec + +additionalProperties: false + +examples: + - | + sound { + compatible = "rockchip,rk3399-gru-sound"; + rockchip,cpu = <&i2s0 &spdif>; + rockchip,codec = <&max98357a &rt5514 &da7219 &cdn_dp>; + dmic-wakeup-delay-ms = <20>; + }; + diff --git a/Documentation/devicetree/bindings/sound/rockchip,rockchip-audio-max98090.yaml b/Documentation/devicetree/bindings/sound/rockchip,rockchip-audio-max98090.yaml new file mode 100644 index 000000000000..5351d5f02edf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip,rockchip-audio-max98090.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/rockchip,rockchip-audio-max98090.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip audio complex with MAX98090 codec + +maintainers: + - Fabio Estevam <festevam@gmail.com> + +properties: + compatible: + const: rockchip,rockchip-audio-max98090 + + rockchip,model: + $ref: /schemas/types.yaml#/definitions/string + description: The user-visible name of this sound complex. + + rockchip,i2s-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the Rockchip I2S controller. + + rockchip,audio-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the MAX98090 audio codec. + + rockchip,headset-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the external chip for jack detection. + + rockchip,hdmi-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the HDMI device for HDMI codec. + +required: + - compatible + - rockchip,model + - rockchip,i2s-controller + +allOf: + - if: + required: + - rockchip,audio-codec + then: + required: + - rockchip,headset-codec + +unevaluatedProperties: false + +examples: + - | + sound { + compatible = "rockchip,rockchip-audio-max98090"; + rockchip,model = "ROCKCHIP-I2S"; + rockchip,i2s-controller = <&i2s>; + rockchip,audio-codec = <&max98090>; + rockchip,headset-codec = <&headsetcodec>; + }; diff --git a/Documentation/devicetree/bindings/sound/rockchip-max98090.txt b/Documentation/devicetree/bindings/sound/rockchip-max98090.txt deleted file mode 100644 index e9c58b204399..000000000000 --- a/Documentation/devicetree/bindings/sound/rockchip-max98090.txt +++ /dev/null @@ -1,42 +0,0 @@ -ROCKCHIP with MAX98090 CODEC - -Required properties: -- compatible: "rockchip,rockchip-audio-max98090" -- rockchip,model: The user-visible name of this sound complex -- rockchip,i2s-controller: The phandle of the Rockchip I2S controller that's - connected to the CODEC - -Optional properties: -- rockchip,audio-codec: The phandle of the MAX98090 audio codec. -- rockchip,headset-codec: The phandle of Ext chip for jack detection. This is - required if there is rockchip,audio-codec. -- rockchip,hdmi-codec: The phandle of HDMI device for HDMI codec. - -Example: - -/* For max98090-only board. */ -sound { - compatible = "rockchip,rockchip-audio-max98090"; - rockchip,model = "ROCKCHIP-I2S"; - rockchip,i2s-controller = <&i2s>; - rockchip,audio-codec = <&max98090>; - rockchip,headset-codec = <&headsetcodec>; -}; - -/* For HDMI-only board. */ -sound { - compatible = "rockchip,rockchip-audio-max98090"; - rockchip,model = "ROCKCHIP-I2S"; - rockchip,i2s-controller = <&i2s>; - rockchip,hdmi-codec = <&hdmi>; -}; - -/* For max98090 plus HDMI board. */ -sound { - compatible = "rockchip,rockchip-audio-max98090"; - rockchip,model = "ROCKCHIP-I2S"; - rockchip,i2s-controller = <&i2s>; - rockchip,audio-codec = <&max98090>; - rockchip,headset-codec = <&headsetcodec>; - rockchip,hdmi-codec = <&hdmi>; -}; diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml index 533d0a1da56e..a14716b2732f 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.yaml +++ b/Documentation/devicetree/bindings/sound/simple-card.yaml @@ -27,14 +27,6 @@ definitions: description: dai-link uses bit clock inversion $ref: /schemas/types.yaml#/definitions/flag - dai-tdm-slot-num: - description: see tdm-slot.txt. - $ref: /schemas/types.yaml#/definitions/uint32 - - dai-tdm-slot-width: - description: see tdm-slot.txt. - $ref: /schemas/types.yaml#/definitions/uint32 - system-clock-frequency: description: | If a clock is specified and a multiplication factor is given with @@ -115,6 +107,8 @@ definitions: dai: type: object + $ref: tdm-slot.yaml# + properties: sound-dai: maxItems: 1 @@ -133,10 +127,6 @@ definitions: bitclock-master: $ref: /schemas/types.yaml#/definitions/flag - dai-tdm-slot-num: - $ref: "#/definitions/dai-tdm-slot-num" - dai-tdm-slot-width: - $ref: "#/definitions/dai-tdm-slot-width" clocks: maxItems: 1 system-clock-frequency: diff --git a/Documentation/devicetree/bindings/sound/tdm-slot.txt b/Documentation/devicetree/bindings/sound/tdm-slot.txt deleted file mode 100644 index 4bb513ae62fc..000000000000 --- a/Documentation/devicetree/bindings/sound/tdm-slot.txt +++ /dev/null @@ -1,29 +0,0 @@ -TDM slot: - -This specifies audio DAI's TDM slot. - -TDM slot properties: -dai-tdm-slot-num : Number of slots in use. -dai-tdm-slot-width : Width in bits for each slot. -dai-tdm-slot-tx-mask : Transmit direction slot mask, optional -dai-tdm-slot-rx-mask : Receive direction slot mask, optional - -For instance: - dai-tdm-slot-num = <2>; - dai-tdm-slot-width = <8>; - dai-tdm-slot-tx-mask = <0 1>; - dai-tdm-slot-rx-mask = <1 0>; - -And for each specified driver, there could be one .of_xlate_tdm_slot_mask() -to specify an explicit mapping of the channels and the slots. If it's absent -the default snd_soc_of_xlate_tdm_slot_mask() will be used to generating the -tx and rx masks. - -For snd_soc_of_xlate_tdm_slot_mask(), the tx and rx masks will use a 1 bit -for an active slot as default, and the default active bits are at the LSB of -the masks. - -The explicit masks are given as array of integers, where the first -number presents bit-0 (LSB), second presents bit-1, etc. Any non zero -number is considered 1 and 0 is 0. snd_soc_of_xlate_tdm_slot_mask() -does not do anything, if either mask is set non zero value. diff --git a/Documentation/devicetree/bindings/sound/tdm-slot.yaml b/Documentation/devicetree/bindings/sound/tdm-slot.yaml new file mode 100644 index 000000000000..457a899e8872 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tdm-slot.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/tdm-slot.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Time Division Multiplexing (TDM) Slot Parameters + +maintainers: + - Liam Girdwood <lgirdwood@gmail.com> + +select: false + +properties: + dai-tdm-slot-num: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of slots in use + + dai-tdm-slot-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Width, in bits, of each slot + + dai-tdm-idle-mode: + $ref: /schemas/types.yaml#/definitions/string + enum: + - none + - off + - zero + - pulldown + - hiz + - pullup + - drivehigh + description: Drive mode for inactive/idle TDM slots. For hardware that + implements .set_tdm_idle(). Optional. "None" represents undefined + behaviour and is the same as not setting this property. + +patternProperties: + '^dai-tdm-slot-[rt]x-mask$': + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Slot mask for active TDM slots. Optional. Drivers may + specify .xlate_tdm_slot_mask() to generate a slot mask dynamically. If + neither this property nor a driver-specific function are specified, the + default snd_soc_xlate_tdm_slot_mask() function will be used to generate + a mask. The first element of the array is slot 0 (LSB). Any nonzero + value will be treated as 1. + + '^dai-tdm-slot-[rt]x-idle-mask$': + $ref: /schemas/types.yaml#/definitions/uint32 + description: Idle slot mask. Optional. A bit being set to 1 indicates + that the corresponding TDM slot is inactive/idle. + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/sound/ti,tas2552.yaml b/Documentation/devicetree/bindings/sound/ti,tas2552.yaml index 10369aa5f0a8..85e3ebd2acd8 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas2552.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tas2552.yaml @@ -12,8 +12,8 @@ maintainers: - Baojun Xu <baojun.xu@ti.com> description: > - The TAS2552 can receive its reference clock via MCLK, BCLK, IVCLKIN pin or - use the internal 1.8MHz. This CLKIN is used by the PLL. In addition to PLL, + The TAS2552 can receive its reference clock via MCLK, BCLK, IVCLKIN pin or + use the internal 1.8MHz. This CLKIN is used by the PLL. In addition to PLL, the PDM reference clock is also selectable: PLL, IVCLKIN, BCLK or MCLK. For system integration the dt-bindings/sound/tas2552.h header file provides @@ -34,6 +34,9 @@ properties: maxItems: 1 description: gpio pin to enable/disable the device + '#sound-dai-cells': + const: 0 + required: - compatible - reg @@ -41,7 +44,10 @@ required: - iovdd-supply - avdd-supply -additionalProperties: false +allOf: + - $ref: dai-common.yaml# + +unevaluatedProperties: false examples: - | @@ -54,6 +60,7 @@ examples: audio-codec@41 { compatible = "ti,tas2552"; reg = <0x41>; + #sound-dai-cells = <0>; vbat-supply = <®_vbat>; iovdd-supply = <®_iovdd>; avdd-supply = <®_avdd>; diff --git a/Documentation/devicetree/bindings/sound/ti,tas2770.yaml b/Documentation/devicetree/bindings/sound/ti,tas2770.yaml index 8eab98a0f7a2..8d49fbcf0b9b 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas2770.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tas2770.yaml @@ -30,7 +30,7 @@ properties: description: | I2C address of the device can be between 0x41 to 0x48. - reset-gpio: + reset-gpios: maxItems: 1 description: GPIO used to reset the device. @@ -82,7 +82,7 @@ examples: #sound-dai-cells = <0>; interrupt-parent = <&gpio1>; interrupts = <14>; - reset-gpio = <&gpio1 15 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>; shutdown-gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>; ti,imon-slot-no = <0>; ti,vmon-slot-no = <2>; diff --git a/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml b/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml index 636338d24bdf..8ff50dfcf585 100644 --- a/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml +++ b/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml @@ -35,10 +35,10 @@ properties: interrupts: maxItems: 1 - clock-names: + clocks: maxItems: 1 - clocks: + resets: maxItems: 1 microchip,apb-datawidth: diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml index a588b112e11e..f40f316943ba 100644 --- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml @@ -13,10 +13,13 @@ properties: compatible: oneOf: - enum: + - renesas,r9a08g046-rspi # RZ/G3L - renesas,r9a09g057-rspi # RZ/V2H(P) - renesas,r9a09g077-rspi # RZ/T2H - items: - - const: renesas,r9a09g056-rspi # RZ/V2N + - enum: + - renesas,r9a09g047-rspi # RZ/G3E + - renesas,r9a09g056-rspi # RZ/V2N - const: renesas,r9a09g057-rspi - items: - const: renesas,r9a09g087-rspi # RZ/N2H @@ -58,12 +61,19 @@ properties: - const: tresetn dmas: - maxItems: 2 + minItems: 2 + maxItems: 10 + description: + Must contain a list of pairs of references to DMA specifiers, one for + transmission, and one for reception. dma-names: + minItems: 2 + maxItems: 10 items: - - const: rx - - const: tx + enum: + - rx + - tx power-domains: maxItems: 1 @@ -86,6 +96,34 @@ allOf: compatible: contains: enum: + - renesas,r9a08g046-rspi + then: + properties: + clocks: + maxItems: 2 + + clock-names: + items: + - const: pclk + - const: tclk + + dmas: + maxItems: 2 + + dma-names: + items: + - const: rx + - const: tx + + required: + - resets + - reset-names + + - if: + properties: + compatible: + contains: + enum: - renesas,r9a09g057-rspi then: properties: @@ -121,6 +159,12 @@ allOf: resets: false reset-names: false + dmas: + maxItems: 6 + + dma-names: + maxItems: 6 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml b/Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml index 08369fdd2161..0f7089e0950a 100644 --- a/Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml +++ b/Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml @@ -24,7 +24,9 @@ properties: compatible: oneOf: - items: - - const: qcom,sar2130p-spmi-pmic-arb + - enum: + - qcom,eliza-spmi-pmic-arb + - qcom,sar2130p-spmi-pmic-arb - const: qcom,x1e80100-spmi-pmic-arb - const: qcom,x1e80100-spmi-pmic-arb diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml index 6a627c57ae2f..c63026904061 100644 --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml @@ -67,6 +67,20 @@ properties: $ref: /schemas/power/reset/syscon-reboot-mode.yaml# patternProperties: + "^modem-tables@[0-9a-f]+$": + type: object + description: + Region containing packet processing configuration for the IP Accelerator. + + properties: + reg: + maxItems: 1 + + required: + - reg + + additionalProperties: false + "^pil-reloc@[0-9a-f]+$": $ref: /schemas/remoteproc/qcom,pil-info.yaml# description: Peripheral image loader relocation region diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index c451140962c8..8985f89170be 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -34,7 +34,9 @@ properties: - nvidia,tegra186-sysram - nvidia,tegra194-sysram - nvidia,tegra234-sysram + - qcom,hawi-imem - qcom,kaanapali-imem + - qcom,milos-imem - qcom,rpm-msg-ram - rockchip,rk3288-pmu-sram @@ -65,7 +67,7 @@ properties: type: boolean patternProperties: - "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$": + "^([a-z0-9]+-)*sram(-section)?@[a-f0-9]+$": type: object description: Each child of the sram node specifies a region of reserved memory. diff --git a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt b/Documentation/devicetree/bindings/thermal/max77620_thermal.txt deleted file mode 100644 index 82ed5d487966..000000000000 --- a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt +++ /dev/null @@ -1,70 +0,0 @@ -Thermal driver for MAX77620 Power management IC from Maxim Semiconductor. - -Maxim Semiconductor MAX77620 supports alarm interrupts when its -die temperature crosses 120C and 140C. These threshold temperatures -are not configurable. Device does not provide the real temperature -of die other than just indicating whether temperature is above or -below threshold level. - -Required properties: -------------------- -#thermal-sensor-cells: For more details, please refer to - <devicetree/bindings/thermal/thermal-sensor.yaml> - The value must be 0. - -For more details, please refer generic thermal DT binding document -<devicetree/bindings/thermal/thermal*.yaml>. - -Please refer <devicetree/bindings/mfd/max77620.txt> for mfd DT binding -document for the MAX77620. - -Example: --------- -#include <dt-bindings/mfd/max77620.h> -#include <dt-bindings/thermal/thermal.h> -... - -i2c@7000d000 { - spmic: max77620@3c { - compatible = "maxim,max77620"; - ::::: - #thermal-sensor-cells = <0>; - ::: - }; -}; - -cool_dev: cool-dev { - compatible = "cooling-dev"; - #cooling-cells = <2>; -}; - -thermal-zones { - PMIC-Die { - polling-delay = <0>; - polling-delay-passive = <0>; - thermal-sensors = <&spmic>; - - trips { - pmic_die_warn_temp_thresh: hot-die { - temperature = <120000>; - type = "hot"; - hysteresis = <0>; - }; - - pmic_die_cirt_temp_thresh: cirtical-die { - temperature = <140000>; - type = "critical"; - hysteresis = <0>; - }; - }; - - cooling-maps { - map0 { - trip = <&pmic_die_warn_temp_thresh>; - cooling-device = <&cool_dev THERMAL_NO_LIMIT - THERMAL_NO_LIMIT>; - contribution = <100>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml index 1175bb358382..ce72347e29d1 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml @@ -23,6 +23,9 @@ properties: - qcom,sdm845-lmh - qcom,sm8150-lmh - items: + - const: qcom,sdm670-lmh + - const: qcom,sdm845-lmh + - items: - const: qcom,qcm2290-lmh - const: qcom,sm8150-lmh diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 3c5256b0cd9f..7d34ba00e684 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -54,6 +54,7 @@ properties: - description: v2 of TSENS items: - enum: + - qcom,eliza-tsens - qcom,glymur-tsens - qcom,kaanapali-tsens - qcom,milos-tsens @@ -71,6 +72,7 @@ properties: - qcom,sc8180x-tsens - qcom,sc8280xp-tsens - qcom,sdm630-tsens + - qcom,sdm670-tsens - qcom,sdm845-tsens - qcom,sm6115-tsens - qcom,sm6350-tsens @@ -81,6 +83,7 @@ properties: - qcom,sm8450-tsens - qcom,sm8550-tsens - qcom,sm8650-tsens + - qcom,sm8750-tsens - qcom,x1e80100-tsens - const: qcom,tsens-v2 diff --git a/Documentation/devicetree/bindings/thermal/spear-thermal.txt b/Documentation/devicetree/bindings/thermal/spear-thermal.txt deleted file mode 100644 index 93e3b67c102d..000000000000 --- a/Documentation/devicetree/bindings/thermal/spear-thermal.txt +++ /dev/null @@ -1,14 +0,0 @@ -* SPEAr Thermal - -Required properties: -- compatible : "st,thermal-spear1340" -- reg : Address range of the thermal registers -- st,thermal-flags: flags used to enable thermal sensor - -Example: - - thermal@fc000000 { - compatible = "st,thermal-spear1340"; - reg = <0xfc000000 0x1000>; - st,thermal-flags = <0x7000>; - }; diff --git a/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml new file mode 100644 index 000000000000..e3462a974691 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/st,thermal-spear1340.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPEAr Thermal Sensor + +maintainers: + - Viresh Kumar <vireshk@kernel.org> + +properties: + compatible: + const: st,thermal-spear1340 + + reg: + maxItems: 1 + + st,thermal-flags: + description: flags used to enable thermal sensor + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - st,thermal-flags + +additionalProperties: false + +examples: + - | + thermal@fc000000 { + compatible = "st,thermal-spear1340"; + reg = <0xfc000000 0x1000>; + st,thermal-flags = <0x7000>; + }; diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml index 0de0a9757ccc..07d9f576ffe7 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml @@ -129,63 +129,60 @@ patternProperties: which the thermal framework needs to take action. The actions to be taken are defined in another node called cooling-maps. - patternProperties: - "^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$": - type: object - - properties: - temperature: - $ref: /schemas/types.yaml#/definitions/int32 - minimum: -273000 - maximum: 200000 - description: - An integer expressing the trip temperature in millicelsius. - - hysteresis: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - An unsigned integer expressing the hysteresis delta with - respect to the trip temperature property above, also in - millicelsius. Any cooling action initiated by the framework is - maintained until the temperature falls below - (trip temperature - hysteresis). This potentially prevents a - situation where the trip gets constantly triggered soon after - cooling action is removed. - - type: - $ref: /schemas/types.yaml#/definitions/string - enum: - - active # enable active cooling e.g. fans - - passive # enable passive cooling e.g. throttling cpu - - hot # send notification to driver - - critical # send notification to driver, trigger shutdown - description: | - There are four valid trip types: active, passive, hot, - critical. - - The critical trip type is used to set the maximum - temperature threshold above which the HW becomes - unstable and underlying firmware might even trigger a - reboot. Hitting the critical threshold triggers a system - shutdown. - - The hot trip type can be used to send a notification to - the thermal driver (if a .notify callback is registered). - The action to be taken is left to the driver. - - The passive trip type can be used to slow down HW e.g. run - the CPU, GPU, bus at a lower frequency. - - The active trip type can be used to control other HW to - help in cooling e.g. fans can be sped up or slowed down - - required: - - temperature - - hysteresis - - type - additionalProperties: false - - additionalProperties: false + additionalProperties: + type: object + additionalProperties: false + + properties: + temperature: + $ref: /schemas/types.yaml#/definitions/int32 + minimum: -273000 + maximum: 200000 + description: + An integer expressing the trip temperature in millicelsius. + + hysteresis: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + An unsigned integer expressing the hysteresis delta with + respect to the trip temperature property above, also in + millicelsius. Any cooling action initiated by the framework is + maintained until the temperature falls below + (trip temperature - hysteresis). This potentially prevents a + situation where the trip gets constantly triggered soon after + cooling action is removed. + + type: + $ref: /schemas/types.yaml#/definitions/string + enum: + - active # enable active cooling e.g. fans + - passive # enable passive cooling e.g. throttling cpu + - hot # send notification to driver + - critical # send notification to driver, trigger shutdown + description: | + There are four valid trip types: active, passive, hot, + critical. + + The critical trip type is used to set the maximum + temperature threshold above which the HW becomes + unstable and underlying firmware might even trigger a + reboot. Hitting the critical threshold triggers a system + shutdown. + + The hot trip type can be used to send a notification to + the thermal driver (if a .notify callback is registered). + The action to be taken is left to the driver. + + The passive trip type can be used to slow down HW e.g. run + the CPU, GPU, bus at a lower frequency. + + The active trip type can be used to control other HW to + help in cooling e.g. fans can be sped up or slowed down + + required: + - temperature + - hysteresis + - type cooling-maps: type: object diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index 3bab40500df9..3c16b260db04 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -31,6 +31,7 @@ properties: - enum: - canaan,k210-clint # Canaan Kendryte K210 - eswin,eic7700-clint # ESWIN EIC7700 + - microchip,pic64gx-clint # Microchip PIC64GX - sifive,fu540-c000-clint # SiFive FU540 - spacemit,k1-clint # SpacemiT K1 - spacemit,k3-clint # SpacemiT K3 diff --git a/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml b/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml index b1597db04263..3538eafff6b1 100644 --- a/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml +++ b/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Xilinx LogiCORE IP AXI Timer maintainers: - - Sean Anderson <sean.anderson@seco.com> + - Sean Anderson <sean.anderson@linux.dev> properties: compatible: diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml index 456797967adc..a96d6cd23895 100644 --- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml +++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml @@ -25,6 +25,8 @@ properties: - nvidia,tegra194-gte-lic - nvidia,tegra234-gte-aon - nvidia,tegra234-gte-lic + - nvidia,tegra264-gte-aon + - nvidia,tegra264-gte-lic reg: maxItems: 1 @@ -112,10 +114,22 @@ allOf: contains: enum: - nvidia,tegra234-gte-aon + - nvidia,tegra264-gte-aon then: required: - nvidia,gpio-controller + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra264-gte-aon + - nvidia,tegra264-gte-lic + then: + properties: + nvidia,slices: false + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index a482aeadcd44..23fd4513933a 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -59,6 +59,10 @@ properties: - adi,lt7182s # AMS iAQ-Core VOC Sensor - ams,iaq-core + # Aosong temperature & humidity sensors with I2C interface + - aosong,aht10 + - aosong,aht20 + - aosong,dht20 # Arduino microcontroller interface over SPI on UnoQ board - arduino,unoq-mcu # Temperature monitoring of Astera Labs PT5161L PCIe retimer @@ -97,6 +101,10 @@ properties: - delta,dps920ab # 1/4 Brick DC/DC Regulated Power Module - delta,q54sj108a2 + # 1300W 1/4 Brick DC/DC Regulated Power Module + - delta,q54sn120a1 + # 2000W 1/4 Brick DC/DC Regulated Power Module + - delta,q54sw120a7 # Devantech SRF02 ultrasonic ranger in I2C mode - devantech,srf02 # Devantech SRF08 ultrasonic ranger @@ -157,6 +165,9 @@ properties: - infineon,xdpe15284 # Infineon Multi-phase Digital VR Controller xdpe152c4 - infineon,xdpe152c4 + # Infineon Multi-phase Digital VR Controller xdpe1a2g7b + - infineon,xdpe1a2g5b + - infineon,xdpe1a2g7b # Injoinic IP5108 2.0A Power Bank IC with I2C - injoinic,ip5108 # Injoinic IP5109 2.1A Power Bank IC with I2C @@ -430,6 +441,8 @@ properties: - smsc,emc6d103s # Socionext Uniphier SMP control registers - socionext,uniphier-smpctrl + # Sony APS-379 Power Supply + - sony,aps-379 # SparkFun Qwiic Joystick (COM-15168) with i2c interface - sparkfun,qwiic-joystick # STMicroelectronics Hot-swap controller stef48h28 diff --git a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml index d94ef4e6b85a..3c407426d697 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml @@ -15,6 +15,7 @@ select: compatible: contains: enum: + - qcom,milos-ufshc - qcom,msm8998-ufshc - qcom,qcs8300-ufshc - qcom,sa8775p-ufshc @@ -31,21 +32,28 @@ select: properties: compatible: - items: - - enum: - - qcom,msm8998-ufshc - - qcom,qcs8300-ufshc - - qcom,sa8775p-ufshc - - qcom,sc7180-ufshc - - qcom,sc7280-ufshc - - qcom,sc8180x-ufshc - - qcom,sc8280xp-ufshc - - qcom,sm8250-ufshc - - qcom,sm8350-ufshc - - qcom,sm8450-ufshc - - qcom,sm8550-ufshc - - const: qcom,ufshc - - const: jedec,ufs-2.0 + oneOf: + - items: + - enum: + - qcom,x1e80100-ufshc + - const: qcom,sm8550-ufshc + - const: qcom,ufshc + - items: + - enum: + - qcom,milos-ufshc + - qcom,msm8998-ufshc + - qcom,qcs8300-ufshc + - qcom,sa8775p-ufshc + - qcom,sc7180-ufshc + - qcom,sc7280-ufshc + - qcom,sc8180x-ufshc + - qcom,sc8280xp-ufshc + - qcom,sm8250-ufshc + - qcom,sm8350-ufshc + - qcom,sm8450-ufshc + - qcom,sm8550-ufshc + - const: qcom,ufshc + - const: jedec,ufs-2.0 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml index cea84ab2204f..f28641c6e68f 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml @@ -15,6 +15,7 @@ select: compatible: contains: enum: + - qcom,eliza-ufshc - qcom,kaanapali-ufshc - qcom,sm8650-ufshc - qcom,sm8750-ufshc @@ -25,6 +26,7 @@ properties: compatible: items: - enum: + - qcom,eliza-ufshc - qcom,kaanapali-ufshc - qcom,sm8650-ufshc - qcom,sm8750-ufshc @@ -66,6 +68,18 @@ required: allOf: - $ref: qcom,ufs-common.yaml + - if: + properties: + compatible: + contains: + enum: + - qcom,eliza-ufshc + then: + properties: + reg: + minItems: 2 + reg-names: + minItems: 2 unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml b/Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml index c7d17cf4dc42..e738153a309c 100644 --- a/Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml +++ b/Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml @@ -41,7 +41,7 @@ properties: maxItems: 1 resets: - maxItems: 4 + maxItems: 5 reset-names: items: @@ -49,6 +49,7 @@ properties: - const: sys - const: ufs - const: grf + - const: mphy reset-gpios: maxItems: 1 @@ -98,8 +99,8 @@ examples: interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>; power-domains = <&power RK3576_PD_USB>; resets = <&cru SRST_A_UFS_BIU>, <&cru SRST_A_UFS_SYS>, <&cru SRST_A_UFS>, - <&cru SRST_P_UFS_GRF>; - reset-names = "biu", "sys", "ufs", "grf"; + <&cru SRST_P_UFS_GRF>, <&cru SRST_MPHY_INIT>; + reset-names = "biu", "sys", "ufs", "grf", "mphy"; reset-gpios = <&gpio4 RK_PD0 GPIO_ACTIVE_LOW>; }; }; diff --git a/Documentation/devicetree/bindings/usb/atmel,at91rm9200-udc.yaml b/Documentation/devicetree/bindings/usb/atmel,at91rm9200-udc.yaml new file mode 100644 index 000000000000..a4eabb935e6e --- /dev/null +++ b/Documentation/devicetree/bindings/usb/atmel,at91rm9200-udc.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/atmel,at91rm9200-udc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel AT91 USB Device Controller (UDC) + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +description: + The Atmel AT91 USB Device Controller provides USB gadget (device-mode) + functionality on AT91 SoCs. It requires a peripheral clock and an AHB + clock for operation and may optionally control VBUS power through a GPIO. + +properties: + compatible: + enum: + - atmel,at91rm9200-udc + - atmel,at91sam9260-udc + - atmel,at91sam9261-udc + - atmel,at91sam9263-udc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: pclk + - const: hclk + + atmel,vbus-gpio: + description: GPIO used to enable or control VBUS power for the USB bus. + maxItems: 1 + + atmel,matrix: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the Atmel bus matrix controller. + + atmel,pullup-gpio: + description: + GPIO controlling the USB D+ pull-up resistor used to signal device + connection to the host. + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/gpio/gpio.h> + gadget@fffa4000 { + compatible = "atmel,at91rm9200-udc"; + reg = <0xfffa4000 0x4000>; + interrupts = <11 IRQ_TYPE_LEVEL_HIGH 2>; + clocks = <&udc_clk>, <&udpck>; + clock-names = "pclk", "hclk"; + atmel,vbus-gpio = <&pioC 5 GPIO_ACTIVE_HIGH>; + }; +... diff --git a/Documentation/devicetree/bindings/usb/atmel,at91sam9rl-udc.yaml b/Documentation/devicetree/bindings/usb/atmel,at91sam9rl-udc.yaml new file mode 100644 index 000000000000..cdbbd17f8036 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/atmel,at91sam9rl-udc.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/atmel,at91sam9rl-udc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel High-Speed USB Device Controller (USBA) + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +description: + The Atmel High-Speed USB Device Controller (USBA) provides USB 2.0 + high-speed gadget functionality on several Atmel and Microchip SoCs. + The controller requires a peripheral clock and a host clock for operation + and may optionally use a GPIO to detect VBUS presence. + +properties: + compatible: + oneOf: + - enum: + - atmel,at91sam9rl-udc + - atmel,at91sam9g45-udc + - atmel,sama5d3-udc + - items: + - const: microchip,lan9662-udc + - const: atmel,sama5d3-udc + - const: microchip,sam9x60-udc + + reg: + maxItems: 2 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + minItems: 2 + maxItems: 2 + items: + enum: [pclk, hclk] + + atmel,vbus-gpio: + description: GPIO used to detect the presence of VBUS, indicating that + the USB cable is connected. + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/gpio/gpio.h> + gadget@fff78000 { + compatible = "atmel,at91sam9g45-udc"; + reg = <0x00600000 0x80000 + 0xfff78000 0x400>; + interrupts = <27 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 27>, <&pmc PMC_TYPE_CORE PMC_UTMI>; + clock-names = "pclk", "hclk"; + atmel,vbus-gpio = <&pioC 15 GPIO_ACTIVE_HIGH>; + }; +... diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt deleted file mode 100644 index 12183ef47ee4..000000000000 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ /dev/null @@ -1,125 +0,0 @@ -Atmel SOC USB controllers - -OHCI - -Required properties: - - compatible: Should be "atmel,at91rm9200-ohci" for USB controllers - used in host mode. - - reg: Address and length of the register set for the device - - interrupts: Should contain ohci interrupt - - clocks: Should reference the peripheral, host and system clocks - - clock-names: Should contain three strings - "ohci_clk" for the peripheral clock - "hclk" for the host clock - "uhpck" for the system clock - - num-ports: Number of ports. - - atmel,vbus-gpio: If present, specifies a gpio that needs to be - activated for the bus to be powered. - - atmel,oc-gpio: If present, specifies a gpio that needs to be - activated for the overcurrent detection. - -usb0: ohci@500000 { - compatible = "atmel,at91rm9200-ohci", "usb-ohci"; - reg = <0x00500000 0x100000>; - clocks = <&uhphs_clk>, <&uhphs_clk>, <&uhpck>; - clock-names = "ohci_clk", "hclk", "uhpck"; - interrupts = <20 4>; - num-ports = <2>; -}; - -EHCI - -Required properties: - - compatible: Should be "atmel,at91sam9g45-ehci" for USB controllers - used in host mode. - - reg: Address and length of the register set for the device - - interrupts: Should contain ehci interrupt - - clocks: Should reference the peripheral and the UTMI clocks - - clock-names: Should contain two strings - "ehci_clk" for the peripheral clock - "usb_clk" for the UTMI clock - -Optional properties: - - phy_type : For multi port host USB controllers, should be one of - "utmi", or "hsic". - -usb1: ehci@800000 { - compatible = "atmel,at91sam9g45-ehci", "usb-ehci"; - reg = <0x00800000 0x100000>; - interrupts = <22 4>; - clocks = <&utmi>, <&uhphs_clk>; - clock-names = "usb_clk", "ehci_clk"; -}; - -AT91 USB device controller - -Required properties: - - compatible: Should be one of the following - "atmel,at91rm9200-udc" - "atmel,at91sam9260-udc" - "atmel,at91sam9261-udc" - "atmel,at91sam9263-udc" - - reg: Address and length of the register set for the device - - interrupts: Should contain macb interrupt - - clocks: Should reference the peripheral and the AHB clocks - - clock-names: Should contain two strings - "pclk" for the peripheral clock - "hclk" for the AHB clock - -Optional properties: - - atmel,vbus-gpio: If present, specifies a gpio that needs to be - activated for the bus to be powered. - -usb1: gadget@fffa4000 { - compatible = "atmel,at91rm9200-udc"; - reg = <0xfffa4000 0x4000>; - interrupts = <10 4>; - clocks = <&udc_clk>, <&udpck>; - clock-names = "pclk", "hclk"; - atmel,vbus-gpio = <&pioC 5 0>; -}; - -Atmel High-Speed USB device controller - -Required properties: - - compatible: Should be one of the following - "atmel,at91sam9rl-udc" - "atmel,at91sam9g45-udc" - "atmel,sama5d3-udc" - "microchip,sam9x60-udc" - "microchip,lan9662-udc" - For "microchip,lan9662-udc" the fallback "atmel,sama5d3-udc" - is required. - - reg: Address and length of the register set for the device - - interrupts: Should contain usba interrupt - - clocks: Should reference the peripheral and host clocks - - clock-names: Should contain two strings - "pclk" for the peripheral clock - "hclk" for the host clock - -Deprecated property: - - ep childnode: To specify the number of endpoints and their properties. - -Optional properties: - - atmel,vbus-gpio: If present, specifies a gpio that allows to detect whether - vbus is present (USB is connected). - -Deprecated child node properties: - - name: Name of the endpoint. - - reg: Num of the endpoint. - - atmel,fifo-size: Size of the fifo. - - atmel,nb-banks: Number of banks. - - atmel,can-dma: Boolean to specify if the endpoint support DMA. - - atmel,can-isoc: Boolean to specify if the endpoint support ISOC. - -usb2: gadget@fff78000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "atmel,at91sam9rl-udc"; - reg = <0x00600000 0x80000 - 0xfff78000 0x400>; - interrupts = <27 4 0>; - clocks = <&utmi>, <&udphs_clk>; - clock-names = "hclk", "pclk"; - atmel,vbus-gpio = <&pioB 19 0>; -}; diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml index f454ddd9bbaa..a199e5ba6416 100644 --- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml +++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml @@ -85,6 +85,7 @@ required: allOf: - $ref: usb-drd.yaml# + - $ref: usb-xhci.yaml# unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/usb/corechips,sl6341.yaml b/Documentation/devicetree/bindings/usb/corechips,sl6341.yaml new file mode 100644 index 000000000000..82996791aaf1 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/corechips,sl6341.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/corechips,sl6341.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Corechips SL6341 USB 2.0/3.0 Hub Controller + +maintainers: + - Alexey Charkov <alchark@flipper.net> + +allOf: + - $ref: usb-hub.yaml# + +properties: + compatible: + enum: + - usb3431,6241 + - usb3431,6341 + + reg: true + + peer-hub: true + + reset-gpios: + description: GPIO controlling the RSTN pin. + + vdd1v1-supply: + description: + The regulator that provides 1.1V core power to the hub. + + vdd3v3-supply: + description: + The regulator that provides 3.3V IO power to the hub. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + patternProperties: + '^port@': + $ref: /schemas/graph.yaml#/properties/port + + properties: + reg: + minimum: 1 + maximum: 4 + +required: + - compatible + - reg + - vdd1v1-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + usb { + #address-cells = <1>; + #size-cells = <0>; + + /* 2.0 hub */ + hub_2_0: hub@1 { + compatible = "usb3431,6241"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>; + vdd1v1-supply = <&vdd1v1_hub>; + }; + + /* 3.0 hub */ + hub_3_0: hub@2 { + compatible = "usb3431,6341"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>; + vdd1v1-supply = <&vdd1v1_hub>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml index 73e7a60a0060..66d368e65c0a 100644 --- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml @@ -10,6 +10,8 @@ title: NXP iMX8MP Soc USB Controller maintainers: - Li Jun <jun.li@nxp.com> +deprecated: true + properties: compatible: oneOf: diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml index 601f097c09a6..55a5aa7d7a54 100644 --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml @@ -9,19 +9,6 @@ title: USB EHCI Controller maintainers: - Greg Kroah-Hartman <gregkh@linuxfoundation.org> -allOf: - - $ref: usb-hcd.yaml - - if: - properties: - compatible: - not: - contains: - const: ibm,usb-ehci-440epx - then: - properties: - reg: - maxItems: 1 - properties: compatible: oneOf: @@ -167,6 +154,39 @@ required: - reg - interrupts +allOf: + - $ref: usb-hcd.yaml + - if: + properties: + compatible: + not: + contains: + const: ibm,usb-ehci-440epx + then: + properties: + reg: + maxItems: 1 + - if: + properties: + compatible: + contains: + const: atmel,at91sam9g45-ehci + then: + properties: + clock-names: + items: + - const: usb_clk + - const: ehci_clk + + phy_type: + enum: + - utmi + - hsic + + required: + - clocks + - clock-names + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml index 961cbf85eeb5..d42f448fa204 100644 --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml @@ -55,6 +55,7 @@ properties: - ti,ohci-omap3 - items: - enum: + - atmel,at91rm9200-ohci - cavium,octeon-6335-ohci - nintendo,hollywood-usb-ohci - nxp,ohci-nxp @@ -137,6 +138,24 @@ properties: The associated ISP1301 device. Necessary for the UDC controller for connecting to the USB physical layer. + atmel,vbus-gpio: + description: + GPIO used to control or sense the USB VBUS power. Each entry + represents a VBUS-related GPIO; count and order may vary by hardware. + Entries follow standard GPIO specifier format. A value of 0 indicates + an unused or unavailable VBUS signal. + minItems: 1 + maxItems: 3 + + atmel,oc-gpio: + description: + GPIO used to signal USB overcurrent condition. Each entry represents + an OC detection GPIO; count and order may vary by hardware. Entries + follow standard GPIO specifier format. A value of 0 indicates an + unused or unavailable OC signal. + minItems: 1 + maxItems: 3 + required: - compatible - reg @@ -145,6 +164,28 @@ required: allOf: - $ref: usb-hcd.yaml - if: + properties: + compatible: + contains: + const: atmel,at91rm9200-ohci + then: + properties: + clock-names: + items: + - const: ohci_clk + - const: hclk + - const: uhpck + + required: + - clocks + - clock-names + + else: + properties: + atmel,vbus-gpio: false + atmel,oc-gpio: false + + - if: not: properties: compatible: diff --git a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml index 3de4dc40b791..003c0b713068 100644 --- a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml +++ b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml @@ -32,6 +32,9 @@ properties: description: Properties for usb c connector. + vbus-supply: + description: Regulator to control sourcing Vbus. + required: - compatible - reg @@ -53,6 +56,7 @@ examples: reg = <0x25>; interrupt-parent = <&gpa8>; interrupts = <2 IRQ_TYPE_LEVEL_LOW>; + vbus-supply = <&chgin_otg_reg>; connector { compatible = "usb-c-connector"; @@ -75,6 +79,10 @@ examples: PDO_FIXED(9000, 2000, 0)>; sink-bc12-completion-time-ms = <500>; pd-revision = /bits/ 8 <0x03 0x01 0x01 0x08>; + sink-load-step = <150>; + sink-load-characteristics = /bits/ 16 <SINK_LOAD_CHAR(0, 1, 1, 2)>; + sink-compliance = /bits/ 8 <(COMPLIANCE_LPS | COMPLIANCE_PS1)>; + charging-adapter-pdp-milliwatt = <18000>; }; }; }; diff --git a/Documentation/devicetree/bindings/usb/maxim,max3421.txt b/Documentation/devicetree/bindings/usb/maxim,max3421.txt deleted file mode 100644 index 90495b1aeec2..000000000000 --- a/Documentation/devicetree/bindings/usb/maxim,max3421.txt +++ /dev/null @@ -1,23 +0,0 @@ -Maxim Integrated SPI-based USB 2.0 host controller MAX3421E - -Required properties: - - compatible: Should be "maxim,max3421" - - spi-max-frequency: maximum frequency for this device must not exceed 26 MHz. - - reg: chip select number to which this device is connected. - - maxim,vbus-en-pin: <GPOUTx ACTIVE_LEVEL> - GPOUTx is the number (1-8) of the GPOUT pin of MAX3421E to drive Vbus. - ACTIVE_LEVEL is 0 or 1. - - interrupts: the interrupt line description for the interrupt controller. - The driver configures MAX3421E for active low level triggered interrupts, - configure your interrupt line accordingly. - -Example: - - usb@0 { - compatible = "maxim,max3421"; - reg = <0>; - maxim,vbus-en-pin = <3 1>; - spi-max-frequency = <26000000>; - interrupt-parent = <&PIC>; - interrupts = <42>; - }; diff --git a/Documentation/devicetree/bindings/usb/maxim,max3421.yaml b/Documentation/devicetree/bindings/usb/maxim,max3421.yaml new file mode 100644 index 000000000000..4639be7ab059 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/maxim,max3421.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/maxim,max3421.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MAXIM MAX3421e USB Peripheral/Host Controller + +maintainers: + - David Mosberger <davidm@egauge.net> + +description: | + The controller provides USB2.0 compliant with Full Speed or Low Speed when in + the host mode. At peripheral, it operates at Full Speed. At both cases, it + uses a SPI interface. + Datasheet at: + https://www.analog.com/media/en/technical-documentation/data-sheets/max3421e.pdf + +properties: + compatible: + const: maxim,max3421 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + spi-max-frequency: + maximum: 26000000 + + maxim,vbus-en-pin: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + One of eight GPOUT pins to control external VBUS power and the polarity + of the active level. It's an array of GPIO number and the active level of it. + minItems: 2 + maxItems: 2 + +required: + - compatible + - reg + - interrupts + - maxim,vbus-en-pin + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + usb@0 { + compatible = "maxim,max3421"; + reg = <0>; + maxim,vbus-en-pin = <3 1>; + spi-max-frequency = <26000000>; + interrupt-parent = <&gpio>; + interrupts = <42>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml b/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml index a812317d8089..c4e1c2d73bdb 100644 --- a/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml +++ b/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml @@ -37,6 +37,9 @@ properties: clocks: maxItems: 1 + resets: + maxItems: 1 + microchip,ext-vbus-drv: description: Some ULPI USB PHYs do not support an internal VBUS supply and driving diff --git a/Documentation/devicetree/bindings/usb/nxp,imx-dwc3.yaml b/Documentation/devicetree/bindings/usb/nxp,imx-dwc3.yaml new file mode 100644 index 000000000000..1911e71f01eb --- /dev/null +++ b/Documentation/devicetree/bindings/usb/nxp,imx-dwc3.yaml @@ -0,0 +1,123 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2026 NXP +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/nxp,imx-dwc3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX Soc USB Controller + +maintainers: + - Xu Yang <xu.yang_2@nxp.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - nxp,imx94-dwc3 + - nxp,imx95-dwc3 + - const: nxp,imx8mp-dwc3 + - const: nxp,imx8mp-dwc3 + + reg: + items: + - description: DWC3 core registers + - description: HSIO Block Control registers + - description: Wrapper registers of dwc3 core + + reg-names: + items: + - const: core + - const: blkctl + - const: glue + + interrupts: + items: + - description: DWC3 controller interrupt + - description: Wakeup interrupt from glue logic + + interrupt-names: + items: + - const: dwc_usb3 + - const: wakeup + + iommus: + maxItems: 1 + + clocks: + items: + - description: System hsio root clock + - description: SoC Bus Clock for AHB/AXI/Native + - description: Reference clock for generating ITP when UTMI/ULPI PHY is suspended + - description: Suspend clock used for usb wakeup logic + + clock-names: + items: + - const: hsio + - const: bus_early + - const: ref + - const: suspend + + fsl,permanently-attached: + type: boolean + description: + Indicates if the device attached to a downstream port is + permanently attached + + fsl,disable-port-power-control: + type: boolean + description: + Indicates whether the host controller implementation includes port + power control. Defines Bit 3 in capability register (HCCPARAMS) + + fsl,over-current-active-low: + type: boolean + description: + Over current signal polarity is active low + + fsl,power-active-low: + type: boolean + description: + Power pad (PWR) polarity is active low + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - power-domains + +allOf: + - $ref: snps,dwc3-common.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + usb@4c100000 { + compatible = "nxp,imx94-dwc3", "nxp,imx8mp-dwc3"; + reg = <0x4c100000 0x10000>, + <0x4c010010 0x04>, + <0x4c1f0000 0x20>; + reg-names = "core", "blkctl", "glue"; + clocks = <&scmi_clk 74>, //IMX94_CLK_HSIO + <&scmi_clk 74>, //IMX94_CLK_HSIO + <&scmi_clk 2>, //IMX94_CLK_24M + <&scmi_clk 1>; //IMX94_CLK_32K + clock-names = "hsio", "bus_early", "ref", "suspend"; + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 386 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "dwc_usb3", "wakeup"; + power-domains = <&scmi_devpd 13>; //IMX94_PD_HSIO_TOP + phys = <&usb3_phy>, <&usb3_phy>; + phy-names = "usb2-phy", "usb3-phy"; + snps,gfladj-refclk-lpm-sel-quirk; + snps,parkmode-disable-ss-quirk; + }; diff --git a/Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml b/Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml index 65a8632b4d9e..581e5916eadd 100644 --- a/Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml +++ b/Documentation/devicetree/bindings/usb/nxp,ptn5110.yaml @@ -26,6 +26,10 @@ properties: $ref: /schemas/connector/usb-connector.yaml# unevaluatedProperties: false + orientation-gpios: + maxItems: 1 + description: Optional orientation select control + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/usb/ohci-st.txt b/Documentation/devicetree/bindings/usb/ohci-st.txt deleted file mode 100644 index 1c735573abc0..000000000000 --- a/Documentation/devicetree/bindings/usb/ohci-st.txt +++ /dev/null @@ -1,36 +0,0 @@ -ST USB OHCI controller - -Required properties: - - - compatible : must be "st,st-ohci-300x" - - reg : physical base addresses of the controller and length of memory mapped - region - - interrupts : one OHCI controller interrupt should be described here - - clocks : phandle list of usb clocks - - clock-names : should be "ic" for interconnect clock and "clk48" -See: Documentation/devicetree/bindings/clock/clock-bindings.txt - - - phys : phandle for the PHY device - - phy-names : should be "usb" - - - resets : phandle to the powerdown and reset controller for the USB IP - - reset-names : should be "power" and "softreset". -See: Documentation/devicetree/bindings/reset/st,stih407-powerdown.yaml -See: Documentation/devicetree/bindings/reset/reset.txt - -Example: - - ohci0: usb@fe1ffc00 { - compatible = "st,st-ohci-300x"; - reg = <0xfe1ffc00 0x100>; - interrupts = <GIC_SPI 149 IRQ_TYPE_NONE>; - clocks = <&clk_s_a1_ls 0>, - <&clockgen_b0 0>; - clock-names = "ic", "clk48"; - phys = <&usb2_phy>; - phy-names = "usb"; - - resets = <&powerdown STIH416_USB0_POWERDOWN>, - <&softreset STIH416_USB0_SOFTRESET>; - reset-names = "power", "softreset"; - }; diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt deleted file mode 100644 index f0dbc5ae45ae..000000000000 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ /dev/null @@ -1,80 +0,0 @@ -OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS - -OMAP MUSB GLUE - - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb" - - ti,hwmods : must be "usb_otg_hs" - - multipoint : Should be "1" indicating the musb controller supports - multipoint. This is a MUSB configuration-specific setting. - - num-eps : Specifies the number of endpoints. This is also a - MUSB configuration-specific setting. Should be set to "16" - - ram-bits : Specifies the ram address size. Should be set to "12" - - interface-type : This is a board specific setting to describe the type of - interface between the controller and the phy. It should be "0" or "1" - specifying ULPI and UTMI respectively. - - mode : Should be "3" to represent OTG. "1" signifies HOST and "2" - represents PERIPHERAL. - - power : Should be "50". This signifies the controller can supply up to - 100mA when operating in host mode. - - usb-phy : the phandle for the PHY device - - phys : the phandle for the PHY device (used by generic PHY framework) - - phy-names : the names of the PHY corresponding to the PHYs present in the - *phy* phandle. - -Optional properties: - - ctrl-module : phandle of the control module this glue uses to write to - mailbox - -SOC specific device node entry -usb_otg_hs: usb_otg_hs@4a0ab000 { - compatible = "ti,omap4-musb"; - ti,hwmods = "usb_otg_hs"; - multipoint = <1>; - num-eps = <16>; - ram-bits = <12>; - ctrl-module = <&omap_control_usb>; - phys = <&usb2_phy>; - phy-names = "usb2-phy"; -}; - -Board specific device node entry -&usb_otg_hs { - interface-type = <1>; - mode = <3>; - power = <50>; -}; - -OMAP DWC3 GLUE - - compatible : Should be - * "ti,dwc3" for OMAP5 and DRA7 - * "ti,am437x-dwc3" for AM437x - - ti,hwmods : Should be "usb_otg_ss" - - reg : Address and length of the register set for the device. - - interrupts : The irq number of this device that is used to interrupt the - MPU - - #address-cells, #size-cells : Must be present if the device has sub-nodes - - utmi-mode : controls the source of UTMI/PIPE status for VBUS and OTG ID. - It should be set to "1" for HW mode and "2" for SW mode. - - ranges: the child address space are mapped 1:1 onto the parent address space - -Optional Properties: - - extcon : phandle for the extcon device omap dwc3 uses to detect - connect/disconnect events. - - vbus-supply : phandle to the regulator device tree node if needed. - -Sub-nodes: -The dwc3 core should be added as subnode to omap dwc3 glue. -- dwc3 : - The binding details of dwc3 can be found in: - Documentation/devicetree/bindings/usb/snps,dwc3.yaml - -omap_dwc3 { - compatible = "ti,dwc3"; - ti,hwmods = "usb_otg_ss"; - reg = <0x4a020000 0x1ff>; - interrupts = <0 93 4>; - #address-cells = <1>; - #size-cells = <1>; - utmi-mode = <2>; - ranges; -}; - diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml index 7d784a648b7d..8201656b41ed 100644 --- a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml @@ -24,6 +24,7 @@ properties: compatible: items: - enum: + - qcom,eliza-dwc3 - qcom,glymur-dwc3 - qcom,glymur-dwc3-mp - qcom,ipq4019-dwc3 @@ -153,8 +154,6 @@ properties: wakeup-source: true -# Required child node: - required: - compatible - reg @@ -175,6 +174,7 @@ allOf: then: properties: clocks: + minItems: 3 maxItems: 3 clock-names: items: @@ -203,6 +203,7 @@ allOf: compatible: contains: enum: + - qcom,ipq5424-dwc3 - qcom,ipq9574-dwc3 - qcom,kaanapali-dwc3 - qcom,msm8953-dwc3 @@ -222,6 +223,7 @@ allOf: then: properties: clocks: + minItems: 5 maxItems: 5 clock-names: items: @@ -264,6 +266,7 @@ allOf: then: properties: clocks: + minItems: 4 maxItems: 4 clock-names: items: @@ -283,6 +286,7 @@ allOf: then: properties: clocks: + minItems: 4 maxItems: 4 clock-names: items: @@ -303,6 +307,7 @@ allOf: then: properties: clocks: + minItems: 9 maxItems: 9 clock-names: items: @@ -346,14 +351,17 @@ allOf: compatible: contains: enum: + - qcom,eliza-dwc3 - qcom,milos-dwc3 - qcom,qcm2290-dwc3 - qcom,qcs615-dwc3 - qcom,sar2130p-dwc3 - qcom,sc8180x-dwc3 - qcom,sc8180x-dwc3-mp + - qcom,sm4250-dwc3 - qcom,sm6115-dwc3 - qcom,sm6125-dwc3 + - qcom,sm6375-dwc3 - qcom,sm8150-dwc3 - qcom,sm8250-dwc3 - qcom,sm8450-dwc3 @@ -363,6 +371,7 @@ allOf: properties: clocks: minItems: 6 + maxItems: 6 clock-names: items: - const: cfg_noc @@ -404,6 +413,7 @@ allOf: then: properties: clocks: + minItems: 7 maxItems: 7 clock-names: items: @@ -446,6 +456,7 @@ allOf: - qcom,msm8996-dwc3 - qcom,qcs404-dwc3 - qcom,sdm660-dwc3 + - qcom,sm4250-dwc3 - qcom,sm6115-dwc3 - qcom,sm6125-dwc3 then: @@ -472,6 +483,7 @@ allOf: then: properties: interrupts: + minItems: 4 maxItems: 4 interrupt-names: items: @@ -485,6 +497,26 @@ allOf: compatible: contains: enum: + - qcom,ipq5424-dwc3 + - qcom,ipq9574-dwc3 + then: + properties: + interrupts: + minItems: 5 + maxItems: 5 + interrupt-names: + items: + - const: dwc_usb3 + - const: pwr_event + - const: qusb2_phy + - const: dp_hs_phy_irq + - const: dm_hs_phy_irq + + - if: + properties: + compatible: + contains: + enum: - qcom,glymur-dwc3 - qcom,milos-dwc3 - qcom,x1e80100-dwc3 @@ -500,13 +532,14 @@ allOf: - const: pwr_event - const: dp_hs_phy_irq - const: dm_hs_phy_irq - - const: ss_phy_irq + - enum: [hs_phy_irq, ss_phy_irq] - if: properties: compatible: contains: enum: + - qcom,eliza-dwc3 - qcom,ipq4019-dwc3 - qcom,ipq8064-dwc3 - qcom,kaanapali-dwc3 @@ -523,8 +556,8 @@ allOf: - qcom,sdx55-dwc3 - qcom,sdx65-dwc3 - qcom,sdx75-dwc3 - - qcom,sm4250-dwc3 - qcom,sm6350-dwc3 + - qcom,sm6375-dwc3 - qcom,sm8150-dwc3 - qcom,sm8250-dwc3 - qcom,sm8350-dwc3 diff --git a/Documentation/devicetree/bindings/usb/renesas,upd720201-pci.yaml b/Documentation/devicetree/bindings/usb/renesas,upd720201-pci.yaml new file mode 100644 index 000000000000..4e890d0d2070 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/renesas,upd720201-pci.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/renesas,upd720201-pci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: UPD720201/UPD720202 USB 3.0 xHCI Host Controller (PCIe) + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +description: + UPD720201 USB 3.0 xHCI Host Controller via PCIe x1 Gen2 interface. + The UPD720202 supports up to two downstream ports, while UPD720201 + supports up to four downstream USB 3.0 rev1.0 ports. + +properties: + compatible: + enum: + - pci1912,0014 # UPD720201 + - pci1912,0015 # UPD720202 + + reg: + maxItems: 1 + + avdd33-supply: + description: +3.3 V power supply for analog circuit + + vdd10-supply: + description: +1.05 V power supply + + vdd33-supply: + description: +3.3 V power supply + +required: + - compatible + - reg + - avdd33-supply + - vdd10-supply + - vdd33-supply + +allOf: + - $ref: usb-xhci.yaml + +additionalProperties: true + +examples: + - | + pcie@0 { + reg = <0x0 0x1000>; + ranges = <0x02000000 0x0 0x100000 0x10000000 0x0 0x0>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + + usb-controller@0 { + compatible = "pci1912,0014"; + reg = <0x0 0x0 0x0 0x0 0x0>; + avdd33-supply = <&avdd33_reg>; + vdd10-supply = <&vdd10_reg>; + vdd33-supply = <&vdd33_reg>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml index ae611f7e57ca..7ded36384518 100644 --- a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml +++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml @@ -18,11 +18,21 @@ description: | properties: compatible: - enum: - - richtek,rt1711h - - richtek,rt1715 + oneOf: + - enum: + - richtek,rt1711h + - richtek,rt1715 + - items: + - enum: + - hynetek,husb311 + - const: richtek,rt1711h + - items: + - enum: + - etekmicro,et7304 + - const: richtek,rt1715 description: - RT1711H support PD20, RT1715 support PD30 except Fast Role Swap. + RT1711H support PD20, ET7304 and RT1715 support PD30 except Fast Role Swap. + HUSB311 is a rebrand of RT1711H which is pin and register compatible. reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/usb/spacemit,k1-dwc3.yaml b/Documentation/devicetree/bindings/usb/spacemit,k1-dwc3.yaml index 0f0b5e061ca1..cc27b363ca79 100644 --- a/Documentation/devicetree/bindings/usb/spacemit,k1-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/spacemit,k1-dwc3.yaml @@ -27,7 +27,9 @@ allOf: properties: compatible: - const: spacemit,k1-dwc3 + enum: + - spacemit,k1-dwc3 + - spacemit,k3-dwc3 reg: maxItems: 1 @@ -42,11 +44,13 @@ properties: maxItems: 1 phys: + minItems: 1 items: - description: phandle to USB2/HS PHY - description: phandle to USB3/SS PHY phy-names: + minItems: 1 items: - const: usb2-phy - const: usb3-phy diff --git a/Documentation/devicetree/bindings/usb/st,st-ohci-300x.yaml b/Documentation/devicetree/bindings/usb/st,st-ohci-300x.yaml new file mode 100644 index 000000000000..a225bf5a2ee4 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/st,st-ohci-300x.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/st,st-ohci-300x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics USB OHCI Controller + +maintainers: + - Peter Griffin <peter.griffin@linaro.org> + +description: + The STMicroelectronics USB Open Host Controller Interface (OHCI) + compliant USB host controller found in ST platforms. The controller + provides full- and low-speed USB host functionality and interfaces + with an external USB PHY. It requires dedicated clock, reset, and + interrupt resources for proper operation. + +allOf: + - $ref: /schemas/usb/usb-hcd.yaml# + +properties: + compatible: + const: st,st-ohci-300x + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: ic + - const: clk48 + + phys: + maxItems: 1 + + phy-names: + items: + - const: usb + + resets: + maxItems: 2 + + reset-names: + items: + - const: power + - const: softreset + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - phys + - phy-names + - resets + - reset-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/reset/stih407-resets.h> + usb@fe1ffc00 { + compatible = "st,st-ohci-300x"; + reg = <0xfe1ffc00 0x100>; + interrupts = <GIC_SPI 149 IRQ_TYPE_NONE>; + clocks = <&clk_s_a1_ls 0>, + <&clockgen_b0 0>; + clock-names = "ic", "clk48"; + phys = <&usb2_phy>; + phy-names = "usb"; + resets = <&powerdown STIH407_USB2_PORT0_POWERDOWN>, + <&softreset STIH407_USB2_PORT0_SOFTRESET>; + reset-names = "power", "softreset"; + }; +... diff --git a/Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml b/Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml new file mode 100644 index 000000000000..fbabe99e9d5c --- /dev/null +++ b/Documentation/devicetree/bindings/usb/starfive,jhb100-dwc3.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/starfive,jhb100-dwc3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JHB100 DWC3 USB SoC Controller + +maintainers: + - Minda Chen <minda.chen@starfivetech.com> + +description: + The USB DRD controller on JHB100 BMC SoC. + +allOf: + - $ref: snps,dwc3-common.yaml# + +properties: + compatible: + const: starfive,jhb100-dwc3 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: USB main enable clk + - description: DWC3 bus early clock + - description: DWC3 ref clock + + clock-names: + items: + - const: main + - const: bus_early + - const: ref + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +unevaluatedProperties: false + +examples: + - | + usb@11800000 { + compatible = "starfive,jhb100-dwc3"; + reg = <0x11800000 0x10000>; + clocks = <&usbcrg 9>, + <&usbcrg 5>, + <&usbcrg 6>; + clock-names = "main", "bus_early", "ref"; + resets = <&usbcrg 4>; + interrupts = <105>; + dr_mode = "host"; + }; diff --git a/Documentation/devicetree/bindings/usb/terminus,fe11.yaml b/Documentation/devicetree/bindings/usb/terminus,fe11.yaml new file mode 100644 index 000000000000..645f97d73807 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/terminus,fe11.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/terminus,fe11.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Terminus FE1.1/1.1S USB 2.0 Hub Controller + +maintainers: + - Yixun Lan <dlan@kernel.org> + +allOf: + - $ref: usb-hub.yaml# + +properties: + compatible: + enum: + - usb1a40,0101 + + reg: true + + reset-gpios: + description: + GPIO controlling the RESET#. + + vdd-supply: + description: + Regulator supply to the hub, one of 3.3V or 5V can be chosen. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + patternProperties: + '^port@': + $ref: /schemas/graph.yaml#/properties/port + + properties: + reg: + minimum: 1 + maximum: 4 + +required: + - compatible + - reg + - vdd-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + usb { + #address-cells = <1>; + #size-cells = <0>; + + hub@1 { + compatible = "usb1a40,0101"; + reg = <1>; + reset-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>; + vdd-supply = <&vcc_5v>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/ti,dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,dwc3.yaml new file mode 100644 index 000000000000..77ac11c3b2db --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ti,dwc3.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/ti,dwc3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments OMAP DWC3 USB Glue Layer + +maintainers: + - Felipe Balbi <balbi@ti.com> + +description: + Texas Instruments glue layer for Synopsys DesignWare USB3 (DWC3) + controller on OMAP and AM43xx SoCs. Manages SoC-specific integration + including register mapping, interrupt routing, UTMI/PIPE interface mode + selection (HW/SW), and child DWC3 core instantiation via address space + translation. Supports both legacy single-instance and multi-instance + (numbered) configurations. + +properties: + compatible: + enum: + - ti,dwc3 + - ti,am437x-dwc3 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + utmi-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Controls the source of UTMI/PIPE status for VBUS and OTG ID. + 1 for HW mode, 2 for SW mode. + enum: [1, 2] + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + + extcon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle for the extcon device used to detect connect/ + disconnect events. + + vbus-supply: + description: Phandle to the regulator device tree node if needed. + +patternProperties: + "^usb@[0-9a-f]+$": + type: object + $ref: snps,dwc3.yaml# + unevaluatedProperties: false + +required: + - reg + - compatible + - interrupts + - "#address-cells" + - "#size-cells" + - utmi-mode + - ranges + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + omap_dwc3_1@0 { + compatible = "ti,dwc3"; + reg = <0x0 0x10000>; + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <1>; + utmi-mode = <2>; + ranges = <0 0 0x20000>; + + usb@10000 { + compatible = "snps,dwc3"; + reg = <0x10000 0x17000>; + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "peripheral", "host", "otg"; + phys = <&usb2_phy1>, <&usb3_phy1>; + phy-names = "usb2-phy", "usb3-phy"; + maximum-speed = "super-speed"; + dr_mode = "otg"; + snps,dis_u3_susphy_quirk; + snps,dis_u2_susphy_quirk; + }; + }; +... diff --git a/Documentation/devicetree/bindings/usb/ti,omap4-musb.yaml b/Documentation/devicetree/bindings/usb/ti,omap4-musb.yaml new file mode 100644 index 000000000000..a3d15f217658 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ti,omap4-musb.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/ti,omap4-musb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments OMAP MUSB USB OTG Controller + +maintainers: + - Felipe Balbi <balbi@ti.com> + +description: + Texas Instruments glue layer for the Mentor Graphics MUSB OTG controller. + Handles SoC-specific integration including PHY interface bridging(ULPI/ + UTMI), interrupt aggregation, DMA engine coordination (internal/ + external), VBUS/session control via control module mailbox, and + clock/reset management. Provides fixed hardware configuration parameters + to the generic MUSB core driver. + +properties: + compatible: + enum: + - ti,omap3-musb + - ti,omap4-musb + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + items: + - const: mc + - const: dma + + multipoint: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Indicates the MUSB controller supports multipoint. This is a MUSB + configuration-specific setting. + const: 1 + + num-eps: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Specifies the number of endpoints. This is a MUSB configuration + specific setting. + const: 16 + + ram-bits: + description: Specifies the RAM address size. + const: 12 + + interface-type: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Describes the type of interface between the controller and the PHY. + 0 for ULPI, 1 for UTMI. + enum: [0, 1] + + mode: + $ref: /schemas/types.yaml#/definitions/uint32 + description: 1 for HOST, 2 for PERIPHERAL, 3 for OTG. + enum: [1, 2, 3] + + power: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Indicates the maximum current the controller can supply when + operating in host mode. A value of 50 corresponds to 100 mA, and a + value of 150 corresponds to 300 mA. + enum: [50, 150] + + phys: + maxItems: 1 + + phy-names: + const: usb2-phy + + usb-phy: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: Phandle for the PHY device. + deprecated: true + + ctrl-module: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle of the control module this glue uses to write to mailbox. + +required: + - reg + - compatible + - interrupts + - interrupt-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + usb@4a0ab000 { + compatible = "ti,omap4-musb"; + reg = <0x4a0ab000 0x1000>; + interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "mc", "dma"; + multipoint = <1>; + num-eps = <16>; + ram-bits = <12>; + ctrl-module = <&omap_control_usb>; + phys = <&usb2_phy>; + phy-names = "usb2-phy"; + interface-type = <1>; + mode = <3>; + power = <50>; + }; +... diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml index 5e3eae9c2961..07e13fae640b 100644 --- a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml @@ -11,6 +11,7 @@ maintainers: allOf: - $ref: usb-device.yaml# + - $ref: usb-hub.yaml# properties: compatible: @@ -30,17 +31,20 @@ properties: description: VDD power supply to the hub - peer-hub: - $ref: /schemas/types.yaml#/definitions/phandle - description: - phandle to the peer hub on the controller. + peer-hub: true + +patternProperties: + '^.*@[1-9a-f][0-9a-f]*$': + description: The hard wired USB devices + type: object + $ref: /schemas/usb/usb-device.yaml + additionalProperties: true required: - compatible - reg - - peer-hub -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -56,7 +60,14 @@ examples: compatible = "usb451,8142"; reg = <1>; peer-hub = <&hub_3_0>; + #address-cells = <1>; + #size-cells = <0>; reset-gpios = <&gpio1 11 GPIO_ACTIVE_LOW>; + + hub@1 { + compatible = "usb123,4567"; + reg = <1>; + }; }; /* 3.0 hub on port 2 */ diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index ee7fd3cfe203..28784d66ae7b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -172,6 +172,8 @@ patternProperties: description: ARM Ltd. "^armadeus,.*": description: ARMadeus Systems SARL + "^armchina,.*": + description: Arm Technology (China) Co., Ltd. "^armsom,.*": description: ArmSoM Technology Co., Ltd. "^arrow,.*": @@ -221,6 +223,8 @@ patternProperties: description: Axiado Corporation "^axis,.*": description: Axis Communications AB + "^ayaneo,.*": + description: Anyun Intelligent Technology (Hong Kong) Co., Ltd "^azoteq,.*": description: Azoteq (Pty) Ltd "^azw,.*": @@ -361,6 +365,8 @@ patternProperties: description: CORERIVER Semiconductor Co.,Ltd. "^corpro,.*": description: Chengdu Corpro Technology Co., Ltd. + "^corechips,.*": + description: Shenzhen Corechips Microelectronics Co., Ltd. "^cortina,.*": description: Cortina Systems, Inc. "^cosmic,.*": @@ -441,6 +447,8 @@ patternProperties: description: D-Link Corporation "^dmo,.*": description: Data Modul AG + "^doestek,.*": + description: Doestek Co., Ltd. "^domintech,.*": description: Domintech Co., Ltd. "^dongwoon,.*": @@ -541,6 +549,8 @@ patternProperties: description: ESTeem Wireless Modems "^eswin,.*": description: Beijing ESWIN Technology Group Co. Ltd. + "^etekmicro,.*": + description: Wuxi ETEK Micro-Electronics Co.,Ltd. "^ettus,.*": description: NI Ettus Research "^eukrea,.*": @@ -709,6 +719,8 @@ patternProperties: description: Hitex Development Tools "^hitron,.*": description: HiTRON Electronics Corporation + "^holitech,.*": + description: Jiangxi Holitech Technology Co., Ltd. "^holt,.*": description: Holt Integrated Circuits, Inc. "^holtek,.*": @@ -743,6 +755,8 @@ patternProperties: description: Hycon Technology Corp. "^hydis,.*": description: Hydis Technologies + "^hynetek,.*": + description: Hynetek Semiconductor Co., Ltd. "^hynitron,.*": description: Shanghai Hynitron Microelectronics Co. Ltd. "^hynix,.*": @@ -973,6 +987,8 @@ patternProperties: description: Liebherr-Werk Nenzing GmbH "^lxa,.*": description: Linux Automation GmbH + "^lxd,.*": + description: LXD Research & Display, LLC "^m5stack,.*": description: M5Stack "^macnica,.*": @@ -1199,6 +1215,8 @@ patternProperties: description: One Laptop Per Child "^oneplus,.*": description: OnePlus Technology (Shenzhen) Co., Ltd. + "^onething,.*": + description: Shenzhen OneThing Technologies Co., Ltd. "^onie,.*": description: Open Network Install Environment group "^onion,.*": @@ -1610,6 +1628,8 @@ patternProperties: "^synopsys,.*": description: Synopsys, Inc. (deprecated, use snps) deprecated: true + "^taiguanck,.*": + description: Shenzhen Top Group Technology Co., Ltd. "^taos,.*": description: Texas Advanced Optoelectronic Solutions Inc. "^tbs,.*": @@ -1731,6 +1751,8 @@ patternProperties: description: Ufi Space Co., Ltd. "^ugoos,.*": description: Ugoos Industrial Co., Ltd. + "^ultrapower,.*": + description: Beijing Ultrapower Software Co., Ltd. "^uni-t,.*": description: Uni-Trend Technology (China) Co., Ltd. "^uniwest,.*": @@ -1761,6 +1783,8 @@ patternProperties: description: Variscite Ltd. "^vdl,.*": description: Van der Laan b.v. + "^verisilicon,.*": + description: VeriSilicon Microelectronics (Shanghai) Co., Ltd. "^vertexcom,.*": description: Vertexcom Technologies, Inc. "^via,.*": @@ -1821,6 +1845,8 @@ patternProperties: description: Wi2Wi, Inc. "^widora,.*": description: Beijing Widora Technology Co., Ltd. + "^wiko,.*": + description: Wiko SAS "^wiligear,.*": description: Wiligear, Ltd. "^willsemi,.*": diff --git a/Documentation/devicetree/of_unittest.rst b/Documentation/devicetree/of_unittest.rst index 8b557acd29d1..6ed6e3291964 100644 --- a/Documentation/devicetree/of_unittest.rst +++ b/Documentation/devicetree/of_unittest.rst @@ -48,30 +48,30 @@ from 'scripts/dtc/of_unittest_expect --help'. 3. Test-data ============ -The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains +The Device Tree Source file (drivers/of/unittest-data/testcases.dtso) contains the test data required for executing the unit tests automated in drivers/of/unittest.c. See the content of the folder:: drivers/of/unittest-data/tests-*.dtsi -for the Device Tree Source Include files (.dtsi) included in testcases.dts. +for the Device Tree Source Include files (.dtsi) included in testcases.dtso. When the kernel is built with CONFIG_OF_UNITTEST enabled, then the following make rule:: - $(obj)/%.dtb: $(src)/%.dts FORCE - $(call if_changed_dep, dtc) + $(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE + $(call if_changed_dep,dtc) -is used to compile the DT source file (testcases.dts) into a binary blob -(testcases.dtb), also referred as flattened DT. +is used to compile the DT source file (testcases.dtso) into a binary blob +(testcases.dtbo), also referred as flattened DT. After that, using the following rule the binary blob above is wrapped as an -assembly file (testcases.dtb.S):: +assembly file (testcases.dtbo.S):: - $(obj)/%.dtb.S: $(obj)/%.dtb - $(call cmd, dt_S_dtb) + $(obj)/%.dtbo.S: $(obj)/%.dtbo FORCE + $(call if_changed,wrap_S_dtb) -The assembly file is compiled into an object file (testcases.dtb.o), and is +The assembly file is compiled into an object file (testcases.dtbo.o), and is linked into the kernel image. diff --git a/Documentation/doc-guide/kernel-doc.rst b/Documentation/doc-guide/kernel-doc.rst index 8d2c09fb36e4..1c148fe8e1f9 100644 --- a/Documentation/doc-guide/kernel-doc.rst +++ b/Documentation/doc-guide/kernel-doc.rst @@ -213,6 +213,10 @@ The ``private:`` and ``public:`` tags must begin immediately following a ``/*`` comment marker. They may optionally include comments between the ``:`` and the ending ``*/`` marker. +When ``private:`` is used on nested structs, it propagates only to inner +structs/unions. + + Example:: /** @@ -256,8 +260,10 @@ It is possible to document nested structs and unions, like:: union { struct { int memb1; + /* private: hides memb2 from documentation */ int memb2; }; + /* Everything here is public again, as private scope finished */ struct { void *memb3; int memb4; diff --git a/Documentation/driver-api/acpi/acpi-drivers.rst b/Documentation/driver-api/acpi/acpi-drivers.rst index b1fbbddb8b4f..376b6d8a678c 100644 --- a/Documentation/driver-api/acpi/acpi-drivers.rst +++ b/Documentation/driver-api/acpi/acpi-drivers.rst @@ -47,7 +47,7 @@ generally be avoided and so struct acpi_driver objects should not be used. Moreover, a device ID is necessary to bind a driver directly to an ACPI device node, but device IDs are not generally associated with all of them. Some of them contain alternative information allowing the corresponding pieces of -hardware to be identified, for example represeted by an _ADR object return +hardware to be identified, for example represented by an _ADR object return value, and device IDs are not used in those cases. In consequence, confusingly enough, binding an ACPI driver to an ACPI device node may even be impossible. diff --git a/Documentation/driver-api/clk.rst b/Documentation/driver-api/clk.rst index 93bab5336dfd..c6aca8186a78 100644 --- a/Documentation/driver-api/clk.rst +++ b/Documentation/driver-api/clk.rst @@ -77,9 +77,6 @@ the operations defined in clk-provider.h:: void (*disable_unused)(struct clk_hw *hw); unsigned long (*recalc_rate)(struct clk_hw *hw, unsigned long parent_rate); - long (*round_rate)(struct clk_hw *hw, - unsigned long rate, - unsigned long *parent_rate); int (*determine_rate)(struct clk_hw *hw, struct clk_rate_request *req); int (*set_parent)(struct clk_hw *hw, u8 index); @@ -220,9 +217,7 @@ optional or must be evaluated on a case-by-case basis. +----------------+------+-------------+---------------+-------------+------+ |.recalc_rate | | y | | | | +----------------+------+-------------+---------------+-------------+------+ - |.round_rate | | y [1]_ | | | | - +----------------+------+-------------+---------------+-------------+------+ - |.determine_rate | | y [1]_ | | | | + |.determine_rate | | y | | | | +----------------+------+-------------+---------------+-------------+------+ |.set_rate | | y | | | | +----------------+------+-------------+---------------+-------------+------+ @@ -238,8 +233,6 @@ optional or must be evaluated on a case-by-case basis. |.init | | | | | | +----------------+------+-------------+---------------+-------------+------+ -.. [1] either one of round_rate or determine_rate is required. - Finally, register your clock at run-time with a hardware-specific registration function. This function simply populates struct clk_foo's data and then passes the common struct clk parameters to the framework diff --git a/Documentation/driver-api/cxl/platform/acpi/cedt.rst b/Documentation/driver-api/cxl/platform/acpi/cedt.rst index 1d9c9d3592dc..217a75fb4881 100644 --- a/Documentation/driver-api/cxl/platform/acpi/cedt.rst +++ b/Documentation/driver-api/cxl/platform/acpi/cedt.rst @@ -55,7 +55,7 @@ voltile vs persistent, etc). One or more bits may be set. :: Bit[1]: CXL Type 3 Memory Bit[2]: Volatile Memory Bit[3]: Persistent Memory - Bit[4]: Fixed Config (HPA cannot be re-used) + Bit[4]: Fixed Config (HPA cannot be reused) INTRA-host-bridge interleave (multiple devices on one host bridge) is NOT reported in this structure, and is solely defined via CXL device decoder diff --git a/Documentation/driver-api/cxl/platform/bios-and-efi.rst b/Documentation/driver-api/cxl/platform/bios-and-efi.rst index a4b44c018f09..5d918b06f6c0 100644 --- a/Documentation/driver-api/cxl/platform/bios-and-efi.rst +++ b/Documentation/driver-api/cxl/platform/bios-and-efi.rst @@ -277,7 +277,7 @@ The CFMWS field of the CEDT has special restriction bits which describe whether the described memory region allows volatile or persistent memory (or both). If the platform intends to support either: -1) A device with multiple medias, or +1) A device with multiple media, or 2) Using a persistent memory device as normal memory A platform may wish to create multiple CEDT CFMWS entries to describe the same diff --git a/Documentation/driver-api/dmaengine/pxa_dma.rst b/Documentation/driver-api/dmaengine/pxa_dma.rst index 442ee691a190..8f9da66b0bfa 100644 --- a/Documentation/driver-api/dmaengine/pxa_dma.rst +++ b/Documentation/driver-api/dmaengine/pxa_dma.rst @@ -40,7 +40,7 @@ Design ====== a) Virtual channels Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual -channel" linked to the requestor line, and the physical DMA channel is +channel" linked to the requester line, and the physical DMA channel is assigned on the fly when the transfer is issued. b) Transfer anatomy for a scatter-gather transfer diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-api/dpll.rst index 83118c728ed9..93c191b2d089 100644 --- a/Documentation/driver-api/dpll.rst +++ b/Documentation/driver-api/dpll.rst @@ -250,6 +250,24 @@ in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute. ``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature =============================== ======================== +Frequency monitor +================= + +Some DPLL devices may offer the capability to measure the actual +frequency of all available input pins. The attribute and current feature state +shall be included in the response message of the ``DPLL_CMD_DEVICE_GET`` +command for supported DPLL devices. In such cases, users can also control +the feature using the ``DPLL_CMD_DEVICE_SET`` command by setting the +``enum dpll_feature_state`` values for the attribute. +Once enabled the measured input frequency for each input pin shall be +returned in the ``DPLL_A_PIN_MEASURED_FREQUENCY`` attribute. The value +is in millihertz (mHz), using ``DPLL_PIN_MEASURED_FREQUENCY_DIVIDER`` +as the divider. + + =============================== ======================== + ``DPLL_A_FREQUENCY_MONITOR`` attr state of a feature + =============================== ======================== + Embedded SYNC ============= @@ -411,6 +429,8 @@ according to attribute purpose. ``DPLL_A_PIN_STATE`` attr state of pin on the parent pin ``DPLL_A_PIN_CAPABILITIES`` attr bitmask of pin capabilities + ``DPLL_A_PIN_MEASURED_FREQUENCY`` attr measured frequency of + an input pin in mHz ==================================== ================================== ==================================== ================================= diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 7d2b897d66fa..017fb155a5bc 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -464,3 +464,7 @@ SPI WATCHDOG devm_watchdog_register_device() + +WORKQUEUE + devm_alloc_workqueue() + devm_alloc_ordered_workqueue() diff --git a/Documentation/driver-api/early-userspace/early_userspace_support.rst b/Documentation/driver-api/early-userspace/early_userspace_support.rst index 61bdeac1bae5..60d1e1bc9413 100644 --- a/Documentation/driver-api/early-userspace/early_userspace_support.rst +++ b/Documentation/driver-api/early-userspace/early_userspace_support.rst @@ -73,7 +73,7 @@ usr/gen_initramfs.sh. This means that CONFIG_INITRAMFS_SOURCE can really be interpreted as any legal argument to 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 +usr/gen_init_cpio file directives are output. If a file is 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 diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst index 069b54d8591b..4ac1e12cf872 100644 --- a/Documentation/driver-api/gpio/board.rst +++ b/Documentation/driver-api/gpio/board.rst @@ -108,9 +108,8 @@ macro, which ties a software node representing the GPIO controller with consumer device. It allows consumers to use regular gpiolib APIs, such as gpiod_get(), gpiod_get_optional(). -The software node representing a GPIO controller need not be attached to the -GPIO controller device. The only requirement is that the node must be -registered and its name must match the GPIO controller's label. +The software node representing a GPIO controller must be attached to the +GPIO controller device - either as the primary or the secondary firmware node. For example, here is how to describe a single GPIO-connected LED. This is an alternative to using platform_data on legacy systems. @@ -122,8 +121,7 @@ alternative to using platform_data on legacy systems. #include <linux/gpio/property.h> /* - * 1. Define a node for the GPIO controller. Its .name must match the - * controller's label. + * 1. Define a node for the GPIO controller. */ static const struct software_node gpio_controller_node = { .name = "gpio-foo", @@ -153,6 +151,21 @@ alternative to using platform_data on legacy systems. }; software_node_register_node_group(swnodes); + /* + * 5. Attach the GPIO controller's software node to the device and + * register it. + */ + static void gpio_foo_register(void) + { + struct platform_device_info pdev_info = { + .name = "gpio-foo", + .id = PLATFORM_DEVID_NONE, + .swnode = &gpio_controller_node + }; + + platform_device_register_full(&pdev_info); + } + // Then register a platform_device for "leds-gpio" and associate // it with &led_device_swnode via .fwnode. @@ -239,22 +252,6 @@ mapping and is thus transparent to GPIO consumers. A set of functions such as gpiod_set_value() is available to work with the new descriptor-oriented interface. -Boards using platform data can also hog GPIO lines by defining GPIO hog tables. - -.. code-block:: c - - struct gpiod_hog gpio_hog_table[] = { - GPIO_HOG("gpio.0", 10, "foo", GPIO_ACTIVE_LOW, GPIOD_OUT_HIGH), - { } - }; - -And the table can be added to the board code as follows:: - - gpiod_add_hogs(gpio_hog_table); - -The line will be hogged as soon as the gpiochip is created or - in case the -chip was created earlier - when the hog table is registered. - Arrays of pins -------------- In addition to requesting pins belonging to a function one by one, a device may diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 85d86f92c41b..a4f160b95089 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -87,6 +87,33 @@ atomic context on realtime kernels (inside hard IRQ handlers and similar contexts). Normally this should not be required. +GPIO level semantics +-------------------- + +The gpip_chip .get/set[_multiple]() line values are clamped to the boolean +space [0, 1], low level or high level. + +Low and high values are defined as physical low on the line in/out to the +connector such as a physical pad, pin or rail. + +The GPIO library has internal logic to handle lines that are active low, such +as indicated by overstrike or #name in a schematic, and the driver should not +try to second-guess the logic value of a line. + +The way GPIO values are handled by the consumers is that the library present +the *logical* value to the consumer. A line is *asserted* if its *logical* +value is 1, and *de-asserted* if its logical value is 0. If inversion is +required, this is handled by gpiolib and configured using hardware descriptions +such as device tree or ACPI that can clearly indicate if a line is active +high or low. + +Since electronics commonly insert inverters as driving stages or protection +buffers in front of a GPIO line it is necessary that this semantic is part +of the hardware description, so that consumers such as kernel drivers need +not worry about this, and can for example assert a RESET line tied to a GPIO +pin by setting it to logic 1 even if it is physically active low. + + GPIO electrical configuration ----------------------------- diff --git a/Documentation/driver-api/gpio/legacy-boards.rst b/Documentation/driver-api/gpio/legacy-boards.rst index 46e3a26dba77..a9d33bcbb176 100644 --- a/Documentation/driver-api/gpio/legacy-boards.rst +++ b/Documentation/driver-api/gpio/legacy-boards.rst @@ -36,12 +36,10 @@ Requirements for GPIO Properties When using software nodes to describe GPIO connections, the following requirements must be met for the GPIO core to correctly resolve the reference: -1. **The GPIO controller's software node "name" must match the controller's - "label".** The gpiolib core uses this name to find the corresponding - struct gpio_chip at runtime. - This software node has to be registered, but need not be attached to the - device representing the GPIO controller that is providing the GPIO in - question. It may be left as a "free floating" node. +1. **The GPIO controller's software node must be registered and attached to + the controller's ``struct device`` either as its primary or secondary + firmware node.** The gpiolib core uses the address of the firmware node to + find the corresponding ``struct gpio_chip`` at runtime. 2. **The GPIO property must be a reference.** The ``PROPERTY_ENTRY_GPIO()`` macro handles this as it is an alias for ``PROPERTY_ENTRY_REF()``. @@ -121,13 +119,21 @@ A typical legacy board file might look like this: /* Device registration */ static int __init myboard_init(void) { + struct platform_device_info pdev_info = { + .name = MYBOARD_GPIO_CONTROLLER, + .id = PLATFORM_DEVID_NONE, + .swnode = &gpio_controller_node + }; + gpiod_add_lookup_table(&myboard_leds_gpios); gpiod_add_lookup_table(&myboard_buttons_gpios); + platform_device_register_full(&pdev_info); platform_device_register_data(NULL, "leds-gpio", -1, &myboard_leds_pdata, sizeof(myboard_leds_pdata)); platform_device_register_data(NULL, "gpio-keys", -1, - &myboard_buttons_pdata, sizeof(myboard_buttons_pdata)); + &myboard_buttons_pdata, + sizeof(myboard_buttons_pdata)); return 0; } @@ -141,8 +147,7 @@ Step 1: Define the GPIO Controller Node *************************************** First, define a software node that represents the GPIO controller that the -LEDs and buttons are connected to. The ``name`` of this node must match the -name of the driver for the GPIO controller (e.g., "gpio-foo"). +LEDs and buttons are connected to. The ``name`` of this node is optional. .. code-block:: c @@ -258,12 +263,23 @@ software nodes using the ``fwnode`` field in struct platform_device_info. return error; memset(&pdev_info, 0, sizeof(pdev_info)); + pdev_info.name = MYBOARD_GPIO_CONTROLLER; + pdev_info.id = PLATFORM_DEVID_NONE; + pdev_info.swnode = &myboard_gpio_controller_node; + gpio_pdev = platform_device_register_full(&pdev_info); + if (IS_ERR(gpio_pdev)) { + error = PTR_ERR(gpio_pdev); + goto err_unregister_nodes; + } + + memset(&pdev_info, 0, sizeof(pdev_info)); pdev_info.name = "leds-gpio"; pdev_info.id = PLATFORM_DEVID_NONE; pdev_info.fwnode = software_node_fwnode(&myboard_leds_node); leds_pdev = platform_device_register_full(&pdev_info); if (IS_ERR(leds_pdev)) { error = PTR_ERR(leds_pdev); + platform_device_unregister(gpio_pdev); goto err_unregister_nodes; } @@ -274,6 +290,7 @@ software nodes using the ``fwnode`` field in struct platform_device_info. keys_pdev = platform_device_register_full(&pdev_info); if (IS_ERR(keys_pdev)) { error = PTR_ERR(keys_pdev); + platform_device_unregister(gpio_pdev); platform_device_unregister(leds_pdev); goto err_unregister_nodes; } @@ -289,6 +306,7 @@ software nodes using the ``fwnode`` field in struct platform_device_info. { platform_device_unregister(keys_pdev); platform_device_unregister(leds_pdev); + platform_device_unregister(gpio_pdev); software_node_unregister_node_group(myboard_swnodes); } diff --git a/Documentation/driver-api/infiniband.rst b/Documentation/driver-api/infiniband.rst index 10d8be9e74fe..d48f246774d2 100644 --- a/Documentation/driver-api/infiniband.rst +++ b/Documentation/driver-api/infiniband.rst @@ -92,21 +92,6 @@ iSCSI Extensions for RDMA (iSER) .. kernel-doc:: drivers/infiniband/ulp/iser/iser_verbs.c :internal: -Omni-Path (OPA) Virtual NIC support ------------------------------------ - -.. kernel-doc:: drivers/infiniband/ulp/opa_vnic/opa_vnic_internal.h - :internal: - -.. kernel-doc:: drivers/infiniband/ulp/opa_vnic/opa_vnic_encap.h - :internal: - -.. kernel-doc:: drivers/infiniband/ulp/opa_vnic/opa_vnic_vema_iface.c - :internal: - -.. kernel-doc:: drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c - :internal: - InfiniBand SCSI RDMA protocol target support -------------------------------------------- diff --git a/Documentation/driver-api/interconnect.rst b/Documentation/driver-api/interconnect.rst index a92d0f277a1f..cebb77b49d8d 100644 --- a/Documentation/driver-api/interconnect.rst +++ b/Documentation/driver-api/interconnect.rst @@ -84,13 +84,25 @@ be registered with the interconnect provider core. .. kernel-doc:: include/linux/interconnect-provider.h +.. kernel-doc:: drivers/interconnect/core.c + :functions: icc_provider_init icc_provider_register icc_provider_deregister + icc_node_create icc_node_create_dyn icc_node_destroy + icc_node_add icc_node_del icc_nodes_remove icc_node_set_name + icc_link_create icc_link_nodes + Interconnect consumers ---------------------- Interconnect consumers are the clients which use the interconnect APIs to get paths between endpoints and set their bandwidth/latency/QoS requirements -for these interconnect paths. These interfaces are not currently -documented. +for these interconnect paths. + +.. kernel-doc:: drivers/interconnect/core.c + :functions: devm_of_icc_get of_icc_get_by_index of_icc_get icc_get + icc_put icc_enable icc_disable icc_set_bw icc_set_tag + icc_get_name + +.. kernel-doc:: drivers/interconnect/bulk.c Interconnect debugfs interfaces ------------------------------- diff --git a/Documentation/driver-api/libata.rst b/Documentation/driver-api/libata.rst index 93d97fe78e3f..28b8437f6e4f 100644 --- a/Documentation/driver-api/libata.rst +++ b/Documentation/driver-api/libata.rst @@ -286,7 +286,7 @@ and other exceptional conditions. The primary responsibility of an implementation is to call :c:func:`ata_std_error_handler`. :c:func:`ata_std_error_handler` will perform a standard error handling sequence -to resurect failed devices, detach lost devices and add new devices (if any). +to resurrect failed devices, detach lost devices and add new devices (if any). This function will call the various reset operations for a port, as needed. These operations are as follows. diff --git a/Documentation/driver-api/media/drivers/zoran.rst b/Documentation/driver-api/media/drivers/zoran.rst index 3e05b7f0442a..2538473c3233 100644 --- a/Documentation/driver-api/media/drivers/zoran.rst +++ b/Documentation/driver-api/media/drivers/zoran.rst @@ -222,7 +222,7 @@ The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong, Ireland, Nigeria, South Africa. The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate, -and is used in Argentina, Uruguay, an a few others +and is used in Argentina, Uruguay, and a few others We do not talk about how the audio is broadcast ! diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst index d5593182a3f9..08fc2cfc07a3 100644 --- a/Documentation/driver-api/media/index.rst +++ b/Documentation/driver-api/media/index.rst @@ -26,6 +26,7 @@ Documentation/userspace-api/media/index.rst :numbered: maintainer-entry-profile + media-committers v4l2-core dtv-core diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst index 2127e5b15e8f..c5c00c66d85c 100644 --- a/Documentation/driver-api/media/maintainer-entry-profile.rst +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst @@ -1,45 +1,328 @@ +.. SPDX-License-Identifier: GPL-2.0 + Media Subsystem Profile ======================= Overview -------- -The media subsystem covers support for a variety of devices: stream -capture, analog and digital TV streams, cameras, remote controllers, HDMI CEC -and media pipeline control. +The Linux Media Community (aka: the LinuxTV Community) is formed by +developers working on Linux Kernel Media Subsystem, together with users +who also play an important role in testing the code. + +The Media Subsystem has code to support a wide variety of media-related +devices: stream capture, analog and digital TV streams, cameras, +video codecs, video processing (resizers, etc.), radio, remote controllers, +HDMI CEC and media pipeline control. -It covers, mainly, the contents of those directories: +The Media Subsystem consists of the following directories in the kernel +tree: - drivers/media - drivers/staging/media + - include/media + - Documentation/devicetree/bindings/media/\ [1]_ - Documentation/admin-guide/media - Documentation/driver-api/media - Documentation/userspace-api/media - - Documentation/devicetree/bindings/media/\ [1]_ - - include/media .. [1] Device tree bindings are maintained by the OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS maintainers (see the MAINTAINERS file). So, changes there must be reviewed - by them before being merged via the media subsystem's development + by them before being merged into the media subsystem's development tree. Both media userspace and Kernel APIs are documented and the documentation must be kept in sync with the API changes. It means that all patches that add new features to the subsystem must also bring changes to the -corresponding API files. +corresponding API documentation. + +Media Maintainers +----------------- + +Media Maintainers are not just people capable of writing code, but they +are developers who have demonstrated their ability to collaborate with +the team, get the most knowledgeable people to review code, contribute +high-quality code, and follow through to fix issues (in code or tests). + +Due to the size and wide scope of the media subsystem, multiple layers of +maintainers are required, each with their own areas of expertise: + +- **Media Driver Maintainer**: + Responsible for one or more drivers within the Media Subsystem. They + are listed in the MAINTAINERS file as maintainer for those drivers. Media + Driver Maintainers review patches for those drivers, provide feedback if + patches do not follow the subsystem rules, or are not using the + media kernel or userspace APIs correctly, or if they have poor code + quality. + + If you are the patch author, you work with other Media + Maintainers to ensure your patches are reviewed. + + Some Media Driver Maintainers have additional responsibilities. They have + been granted Patchwork access and keep + `Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_ + up to date, decide when patches are ready for merging, and create Pull + Requests for the Media Subsystem Maintainers to merge. + +- **Media Core Maintainer**: + Media Driver Maintainers with Patchwork access who are also responsible for + one or more media core frameworks. + + Core framework changes are done via consensus between the relevant Media + Core Maintainers. Media Maintainers may include core framework changes in + their Pull Requests if they are signed off by the relevant Media Core + Maintainers. + +- **Media Subsystem Maintainers**: + Media Core Maintainers who are also responsible for the subsystem as a + whole, with access to the entire subsystem. Responsible for merging Pull + Requests from other Media Maintainers. + + Userspace API/ABI changes are made via consensus among Media Subsystem + Maintainers\ [2]_. Media Maintainers may include API/ABI changes in + their Pull Requests if they are signed off by all Media Subsystem + Maintainers. + +All Media Maintainers shall agree with the Kernel development process as +described in Documentation/process/index.rst and with the Kernel development +rules in the Kernel documentation, including its code of conduct. + +Media Maintainers are often reachable via the #linux-media IRC channel at OFTC. + +.. [2] Everything that would break backward compatibility with existing + non-kernel code are API/ABI changes. This includes ioctl and sysfs + interfaces, v4l2 controls, and their behaviors. + +Patchwork Access +---------------- + +All Media Maintainers who have been granted Patchwork access shall ensure that +`Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_ +will reflect the current status, e.g. patches shall be delegated to the Media +Maintainer who is handling them and the patch status shall be updated according +to these rules: + +- ``Under Review``: Used if the patch requires a second opinion + or when it is part of a Pull Request; +- ``Superseded``: There is a newer version of the patch posted to the + mailing list. +- ``Duplicated``: There was another patch doing the same thing from someone + else that was accepted. +- ``Not Applicable``: Use for patch series that are not merged at media.git + tree (e.g. drm, dmabuf, upstream merge, etc.) but were cross-posted to the + linux-media mailing list. +- ``Accepted``: Once a patch is merged in the multi-committer tree. Only Media + Maintainers with commit rights are allowed to set this state. + +If Media Maintainers decide not to accept a patch, they should reply to the +patch authors by e‑mail, explaining why it is not accepted, and +update `Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_ +accordingly with one of the following statuses: + +- ``Changes Requested``: if a new revision was requested; +- ``Rejected``: if the proposed change is not acceptable at all. + +.. Note:: + + Patchwork supports a couple of clients to help semi-automate + status updates via its REST interface: + + https://patchwork.readthedocs.io/en/latest/usage/clients/ + +For patches that fall within their area of responsibility a Media Maintainer +also decides when those patches are ready for merging, and create Pull Requests +for the Media Subsystem Maintainers to merge. + +The most important aspect of becoming a Media Maintainer with Patchwork access +is that you have demonstrated an ability to give good code reviews. We value +your ability to deliver thorough, constructive code reviews. + +As such, potential maintainers must earn enough credibility and trust from the +Linux Media Community. To do that, developers shall be familiar with the open +source model and have been active in the Linux Kernel community for some time, +and, in particular, in the media subsystem. + +In addition to actually making the code changes, you are basically +demonstrating your: + +- commitment to the project; +- ability to collaborate with the team and communicate well; +- understanding of how upstream and the Linux Media Community work + (policies, processes for testing, code review, ...) +- reasonable knowledge about: + + - the Kernel development process: + Documentation/process/index.rst + + - the Media development profile: + Documentation/driver-api/media/maintainer-entry-profile.rst + +- understanding of the projects' code base and coding style; +- ability to provide feedback to the patch authors; +- ability to judge when a patch might be ready for review and to submit; +- ability to write good code (last but certainly not least). + +Media Driver Maintainers that desire to get Patchwork access are encouraged +to participate at the yearly Linux Media Summit, typically co-located with +a Linux-related conference. These summits are announced on the linux-media +mailing list. + +If you are doing such tasks and have become a valued developer, an +existing Media Maintainer can nominate you to the Media Subsystem Maintainers. + +The ultimate responsibility for accepting a nominated maintainer is up to +the subsystem's maintainers. The nominated maintainer must have earned a trust +relationship with all Media Subsystem Maintainers, as, by being granted +Patchwork access, you will take over part of their maintenance tasks. + +Media Committers +---------------- + +Experienced and trusted Media Maintainers may be granted commit rights +which allow them to directly push patches to the media development tree instead +of posting a Pull Request for the Media Subsystem Maintainers. This helps +offloading some of the work of the Media Subsystem Maintainers. + +More details about Media Committers' roles and responsibilities can be +found here: :ref:`Media Committers`. + +Media development sites +----------------------- + +The `LinuxTV <https://linuxtv.org/>`_ web site hosts news about the subsystem, +together with: + +- `Wiki pages <https://www.linuxtv.org/wiki/index.php/Main_Page>`_; +- `Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_; +- `Linux Media documentation <https://linuxtv.org/docs.php>`_; +- and more. + +The main development trees used by the media subsystem are at: + +- Stable tree: + - https://git.linuxtv.org/media.git/ + +- Media committers tree: + - https://gitlab.freedesktop.org/linux-media/media-committers.git + + Please note that it can be rebased, although only as a last resort. + +- Media development trees, including apps and CI: + + - https://git.linuxtv.org/ + - https://gitlab.freedesktop.org/linux-media/ + + +.. _Media development workflow: + +Media development workflow +++++++++++++++++++++++++++ + +All changes for the media subsystem shall be sent first as e-mails to the +media mailing list, following the process documented at +Documentation/process/index.rst. + +It means that patches shall be submitted as plain text only via e-mail to +linux-media@vger.kernel.org (aka: LMML). While subscription is not mandatory, +you can find details about how to subscribe to it and to see its archives at: + + https://subspace.kernel.org/vger.kernel.org.html + +Emails with HTML will be automatically rejected by the mail server. + +It could be wise to also copy the relevant Media Maintainer(s). You should use +``scripts/get_maintainers.pl`` to identify whom else needs to be copied. +Please always copy driver's authors and maintainers. + +To minimize the chance of merge conflicts for your patch series, and make it +easier to backport patches to stable Kernels, we recommend that you use the +following baseline for your patch series: -Due to the size and wide scope of the media subsystem, media's -maintainership model is to have sub-maintainers that have a broad -knowledge of a specific aspect of the subsystem. It is the sub-maintainers' -task to review the patches, providing feedback to users if the patches are -following the subsystem rules and are properly using the media kernel and -userspace APIs. +1. Features for the next mainline release: -Patches for the media subsystem must be sent to the media mailing list -at linux-media@vger.kernel.org as plain text only e-mail. Emails with -HTML will be automatically rejected by the mail server. It could be wise -to also copy the sub-maintainer(s). + - baseline shall be the ``media-committers.git next`` branch; + +2. Bug fixes for the next mainline release: + + - baseline shall be the ``media-committers.git next`` branch. If the + changes depend on a fix from the ``media-committers.git fixes`` + branch, then you can use that as baseline. + +3. Bug fixes for the current mainline release (-rcX): + + - baseline shall be the latest mainline -rcX release or the + ``media-committers.git fixes`` branch if changes depend on a mainline + fix that is not yet merged; + +.. Note:: + + See https://www.kernel.org/category/releases.html for an overview + about Kernel release types. + +Patches with fixes shall have: + +- a ``Fixes:`` tag pointing to the first commit that introduced the bug; +- when applicable, a ``Cc: stable@vger.kernel.org``. + +Patches that were fixing bugs publicly reported by someone at the +linux-media@vger.kernel.org mailing list shall have: + +- a ``Reported-by:`` tag immediately followed by a ``Closes:`` tag. + +Patches that change API shall update documentation accordingly at the +same patch series. + +See Documentation/process/index.rst for more details about e-mail submission. + +Once a patch is submitted, it may follow either one of the following +workflows: + +a. Media Maintainers' workflow: Media Maintainers post the Pull Requests, + which are handled by the Media Subsystem Maintainers:: + + +-------+ +------------+ +------+ +-------+ +---------------------+ + |e-mail |-->|picked up by|-->|code |-->|pull |-->|Subsystem Maintainers| + |to LMML| |Patchwork | |review| |request| |merge in | + | | | | | | | | |media-committers.git | + +-------+ +------------+ +------+ +-------+ +---------------------+ + + For this workflow, Pull Requests are generated by Media Maintainers with + Patchwork access. If you do not have Patchwork access, then please don't + submit Pull Requests, as they will not be processed. + +b. Media Committers' workflow: patches are handled by Media Maintainers with + commit rights:: + + +-------+ +------------+ +------+ +--------------------------+ + |e-mail |-->|picked up by|-->|code |-->|Media Committers merge in | + |to LMML| |Patchwork | |review| |media-committers.git | + +-------+ +------------+ +------+ +--------------------------+ + +When patches are picked up by +`Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_ +and when merged at media-committers, Media CI bots will check for errors and +may provide e-mail feedback about patch problems. When this happens, the patch +submitter must fix them or explain why the errors are false positives. + +Patches will only be moved to the next stage in these two workflows if they +pass on Media CI or if there are false-positives in the Media CI reports. + +For both workflows, all patches shall be properly reviewed at +linux-media@vger.kernel.org (LMML) before being merged in +``media-committers.git``. Media patches will be reviewed in a timely manner +by the maintainers and reviewers as listed in the MAINTAINERS file. + +Media Maintainers shall request reviews from other Media Maintainers and +developers where applicable, i.e. because those developers have more +knowledge about some areas that are changed by a patch. + +There shall be no open issues or unresolved or conflicting feedback +from anyone. Clear them up first. Defer to the Media Subsystem +Maintainers if needed. + +Failures during e-mail submission ++++++++++++++++++++++++++++++++++ Media's workflow is heavily based on Patchwork, meaning that, once a patch is submitted, the e-mail will first be accepted by the mailing list @@ -47,51 +330,107 @@ server, and, after a while, it should appear at: - https://patchwork.linuxtv.org/project/linux-media/list/ -If it doesn't automatically appear there after a few minutes, then +If it doesn't automatically appear there after some time [3]_, then probably something went wrong on your submission. Please check if the -email is in plain text\ [2]_ only and if your emailer is not mangling +email is in plain text\ [4]_ only and if your emailer is not mangling whitespaces before complaining or submitting them again. -You can check if the mailing list server accepted your patch, by looking at: +To troubleshoot problems, you should first check if the mailing list +server has accepted your patch, by looking at: - https://lore.kernel.org/linux-media/ -.. [2] If your email contains HTML, the mailing list server will simply +If the patch is there and not at +`Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_, +it is likely that your e-mailer mangled the patch. Patchwork internally +has logic that checks if the received e-mail contains a valid patch. +Any whitespace and new line breakages mangling the patch won't be recognized by +`Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_, +and such a patch will be rejected. + +.. [3] It usually takes a few minutes for the patch to arrive, but + the e-mail server may be busy, so it may take a longer time + for a patch to be picked by + `Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_. + +.. [4] If your email contains HTML, the mailing list server will simply drop it, without any further notice. +.. _media-developers-gpg: + +Authentication for pull and merge requests +++++++++++++++++++++++++++++++++++++++++++ + +The authenticity of developers submitting Pull Requests and merge requests +shall be validated by using the Linux Kernel Web of Trust, with PGP signing +at some moment. See: :ref:`kernel_org_trust_repository`. -Media maintainers -+++++++++++++++++ +With the Pull Request workflow, Pull Requests shall use PGP-signed tags. -At the media subsystem, we have a group of senior developers that -are responsible for doing the code reviews at the drivers (also known as -sub-maintainers), and another senior developer responsible for the -subsystem as a whole. For core changes, whenever possible, multiple -media maintainers do the review. +With the committers' workflow, this is ensured at the time merge request +rights will be granted to the gitlab instance used by the media-committers.git +tree, after receiving the e-mail documented in +:ref:`media-committer-agreement`. + +For more details about PGP signing, please read +Documentation/process/maintainer-pgp-guide.rst. + +Maintaining media maintainer status +----------------------------------- + +See :ref:`Maintain Media Status`. + +List of Media Maintainers +------------------------- -The media maintainers that work on specific areas of the subsystem are: +The Media Maintainers listed here all have patchwork access and can +make Pull Requests or have commit rights. -- Remote Controllers (infrared): - Sean Young <sean@mess.org> +The Media Subsystem Maintainers are: + - Mauro Carvalho Chehab <mchehab@kernel.org> + - Hans Verkuil <hverkuil@kernel.org> -- HDMI CEC: - Hans Verkuil <hverkuil@kernel.org> +The Media Core Maintainers are: + - Sakari Ailus <sakari.ailus@linux.intel.com> -- Media controller drivers: - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + - Media controller drivers + - Core media controller framework + - ISP + - sensor drivers + - v4l2-async and v4l2-fwnode core frameworks + - v4l2-flash-led-class core framework -- ISP, v4l2-async, v4l2-fwnode, v4l2-flash-led-class and Sensor drivers: - Sakari Ailus <sakari.ailus@linux.intel.com> + - Mauro Carvalho Chehab <mchehab@kernel.org> -- V4L2 drivers and core V4L2 frameworks: - Hans Verkuil <hverkuil@kernel.org> + - DVB -The subsystem maintainer is: - Mauro Carvalho Chehab <mchehab@kernel.org> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> -Media maintainers may delegate a patch to other media maintainers as needed. -On such case, checkpatch's ``delegate`` field indicates who's currently -responsible for reviewing a patch. + - Media controller drivers + - Core media controller framework + - ISP + + - Hans Verkuil <hverkuil@kernel.org> + + - V4L2 drivers + - V4L2 and videobuf2 core frameworks + - HDMI CEC drivers + - HDMI CEC core framework + + - Sean Young <sean@mess.org> + + - Remote Controller (infrared) drivers + - Remote Controller (infrared) core framework + +The Media Driver Maintainers responsible for specific areas are: + - Nicolas Dufresne <nicolas.dufresne@collabora.com> + + - Codec drivers + - M2M driver not otherwise delegated + + - Bryan O'Donoghue <bryan.odonoghue@linaro.org> + + - Qualcomm drivers Submit Checklist Addendum ------------------------- @@ -106,18 +445,15 @@ that should be used in order to check if the drivers are properly implementing the media APIs: ==================== ======================================================= -Type Tool +Type Utility ==================== ======================================================= -V4L2 drivers\ [3]_ ``v4l2-compliance`` +V4L2 drivers\ [5]_ ``v4l2-compliance`` V4L2 virtual drivers ``contrib/test/test-media`` CEC drivers ``cec-compliance`` ==================== ======================================================= -.. [3] The ``v4l2-compliance`` also covers the media controller usage inside - V4L2 drivers. - -Other compliance tools are under development to check other parts of the -subsystem. +.. [5] The ``v4l2-compliance`` utility also covers the media controller usage + inside V4L2 drivers. Those tests need to pass before the patches go upstream. @@ -134,6 +470,8 @@ Where the check script is:: Be sure to not introduce new warnings on your patches without a very good reason. +Please see `Media development workflow`_ for e-mail submission rules. + Style Cleanup Patches +++++++++++++++++++++ @@ -173,34 +511,35 @@ least, simply wrapping the lines. In particular, we accept lines with more than 80 columns: - on strings, as they shouldn't be broken due to line length limits; - - when a function or variable name need to have a big identifier name, - which keeps hard to honor the 80 columns limit; + - when a function or variable name needs to have a long identifier name, + which makes hard to honor the 80 columns limit; - on arithmetic expressions, when breaking lines makes them harder to read; - - when they avoid a line to end with an open parenthesis or an open + - when they avoid a line ending with an open parenthesis or an open bracket. Key Cycle Dates --------------- -New submissions can be sent at any time, but if they intend to hit the +New submissions can be sent at any time, but if they are intended to hit the next merge window they should be sent before -rc5, and ideally stabilized in the linux-media branch by -rc6. Review Cadence -------------- -Provided that your patch is at https://patchwork.linuxtv.org, it should -be sooner or later handled, so you don't need to re-submit a patch. +Provided that your patch has landed in +`Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_, it +should be sooner or later handled, so you don't need to re-submit a patch. -Except for bug fixes, we don't usually add new patches to the development -tree between -rc6 and the next -rc1. +Except for important bug fixes, we don't usually add new patches to the +development tree between -rc6 and the next -rc1. Please notice that the media subsystem is a high traffic one, so it could take a while for us to be able to review your patches. Feel free to ping if you don't get a feedback in a couple of weeks or to ask -other developers to publicly add Reviewed-by and, more importantly, +other developers to publicly add ``Reviewed-by:`` and, more importantly, ``Tested-by:`` tags. Please note that we expect a detailed description for ``Tested-by:``, -identifying what boards were used at the test and what it was tested. +identifying what boards were used during the test and what it was tested. diff --git a/Documentation/driver-api/media/media-committers.rst b/Documentation/driver-api/media/media-committers.rst new file mode 100644 index 000000000000..a905856f6a61 --- /dev/null +++ b/Documentation/driver-api/media/media-committers.rst @@ -0,0 +1,203 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _Media Committers: + +Media Committers +================ + +Who is a Media Committer? +------------------------- + +A Media Committer is a Media Maintainer with patchwork access who has been +granted commit access to push patches from other developers and their own +patches to the +`media-committers <https://gitlab.freedesktop.org/linux-media/media-committers>`_ +tree. + +These commit rights are granted with expectation of responsibility: +committers are people who care about the Linux Kernel as a whole and +about the Linux media subsystem and want to advance its development. It +is also based on a trust relationship among other committers, maintainers +and the Linux Media community. + +As Media Committer you have the following additional responsibilities: + +1. Patches you authored must have a ``Signed-off-by``, ``Reviewed-by`` + or ``Acked-by`` from another Media Maintainer; +2. If a patch introduces a regression, then that must be corrected as soon + as possible. Typically the patch is either reverted, or an additional + patch is committed to fix the regression; +3. If patches are fixing bugs against already released Kernels, including + the reverts mentioned above, the Media Committer shall add the needed + tags. Please see :ref:`Media development workflow` for more details. +4. All Media Committers are responsible for maintaining + `Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_, + updating the state of the patches they review or merge. + + +Becoming a Media Committer +-------------------------- + +Existing Media Committers can nominate a Media Maintainer to be granted +commit rights. The Media Maintainer must have patchwork access, +have been reviewing patches from third parties for some time, and has +demonstrated a good understanding of the maintainer's duties and processes. + +The ultimate responsibility for accepting a nominated committer is up to +the Media Subsystem Maintainers. The nominated committer must have earned a +trust relationship with all Media Subsystem Maintainers, as, by granting you +commit rights, part of their responsibilities are handed over to you. + +Due to that, to become a Media Committer, a consensus between all Media +Subsystem Maintainers is required. + +.. Note:: + + In order to preserve/protect the developers that could have their commit + rights granted, denied or removed as well as the subsystem maintainers who + have the task to accept or deny commit rights, all communication related to + changing commit rights should happen in private as much as possible. + +.. _media-committer-agreement: + +Media Committer's agreement +--------------------------- + +Once a nominated committer is accepted by all Media Subsystem Maintainers, +they will ask if the developer is interested in the nomination and discuss +what area(s) of the media subsystem the committer will be responsible for. +Those areas will typically be the same as the areas that the nominated +committer is already maintaining. + +When the developer accepts being a committer, the new committer shall +explicitly accept the Kernel development policies described under its +Documentation/, and in particular to the rules in this document, by writing +an e-mail to media-committers@linuxtv.org, with a declaration of intent +following the model below:: + + I, John Doe, would like to change my status to: Committer + + As Media Maintainer I accept commit rights for the following areas of + the media subsystem: + + ... + + For the purpose of committing patches to the media-committers tree, + I'll be using my user https://gitlab.freedesktop.org/users/<username>. + +Followed by a formal declaration of agreement with the Kernel development +rules:: + + I agree to follow the Kernel development rules described at: + + https://www.kernel.org/doc/html/latest/driver-api/media/media-committers.rst + + and to the Linux Kernel development process rules. + + I agree to abide by the Code of Conduct as documented in: + https://www.kernel.org/doc/html/latest/process/code-of-conduct.rst + + I am aware that I can, at any point of time, retire. In that case, I will + send an e-mail to notify the Media Subsystem Maintainers for them to revoke + my commit rights. + + I am aware that the Kernel development rules change over time. + By doing a new push to media-committers tree, I understand that I agree + to follow the rules in effect at the time of the commit. + +That e-mail shall be signed via the Kernel Web of trust with a PGP key cross +signed by other Kernel and media developers. As described at +:ref:`media-developers-gpg`, the PGP signature, together with the gitlab user +security are fundamental components that ensure the authenticity of the merge +requests that will happen at the media-committers.git tree. + +In case the kernel development process changes, by merging new commits to the +`media-committers tree <https://gitlab.freedesktop.org/linux-media/media-committers>`_, +the Media Committer implicitly declares their agreement with the latest +version of the documented process including the contents of this file. + +If a Media Committer decides to retire, it is the committer's duty to +notify the Media Subsystem Maintainers about that decision. + +.. note:: + + 1. Changes to the kernel media development process shall be announced in + the media-committers mailing list with a reasonable review period. All + committers are automatically subscribed to that mailing list; + 2. Due to the distributed nature of the Kernel development, it is + possible that kernel development process changes may end being + reviewed/merged at the Linux Docs and/or at the Linux Kernel mailing + lists, especially for the contents under Documentation/process and for + trivial typo fixes. + +Media Core Committers +--------------------- + +A Media Core Committer is a Media Core Maintainer with commit rights. + +As described in Documentation/driver-api/media/maintainer-entry-profile.rst, +a Media Core Maintainer maintains media core frameworks as well, besides +just drivers, and so is allowed to change core files and the media subsystem's +Kernel API. The extent of the core committer's grants will be detailed by the +Media Subsystem Maintainers when they nominate a Media Core Committer. + +Existing Media Committers may become Media Core Committers and vice versa. +Such decisions will be taken in consensus among the Media Subsystem +Maintainers. + +Media committers rules +---------------------- + +Media committers shall do their best efforts to avoid merging patches that +would break any existing drivers. If it breaks, fixup or revert patches +shall be merged as soon as possible, aiming to be merged at the same Kernel +cycle the bug is reported. + +Media committers shall behave accordingly to the rights granted by +the Media Subsystem Maintainers, especially with regards of the scope of changes +they may apply directly at the media-committers tree. That scope can +change over time on a mutual agreement between Media Committers and +Media Subsystem Maintainers. + +The Media Committer workflow is described at :ref:`Media development workflow`. + +.. _Maintain Media Status: + +Maintaining Media Maintainer or Committer status +------------------------------------------------ + +A community of maintainers working together to move the Linux Kernel +forward is essential to creating successful projects that are rewarding +to work on. If there are problems or disagreements within the community, +they can usually be solved through healthy discussion and debate. + +In the unhappy event that a Media Maintainer or Committer continues to +disregard good citizenship (or actively disrupts the project), we may need +to revoke that person's status. In such cases, if someone suggests the +revocation with a good reason, then after discussing this among the Media +Maintainers, the final decision is taken by the Media Subsystem Maintainers. + +As the decision to become a Media Maintainer or Committer comes from a +consensus between Media Subsystem Maintainers, a single Media Subsystem +Maintainer not trusting the Media Maintainer or Committer anymore is enough +to revoke their maintenance, Patchwork grants and/or commit rights. + +Having commit rights revoked doesn't prevent Media Maintainers to keep +contributing to the subsystem either via the pull request or via email workflow +as documented at the :ref:`Media development workflow`. + +If a maintainer is inactive for more than a couple of Kernel cycles, +maintainers will try to reach you via e-mail. If not possible, they may +revoke their maintainer/patchwork and committer rights and update MAINTAINERS +file entries accordingly. If you wish to resume contributing as maintainer +later on, then contact the Media Subsystem Maintainers to ask if your +maintenance, Patchwork grants and commit rights can be restored. + +References +---------- + +Much of this was inspired by/copied from the committer policies of: + +- `Chromium <https://chromium.googlesource.com/chromium/src/+/main/docs/contributing.md>`_; +- `WebKit <https://webkit.org/commit-and-review-policy/>`_; +- `Mozilla <https://www.mozilla.org/hacking/committer/>`_. diff --git a/Documentation/driver-api/pci/p2pdma.rst b/Documentation/driver-api/pci/p2pdma.rst index 280673b50350..d3f406cca694 100644 --- a/Documentation/driver-api/pci/p2pdma.rst +++ b/Documentation/driver-api/pci/p2pdma.rst @@ -38,7 +38,7 @@ for all usage refcounts to reach zero. At the lowest level the P2P subsystem offers a naked struct p2p_provider that delegates lifecycle management to the providing driver. It is expected that drivers using this option will wrap their MMIO memory in DMABUF and use DMABUF -to provide an invalidation shutdown. These MMIO addresess have no struct page, and +to provide an invalidation shutdown. These MMIO addresses have no struct page, and if used with mmap() must create special PTEs. As such there are very few kernel uAPIs that can accept pointers to them; in particular they cannot be used with read()/write(), including O_DIRECT. diff --git a/Documentation/driver-api/reset.rst b/Documentation/driver-api/reset.rst index f773100daaa4..7a6571849664 100644 --- a/Documentation/driver-api/reset.rst +++ b/Documentation/driver-api/reset.rst @@ -198,7 +198,6 @@ query the reset line status using reset_control_status(). reset_control_rearm reset_control_put of_reset_control_get_count - of_reset_control_array_get devm_reset_control_array_get reset_control_get_count diff --git a/Documentation/driver-api/vme.rst b/Documentation/driver-api/vme.rst index c0b475369de0..7111999abc14 100644 --- a/Documentation/driver-api/vme.rst +++ b/Documentation/driver-api/vme.rst @@ -107,7 +107,7 @@ The function :c:func:`vme_master_read` can be used to read from and In addition to simple reads and writes, :c:func:`vme_master_rmw` is provided to do a read-modify-write transaction. Parts of a VME window can also be mapped -into user space memory using :c:func:`vme_master_mmap`. +into user space memory using :c:func:`vme_master_mmap_prepare`. Slave windows diff --git a/Documentation/features/perf/perf-regs/arch-support.txt b/Documentation/features/perf/perf-regs/arch-support.txt index 09431518b0e8..4c9a5a012075 100644 --- a/Documentation/features/perf/perf-regs/arch-support.txt +++ b/Documentation/features/perf/perf-regs/arch-support.txt @@ -18,7 +18,7 @@ | mips: | ok | | nios2: | TODO | | openrisc: | TODO | - | parisc: | TODO | + | parisc: | ok | | powerpc: | ok | | riscv: | ok | | s390: | ok | diff --git a/Documentation/features/perf/perf-stackdump/arch-support.txt b/Documentation/features/perf/perf-stackdump/arch-support.txt index f9db4dd8ef79..dd362b5cb638 100644 --- a/Documentation/features/perf/perf-stackdump/arch-support.txt +++ b/Documentation/features/perf/perf-stackdump/arch-support.txt @@ -18,7 +18,7 @@ | mips: | ok | | nios2: | TODO | | openrisc: | TODO | - | parisc: | TODO | + | parisc: | ok | | powerpc: | ok | | riscv: | ok | | s390: | ok | diff --git a/Documentation/features/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt index 13feb679649e..9336bdfc125c 100644 --- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt +++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt @@ -6,7 +6,7 @@ ----------------------- | arch |status| ----------------------- - | alpha: | TODO | + | alpha: | ok | | arc: | TODO | | arm: | ok | | arm64: | ok | diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index f4873197587d..fc7254d01a2b 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -29,6 +29,7 @@ algorithms work. fiemap files locks + mmap_prepare multigrain-ts mount_api quota @@ -98,6 +99,7 @@ Documentation for filesystem implementations. isofs nilfs2 nfs/index + ntfs ntfs3 ocfs2 ocfs2-online-filecheck diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 8025df6e6499..8421ea21bd35 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -398,6 +398,7 @@ prototypes:: bool (*lm_breaker_owns_lease)(struct file_lock *); bool (*lm_lock_expirable)(struct file_lock *); void (*lm_expire_lock)(void); + bool (*lm_breaker_timedout)(struct file_lease *); locking rules: @@ -412,6 +413,7 @@ lm_breaker_owns_lease: yes no no lm_lock_expirable yes no no lm_expire_lock no no yes lm_open_conflict yes no no +lm_breaker_timedout yes no no ====================== ============= ================= ========= buffer_head diff --git a/Documentation/filesystems/mmap_prepare.rst b/Documentation/filesystems/mmap_prepare.rst new file mode 100644 index 000000000000..82c99c95ad85 --- /dev/null +++ b/Documentation/filesystems/mmap_prepare.rst @@ -0,0 +1,168 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +mmap_prepare callback HOWTO +=========================== + +Introduction +============ + +The ``struct file->f_op->mmap()`` callback has been deprecated as it is both a +stability and security risk, and doesn't always permit the merging of adjacent +mappings resulting in unnecessary memory fragmentation. + +It has been replaced with the ``file->f_op->mmap_prepare()`` callback which +solves these problems. + +This hook is called right at the beginning of setting up the mapping, and +importantly it is invoked *before* any merging of adjacent mappings has taken +place. + +If an error arises upon mapping, it might arise after this callback has been +invoked, therefore it should be treated as effectively stateless. + +That is - no resources should be allocated nor state updated to reflect that a +mapping has been established, as the mapping may either be merged, or fail to be +mapped after the callback is complete. + +Mapped callback +--------------- + +If resources need to be allocated per-mapping, or state such as a reference +count needs to be manipulated, this should be done using the ``vm_ops->mapped`` +hook, which itself should be set by the >mmap_prepare hook. + +This callback is only invoked if a new mapping has been established and was not +merged with any other, and is invoked at a point where no error may occur before +the mapping is established. + +You may return an error to the callback itself, which will cause the mapping to +become unmapped and an error returned to the mmap() caller. This is useful if +resources need to be allocated, and that allocation might fail. + +How To Use +========== + +In your driver's struct file_operations struct, specify an ``mmap_prepare`` +callback rather than an ``mmap`` one, e.g. for ext4: + +.. code-block:: C + + const struct file_operations ext4_file_operations = { + ... + .mmap_prepare = ext4_file_mmap_prepare, + }; + +This has a signature of ``int (*mmap_prepare)(struct vm_area_desc *)``. + +Examining the struct vm_area_desc type: + +.. code-block:: C + + struct vm_area_desc { + /* Immutable state. */ + const struct mm_struct *const mm; + struct file *const file; /* May vary from vm_file in stacked callers. */ + unsigned long start; + unsigned long end; + + /* Mutable fields. Populated with initial state. */ + pgoff_t pgoff; + struct file *vm_file; + vma_flags_t vma_flags; + pgprot_t page_prot; + + /* Write-only fields. */ + const struct vm_operations_struct *vm_ops; + void *private_data; + + /* Take further action? */ + struct mmap_action action; + }; + +This is straightforward - you have all the fields you need to set up the +mapping, and you can update the mutable and writable fields, for instance: + +.. code-block:: C + + static int ext4_file_mmap_prepare(struct vm_area_desc *desc) + { + int ret; + struct file *file = desc->file; + struct inode *inode = file->f_mapping->host; + + ... + + file_accessed(file); + if (IS_DAX(file_inode(file))) { + desc->vm_ops = &ext4_dax_vm_ops; + vma_desc_set_flags(desc, VMA_HUGEPAGE_BIT); + } else { + desc->vm_ops = &ext4_file_vm_ops; + } + return 0; + } + +Importantly, you no longer have to dance around with reference counts or locks +when updating these fields - **you can simply go ahead and change them**. + +Everything is taken care of by the mapping code. + +VMA Flags +--------- + +Along with ``mmap_prepare``, VMA flags have undergone an overhaul. Where before +you would invoke one of vm_flags_init(), vm_flags_reset(), vm_flags_set(), +vm_flags_clear(), and vm_flags_mod() to modify flags (and to have the +locking done correctly for you, this is no longer necessary. + +Also, the legacy approach of specifying VMA flags via ``VM_READ``, ``VM_WRITE``, +etc. - i.e. using a ``-VM_xxx``- macro has changed too. + +When implementing mmap_prepare(), reference flags by their bit number, defined +as a ``VMA_xxx_BIT`` macro, e.g. ``VMA_READ_BIT``, ``VMA_WRITE_BIT`` etc., +and use one of (where ``desc`` is a pointer to struct vm_area_desc): + +* ``vma_desc_test_any(desc, ...)`` - Specify a comma-separated list of flags + you wish to test for (whether _any_ are set), e.g. - ``vma_desc_test_any( + desc, VMA_WRITE_BIT, VMA_MAYWRITE_BIT)`` - returns ``true`` if either are set, + otherwise ``false``. +* ``vma_desc_set_flags(desc, ...)`` - Update the VMA descriptor flags to set + additional flags specified by a comma-separated list, + e.g. - ``vma_desc_set_flags(desc, VMA_PFNMAP_BIT, VMA_IO_BIT)``. +* ``vma_desc_clear_flags(desc, ...)`` - Update the VMA descriptor flags to clear + flags specified by a comma-separated list, e.g. - ``vma_desc_clear_flags( + desc, VMA_WRITE_BIT, VMA_MAYWRITE_BIT)``. + +Actions +======= + +You can now very easily have actions be performed upon a mapping once set up by +utilising simple helper functions invoked upon the struct vm_area_desc +pointer. These are: + +* mmap_action_remap() - Remaps a range consisting only of PFNs for a specific + range starting a virtual address and PFN number of a set size. + +* mmap_action_remap_full() - Same as mmap_action_remap(), only remaps the + entire mapping from ``start_pfn`` onward. + +* mmap_action_ioremap() - Same as mmap_action_remap(), only performs an I/O + remap. + +* mmap_action_ioremap_full() - Same as mmap_action_ioremap(), only remaps + the entire mapping from ``start_pfn`` onward. + +* mmap_action_simple_ioremap() - Sets up an I/O remap from a specified + physical address and over a specified length. + +* mmap_action_map_kernel_pages() - Maps a specified array of `struct page` + pointers in the VMA from a specific offset. + +* mmap_action_map_kernel_pages_full() - Maps a specified array of `struct + page` pointers over the entire VMA. The caller must ensure there are + sufficient entries in the page array to cover the entire range of the + described VMA. + +**NOTE:** The ``action`` field should never normally be manipulated directly, +rather you ought to use one of these helpers. diff --git a/Documentation/filesystems/mount_api.rst b/Documentation/filesystems/mount_api.rst index a064234fed5b..e8b94357b4df 100644 --- a/Documentation/filesystems/mount_api.rst +++ b/Documentation/filesystems/mount_api.rst @@ -647,9 +647,7 @@ The members are as follows: fs_param_is_u64 64-bit unsigned int result->uint_64 fs_param_is_enum Enum value name result->uint_32 fs_param_is_string Arbitrary string param->string - fs_param_is_blob Binary blob param->blob fs_param_is_blockdev Blockdev path * Needs lookup - fs_param_is_path Path * Needs lookup fs_param_is_fd File descriptor result->int_32 fs_param_is_uid User ID (u32) result->uid fs_param_is_gid Group ID (u32) result->gid @@ -681,9 +679,7 @@ The members are as follows: fsparam_u64() fs_param_is_u64 fsparam_enum() fs_param_is_enum fsparam_string() fs_param_is_string - fsparam_blob() fs_param_is_blob fsparam_bdev() fs_param_is_blockdev - fsparam_path() fs_param_is_path fsparam_fd() fs_param_is_fd fsparam_uid() fs_param_is_uid fsparam_gid() fs_param_is_gid diff --git a/Documentation/filesystems/nfs/exporting.rst b/Documentation/filesystems/nfs/exporting.rst index a01d9b9b5bc3..4aa59b0bf253 100644 --- a/Documentation/filesystems/nfs/exporting.rst +++ b/Documentation/filesystems/nfs/exporting.rst @@ -206,3 +206,88 @@ following flags are defined: all of an inode's dirty data on last close. Exports that behave this way should set EXPORT_OP_FLUSH_ON_CLOSE so that NFSD knows to skip waiting for writeback when closing such files. + +Signed Filehandles +------------------ + +To protect against filehandle guessing attacks, the Linux NFS server can be +configured to sign filehandles with a Message Authentication Code (MAC). + +Standard NFS filehandles are often predictable. If an attacker can guess +a valid filehandle for a file they do not have permission to access via +directory traversal, they may be able to bypass path-based permissions +(though they still remain subject to inode-level permissions). + +Signed filehandles prevent this by appending a MAC to the filehandle +before it is sent to the client. Upon receiving a filehandle back from a +client, the server re-calculates the MAC using its internal key and +verifies it against the one provided. If the signatures do not match, +the server treats the filehandle as invalid (returning NFS[34]ERR_STALE). + +Note that signing filehandles provides integrity and authenticity but +not confidentiality. The contents of the filehandle remain visible to +the client; they simply cannot be forged or modified. + +Configuration +~~~~~~~~~~~~~ + +To enable signed filehandles, the administrator must provide a signing +key to the kernel and enable the "sign_fh" export option. + +1. Providing a Key + The signing key is managed via the nfsd netlink interface. This key + is per-network-namespace and must be set before any exports using + "sign_fh" become active. + +2. Export Options + The feature is controlled on a per-export basis in /etc/exports: + + sign_fh + Enables signing for all filehandles generated under this export. + + no_sign_fh + (Default) Disables signing. + +Key Management and Rotation +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The security of this mechanism relies entirely on the secrecy of the +signing key. + +Initial Setup: + The key should be generated using a high-quality random source and + loaded early in the boot process or during the nfs-server startup + sequence. + +Changing Keys: + If a key is changed while clients have active mounts, existing + filehandles held by those clients will become invalid, resulting in + "Stale file handle" errors on the client side. + +Safe Rotation: + Currently, there is no mechanism for "graceful" key rotation + (maintaining multiple valid keys). Changing the key is an atomic + operation that immediately invalidates all previous signatures. + +Transitioning Exports +~~~~~~~~~~~~~~~~~~~~~ + +When adding or removing the "sign_fh" flag from an active export, the +following behaviors should be expected: + ++-------------------+---------------------------------------------------+ +| Change | Result for Existing Clients | ++===================+===================================================+ +| Adding sign_fh | Clients holding unsigned filehandles will find | +| | them rejected, as the server now expects a | +| | signature. | ++-------------------+---------------------------------------------------+ +| Removing sign_fh | Clients holding signed filehandles will find them | +| | rejected, as the server now expects the | +| | filehandle to end at its traditional boundary | +| | without a MAC. | ++-------------------+---------------------------------------------------+ + +Because filehandles are often cached persistently by clients, adding or +removing this option should generally be done during a scheduled maintenance +window involving a NFS client unmount/remount. diff --git a/Documentation/filesystems/ntfs.rst b/Documentation/filesystems/ntfs.rst new file mode 100644 index 000000000000..5c96b04a4d7a --- /dev/null +++ b/Documentation/filesystems/ntfs.rst @@ -0,0 +1,159 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +The Linux NTFS filesystem driver +================================= + + +.. Table of contents + + - Overview + - Utilities support + - Supported mount options + + +Overview +======== + +NTFS is a Linux kernel filesystem driver that provides full read and write +support for NTFS volumes. It is designed for high performance, modern +kernel infrastructure (iomap, folio), and stable long-term maintenance. + + +Utilities support +================= + +The NTFS utilities project, called ntfsprogs-plus, provides mkfs.ntfs, +fsck.ntfs, and other related tools (e.g., ntfsinfo, ntfsclone, etc.) for +creating, checking, and managing NTFS volumes. These utilities can be used +for filesystem testing with xfstests as well as for recovering corrupted +NTFS devices. + +The project is available at: + + https://github.com/ntfsprogs-plus/ntfsprogs-plus + + +Supported mount options +======================= + +The NTFS driver supports the following mount options: + +======================= ==================================================== +iocharset=name Character set to use for converting between + the encoding is used for user visible filename and + 16 bit Unicode characters. + +nls=name Deprecated option. Still supported but please use + iocharset=name in the future. + +uid= +gid= +umask= Provide default owner, group, and access mode mask. + These options work as documented in mount(8). By + default, the files/directories are owned by root + and he/she has read and write permissions, as well + as browse permission for directories. No one else + has any access permissions. I.e. the mode on all + files is by default rw------- and + for directories rwx------, a consequence of + the default fmask=0177 and dmask=0077. + Using a umask of zero will grant all permissions to + everyone, i.e. all files and directories will have + mode rwxrwxrwx. + +fmask= +dmask= Instead of specifying umask which applies both to + files and directories, fmask applies only to files + and dmask only to directories. + +showmeta=<BOOL> +show_sys_files=<BOOL> If show_sys_files is specified, show the system + files in directory listings. Otherwise the default + behaviour is to hide the system files. + Note that even when show_sys_files is specified, + "$MFT" will not be visible due to bugs/mis-features + in glibc. Further, note that irrespective of + show_sys_files, all files are accessible by name, + i.e. you can always do "ls -l \$UpCase" for example + to specifically show the system file containing + the Unicode upcase table. + +case_sensitive=<BOOL> If case_sensitive is specified, treat all filenames + as case sensitive and create file names in + the POSIX namespace (default behavior). Note, + the Linux NTFS driver will never create short + filenames and will remove them on rename/delete of + the corresponding long file name. Note that files + remain accessible via their short file name, if it + exists. + +nocase=<BOOL> If nocase is specified, treat filenames + case-insensitively. + +disable_sparse=<BOOL> If disable_sparse is specified, creation of sparse + regions, i.e. holes, inside files is disabled for + the volume (for the duration of this mount only). + By default, creation of sparse regions is enabled, + which is consistent with the behaviour of + traditional Unix filesystems. + +errors=opt Specify NTFS behavior on critical errors: panic, + remount the partition in read-only mode or + continue without doing anything (default behavior). + +mft_zone_multiplier= Set the MFT zone multiplier for the volume (this + setting is not persistent across mounts and can be + changed from mount to mount but cannot be changed + on remount). Values of 1 to 4 are allowed, 1 being + the default. The MFT zone multiplier determines + how much space is reserved for the MFT on the + volume. If all other space is used up, then the + MFT zone will be shrunk dynamically, so this has no + impact on the amount of free space. However, it + can have an impact on performance by affecting + fragmentation of the MFT. In general use the + default. If you have a lot of small files then use + a higher value. The values have the following + meaning: + + ===== ================================= + Value MFT zone size (% of volume size) + ===== ================================= + 1 12.5% + 2 25% + 3 37.5% + 4 50% + ===== ================================= + + Note this option is irrelevant for read-only mount. + +preallocated_size= Set preallocated size to optimize runlist merge + overhead with small chunck size.(64KB size by + default) + +acl=<BOOL> Enable POSIX ACL support. When specified, POSIX + ACLs stored in extended attributes are enforced. + Default is off. Requires kernel config + NTFS_FS_POSIX_ACL enabled. + +sys_immutable=<BOOL> Make NTFS system files (e.g. $MFT, $LogFile, + $Bitmap, $UpCase, etc.) immutable to user initiated + modifications for extra safety. Default is off. + +nohidden=<BOOL> Hide files and directories marked with the Windows + "hidden" attribute. By default hidden items are + shown. + +hide_dot_files=<BOOL> Hide names beginning with a dot ("."). By default + dot files are shown. When enabled, files and + directories created with a leading '.' will be + hidden from directory listings. + +windows_names=<BOOL> Refuse creation/rename of files with characters or + reserved device names disallowed on Windows (e.g. + CON, NUL, AUX, COM1, LPT1, etc.). Default is off. +discard=<BOOL> Issue block device discard for clusters freed on + file deletion/truncation to inform underlying + storage. +======================= ==================================================== diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index 9ced1135608e..6957c70f18db 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -1364,7 +1364,7 @@ it sets ``LOOKUP_AUTOMOUNT``, as does "``quotactl()``" and the handling of symlinks. Some system calls set or clear it implicitly, while others have API flags such as ``AT_SYMLINK_FOLLOW`` and ``UMOUNT_NOFOLLOW`` to control it. Its effect is similar to -``WALK_GET`` that we already met, but it is used in a different way. +``WALK_TRAILING`` that we already met, but it is used in a different way. ``LOOKUP_DIRECTORY`` insists that the final component is a directory. Various callers set this and it is also set when the final component diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 52ff1d19405b..fdf074429cd3 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -1361,3 +1361,27 @@ to match what strlen() would return if it was ran on the string. However, if the string is freely accessible for the duration of inode's lifetime, consider using inode_set_cached_link() instead. + +--- + +**mandatory** + +lookup_one_qstr_excl() is no longer exported - use start_creating() or +similar. + +--- + +** mandatory** + +lock_rename(), lock_rename_child(), unlock_rename() are no +longer available. Use start_renaming() or similar. + +--- + +**recommended** + +If you really need to iterate through dentries for given inode, use +for_each_alias(dentry, inode) instead of hlist_for_each_entry; better +yet, see if any of the exported primitives could be used instead of +the entire loop. You still need to hold ->i_lock of the inode over +either form of manual loop. diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index b0c0d1b45b99..db6167befb7b 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -464,26 +464,37 @@ Memory Area, or VMA) there is a series of lines such as the following:: KSM: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB + FilePmdMapped: 0 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB - KernelPageSize: 4 kB - MMUPageSize: 4 kB Locked: 0 kB THPeligible: 0 VmFlags: rd ex mr mw me dw The first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. Following lines show the size of the -mapping (size); the size of each page allocated when backing a VMA -(KernelPageSize), which is usually the same as the size in the page table -entries; the page size used by the MMU when backing a VMA (in most cases, -the same as KernelPageSize); the amount of the mapping that is currently -resident in RAM (RSS); the process's proportional share of this mapping -(PSS); and the number of clean and dirty shared and private pages in the -mapping. +mapping (size); the smallest possible page size allocated when backing a +VMA (KernelPageSize), which is the granularity in which VMA modifications +can be performed; the smallest possible page size that could be used by the +MMU (MMUPageSize) when backing a VMA; the amount of the mapping that is +currently resident in RAM (RSS); the process's proportional share of this +mapping (PSS); and the number of clean and dirty shared and private pages +in the mapping. + +"KernelPageSize" always corresponds to "MMUPageSize", except when a larger +kernel page size is emulated on a system with a smaller page size used by the +MMU, which is the case for some PPC64 setups with hugetlb. Furthermore, +"KernelPageSize" and "MMUPageSize" always correspond to the smallest +possible granularity (fallback) that can be encountered in a VMA throughout +its lifetime. These values are not affected by Transparent Huge Pages +being in effect, or any usage of larger MMU page sizes (either through +architectural huge-page mappings or other explicit/implicit coalescing of +virtual ranges performed by the MMU). "AnonHugePages", "ShmemPmdMapped" and +"FilePmdMapped" provide insight into the usage of PMD-level architectural +huge-page mappings. The "proportional set size" (PSS) of a process is the count of pages it has in memory, where each page is divided by the number of processes sharing it. @@ -528,10 +539,15 @@ pressure if the memory is clean. Please note that the printed value might be lower than the real value due to optimizations used in the current implementation. If this is not desirable please file a bug report. -"AnonHugePages" shows the amount of memory backed by transparent hugepage. +"AnonHugePages", "ShmemPmdMapped" and "FilePmdMapped" show the amount of +memory backed by Transparent Huge Pages that are currently mapped by +architectural huge-page mappings at the PMD level. "AnonHugePages" +corresponds to memory that does not belong to a file, "ShmemPmdMapped" to +shared memory (shmem/tmpfs) and "FilePmdMapped" to file-backed memory +(excluding shmem/tmpfs). -"ShmemPmdMapped" shows the amount of shared (shmem/tmpfs) memory backed by -huge pages. +There are no dedicated entries for Transparent Huge Pages (or similar concepts) +that are not mapped by architectural huge-page mappings at the PMD level. "Shared_Hugetlb" and "Private_Hugetlb" show the amounts of memory backed by hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical @@ -549,6 +565,10 @@ does not take into account swapped out page of underlying shmem objects. naturally aligned THP pages of any currently enabled size. 1 if true, 0 otherwise. +If both the kernel and the CPU support protection keys (pkeys), +"ProtectionKey" indicates the memory protection key associated with the +virtual memory area. + "VmFlags" field deserves a separate description. This member represents the kernel flags associated with the particular virtual memory area in two letter encoded manner. The codes are the following: @@ -727,7 +747,7 @@ files are there, and which are missing. in the kernel image cpuinfo Info about the CPU devices Available devices (block and character) - dma Used DMS channels + dma Used DMA channels filesystems Supported filesystems driver Various drivers grouped here, currently rtc (2.4) execdomains Execdomains, related to security (2.4) @@ -861,14 +881,13 @@ i386 and x86_64 platforms support the new IRQ vector displays. Of some interest is the introduction of the /proc/irq directory to 2.4. It could be used to set IRQ to CPU affinity. This means that you can "hook" an IRQ to only one CPU, or to exclude a CPU of handling IRQs. The contents of the -irq subdir is one subdir for each IRQ, and two files; default_smp_affinity and -prof_cpu_mask. +irq subdir is one subdir for each IRQ, and default_smp_affinity. For example:: > ls /proc/irq/ - 0 10 12 14 16 18 2 4 6 8 prof_cpu_mask - 1 11 13 15 17 19 3 5 7 9 default_smp_affinity + 0 10 12 14 16 18 2 4 6 8 default_smp_affinity + 1 11 13 15 17 19 3 5 7 9 > ls /proc/irq/0/ smp_affinity @@ -899,9 +918,6 @@ The node file on an SMP system shows the node to which the device using the IRQ reports itself as being attached. This hardware locality information does not include information about any possible driver locality preference. -prof_cpu_mask specifies which CPUs are to be profiled by the system wide -profiler. Default value is ffffffff (all CPUs if there are only 32 of them). - The way IRQs are routed is handled by the IO-APIC, and it's Round Robin between all the CPUs which are allowed to handle it. As usual the kernel has more info than you and does a better job than you, so the defaults are the @@ -1089,6 +1105,8 @@ Example output. You may not have all of these fields. CmaFree: 0 kB Unaccepted: 0 kB Balloon: 0 kB + GPUActive: 0 kB + GPUReclaim: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 @@ -1269,6 +1287,12 @@ Unaccepted Memory that has not been accepted by the guest Balloon Memory returned to Host by VM Balloon Drivers +GPUActive + System memory allocated to active GPU objects +GPUReclaim + System memory stored in GPU pools for reuse. This memory is not + counted in GPUActive. It is shrinker reclaimable memory kept in a reuse + pool because it has non-standard page table attributes, like WC or UC. HugePages_Total, HugePages_Free, HugePages_Rsvd, HugePages_Surp, Hugepagesize, Hugetlb See Documentation/admin-guide/mm/hugetlbpage.rst. DirectMap4k, DirectMap2M, DirectMap1G diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst index ba609f8d4de5..b003bed339fd 100644 --- a/Documentation/filesystems/resctrl.rst +++ b/Documentation/filesystems/resctrl.rst @@ -215,6 +215,14 @@ related to allocation: # cat /sys/fs/resctrl/info/L3/io_alloc_cbm 0=00ff;1=000f + An ID of "*" configures all domains with the provided CBM. + + Example on a system that does not require a minimum number of consecutive bits in the mask:: + + # echo "*=0" > /sys/fs/resctrl/info/L3/io_alloc_cbm + # cat /sys/fs/resctrl/info/L3/io_alloc_cbm + 0=0;1=0 + When CDP is enabled "io_alloc_cbm" associated with the CDP_DATA and CDP_CODE resources may reflect the same values. For example, values read from and written to /sys/fs/resctrl/info/L3DATA/io_alloc_cbm may be reflected by diff --git a/Documentation/filesystems/seq_file.rst b/Documentation/filesystems/seq_file.rst index 1e1713d00010..d753d8177bcb 100644 --- a/Documentation/filesystems/seq_file.rst +++ b/Documentation/filesystems/seq_file.rst @@ -27,7 +27,7 @@ position within the virtual file - that position is, likely as not, in the middle of a line of output. The kernel has traditionally had a number of implementations that got this wrong. -The 2.6 kernel contains a set of functions (implemented by Alexander Viro) +The kernel now contains a set of functions (implemented by Alexander Viro) which are designed to make it easy for virtual file creators to get it right. diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 781129f78b06..b4a9e5ae81f6 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -104,18 +104,6 @@ VBLANK Helper Reference .. kernel-doc:: drivers/gpu/drm/drm_vblank_helper.c :export: -Simple KMS Helper Reference -=========================== - -.. kernel-doc:: drivers/gpu/drm/drm_simple_kms_helper.c - :doc: overview - -.. kernel-doc:: include/drm/drm_simple_kms_helper.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/drm_simple_kms_helper.c - :export: - fbdev Helper Functions Reference ================================ diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index f22433470c76..32fb506db05b 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -526,8 +526,14 @@ DRM GPUVM Function References DRM Buddy Allocator =================== -DRM Buddy Function References ------------------------------ +Buddy Allocator Function References (GPU buddy) +----------------------------------------------- + +.. kernel-doc:: drivers/gpu/buddy.c + :export: + +DRM Buddy Specific Logging Function References +---------------------------------------------- .. kernel-doc:: drivers/gpu/drm/drm_buddy.c :export: diff --git a/Documentation/gpu/drm-ras.rst b/Documentation/gpu/drm-ras.rst new file mode 100644 index 000000000000..70b246a78fc8 --- /dev/null +++ b/Documentation/gpu/drm-ras.rst @@ -0,0 +1,103 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +============================ +DRM RAS over Generic Netlink +============================ + +The DRM RAS (Reliability, Availability, Serviceability) interface provides a +standardized way for GPU/accelerator drivers to expose error counters and +other reliability nodes to user space via Generic Netlink. This allows +diagnostic tools, monitoring daemons, or test infrastructure to query hardware +health in a uniform way across different DRM drivers. + +Key Goals: + +* Provide a standardized RAS solution for GPU and accelerator drivers, enabling + data center monitoring and reliability operations. +* Implement a single drm-ras Generic Netlink family to meet modern Netlink YAML + specifications and centralize all RAS-related communication in one namespace. +* Support a basic error counter interface, addressing the immediate, essential + monitoring needs. +* Offer a flexible, future-proof interface that can be extended to support + additional types of RAS data in the future. +* Allow multiple nodes per driver, enabling drivers to register separate + nodes for different IP blocks, sub-blocks, or other logical subdivisions + as applicable. + +Nodes +===== + +Nodes are logical abstractions representing an error type or error source within +the device. Currently, only error counter nodes is supported. + +Drivers are responsible for registering and unregistering nodes via the +`drm_ras_node_register()` and `drm_ras_node_unregister()` APIs. + +Node Management +------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_ras.c + :doc: DRM RAS Node Management +.. kernel-doc:: drivers/gpu/drm/drm_ras.c + :internal: + +Generic Netlink Usage +===================== + +The interface is implemented as a Generic Netlink family named ``drm-ras``. +User space tools can: + +* List registered nodes with the ``list-nodes`` command. +* List all error counters in an node with the ``get-error-counter`` command with ``node-id`` + as a parameter. +* Query specific error counter values with the ``get-error-counter`` command, using both + ``node-id`` and ``error-id`` as parameters. + +YAML-based Interface +-------------------- + +The interface is described in a YAML specification ``Documentation/netlink/specs/drm_ras.yaml`` + +This YAML is used to auto-generate user space bindings via +``tools/net/ynl/pyynl/ynl_gen_c.py``, and drives the structure of netlink +attributes and operations. + +Usage Notes +----------- + +* User space must first enumerate nodes to obtain their IDs. +* Node IDs or Node names can be used for all further queries, such as error counters. +* Error counters can be queried by either the Error ID or Error name. +* Query Parameters should be defined as part of the uAPI to ensure user interface stability. +* The interface supports future extension by adding new node types and + additional attributes. + +Example: List nodes using ynl + +.. code-block:: bash + + sudo ynl --family drm_ras --dump list-nodes + [{'device-name': '0000:03:00.0', + 'node-id': 0, + 'node-name': 'correctable-errors', + 'node-type': 'error-counter'}, + {'device-name': '0000:03:00.0', + 'node-id': 1, + 'node-name': 'uncorrectable-errors', + 'node-type': 'error-counter'}] + +Example: List all error counters using ynl + +.. code-block:: bash + + sudo ynl --family drm_ras --dump get-error-counter --json '{"node-id":0}' + [{'error-id': 1, 'error-name': 'error_name1', 'error-value': 0}, + {'error-id': 2, 'error-name': 'error_name2', 'error-value': 0}] + +Example: Query an error counter for a given node + +.. code-block:: bash + + sudo ynl --family drm_ras --do get-error-counter --json '{"node-id":0, "error-id":1}' + {'error-id': 1, 'error-name': 'error_name1', 'error-value': 0} + diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index d98428a592f1..579e87cb9ff7 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -438,14 +438,14 @@ following expectations. unknown consumer policy =============== ======================================== -The only exception to this is ``WEDGED=none``, which signifies that the device -was temporarily 'wedged' at some point but was recovered from driver context -using device specific methods like reset. No explicit recovery is expected from -the consumer in this case, but it can still take additional steps like gathering -telemetry information (devcoredump, syslog). This is useful because the first -hang is usually the most critical one which can result in consequential hangs or -complete wedging. - +No Recovery +----------- + +Here ``WEDGED=none`` signifies that no recovery is expected from the consumer +but it can still try to gather telemetry information (devcoredump, syslog) for +debug purpose in order to root cause the hang. This is useful because the first +hang is usually the most critical one which can result in consequential hangs +or complete wedging. Vendor Specific Recovery ------------------------ diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 2fafa1f35ef3..5d708a106b3f 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -9,6 +9,7 @@ GPU Driver Developer's Guide drm-mm drm-kms drm-kms-helpers + drm-ras drm-uapi drm-usage-stats driver-uapi diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 3cd0c8860b94..d8f519693fc2 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -119,12 +119,6 @@ Simple DRM drivers to use as examples The DRM subsystem contains a lot of helper functions to ease writing drivers for simple graphic devices. For example, the `drivers/gpu/drm/tiny/` directory has a set of drivers that are simple enough to be implemented in a single source file. - -These drivers make use of the `struct drm_simple_display_pipe_funcs`, that hides -any complexity of the DRM subsystem and just requires drivers to implement a few -functions needed to operate the device. This could be used for devices that just -need a display pipeline with one full-screen scanout buffer feeding one output. - The tiny DRM drivers are good examples to understand how DRM drivers should look like. Since are just a few hundreds lines of code, they are quite easy to read. diff --git a/Documentation/gpu/nova/core/todo.rst b/Documentation/gpu/nova/core/todo.rst index d1964eb645e2..d5130b2b08fb 100644 --- a/Documentation/gpu/nova/core/todo.rst +++ b/Documentation/gpu/nova/core/todo.rst @@ -51,82 +51,6 @@ There also have been considerations of ToPrimitive [2]. | Link: https://lore.kernel.org/all/cover.1750689857.git.y.j3ms.n@gmail.com/ [1] | Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Implement.20.60FromPrimitive.60.20trait.20.2B.20derive.20macro.20for.20nova-core/with/541971854 [2] -Generic register abstraction [REGA] ------------------------------------ - -Work out how register constants and structures can be automatically generated -through generalized macros. - -Example: - -.. code-block:: rust - - register!(BOOT0, 0x0, u32, pci::Bar<SIZE>, Fields [ - MINOR_REVISION(3:0, RO), - MAJOR_REVISION(7:4, RO), - REVISION(7:0, RO), // Virtual register combining major and minor rev. - ]) - -This could expand to something like: - -.. code-block:: rust - - const BOOT0_OFFSET: usize = 0x00000000; - const BOOT0_MINOR_REVISION_SHIFT: u8 = 0; - const BOOT0_MINOR_REVISION_MASK: u32 = 0x0000000f; - const BOOT0_MAJOR_REVISION_SHIFT: u8 = 4; - const BOOT0_MAJOR_REVISION_MASK: u32 = 0x000000f0; - const BOOT0_REVISION_SHIFT: u8 = BOOT0_MINOR_REVISION_SHIFT; - const BOOT0_REVISION_MASK: u32 = BOOT0_MINOR_REVISION_MASK | BOOT0_MAJOR_REVISION_MASK; - - struct Boot0(u32); - - impl Boot0 { - #[inline] - fn read(bar: &RevocableGuard<'_, pci::Bar<SIZE>>) -> Self { - Self(bar.readl(BOOT0_OFFSET)) - } - - #[inline] - fn minor_revision(&self) -> u32 { - (self.0 & BOOT0_MINOR_REVISION_MASK) >> BOOT0_MINOR_REVISION_SHIFT - } - - #[inline] - fn major_revision(&self) -> u32 { - (self.0 & BOOT0_MAJOR_REVISION_MASK) >> BOOT0_MAJOR_REVISION_SHIFT - } - - #[inline] - fn revision(&self) -> u32 { - (self.0 & BOOT0_REVISION_MASK) >> BOOT0_REVISION_SHIFT - } - } - -Usage: - -.. code-block:: rust - - let bar = bar.try_access().ok_or(ENXIO)?; - - let boot0 = Boot0::read(&bar); - pr_info!("Revision: {}\n", boot0.revision()); - -A work-in-progress implementation currently resides in -`drivers/gpu/nova-core/regs/macros.rs` and is used in nova-core. It would be -nice to improve it (possibly using proc macros) and move it to the `kernel` -crate so it can be used by other components as well. - -Features desired before this happens: - -* Make I/O optional I/O (for field values that are not registers), -* Support other sizes than `u32`, -* Allow visibility control for registers and individual fields, -* Use Rust slice syntax to express fields ranges. - -| Complexity: Advanced -| Contact: Alexandre Courbot - Numerical operations [NUMM] --------------------------- diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 520da44a04a6..bc9f14c8a2ec 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -29,6 +29,38 @@ refactorings already and are an expert in the specific area Subsystem-wide refactorings =========================== +Open-code drm_simple_encoder_init() +----------------------------------- + +The helper drm_simple_encoder_init() was supposed to simplify encoder +initialization. Instead it only added an intermediate layer between atomic +modesetting and the DRM driver. + +The task here is to remove drm_simple_encoder_init(). Search for a driver +that calls drm_simple_encoder_init() and inline the helper. The driver will +also need its own instance of drm_encoder_funcs. + +Contact: Thomas Zimmermann, respective driver maintainer + +Level: Easy + +Replace struct drm_simple_display_pipe with regular atomic helpers +------------------------------------------------------------------ + +The data type struct drm_simple_display_pipe and its helpers were supposed +to simplify driver development. Instead they only added an intermediate layer +between atomic modesetting and the DRM driver. + +There are still drivers that use drm_simple_display_pipe. The task here is to +convert them to use regular atomic helpers. Search for a driver that calls +drm_simple_display_pipe_init() and inline all helpers from drm_simple_kms_helper.c +into the driver, such that no simple-KMS interfaces are required. Please also +rename all inlined fucntions according to driver conventions. + +Contact: Thomas Zimmermann, respective driver maintainer + +Level: Easy + Remove custom dumb_map_offset implementations --------------------------------------------- diff --git a/Documentation/gpu/xe/xe_firmware.rst b/Documentation/gpu/xe/xe_firmware.rst index 5d23e9f27391..9c15a300bc62 100644 --- a/Documentation/gpu/xe/xe_firmware.rst +++ b/Documentation/gpu/xe/xe_firmware.rst @@ -31,6 +31,9 @@ GuC Power Conservation (PC) .. kernel-doc:: drivers/gpu/drm/xe/xe_guc_pc.c :doc: GuC Power Conservation (PC) +.. kernel-doc:: drivers/gpu/drm/xe/xe_guc_rc.c + :doc: GuC Render C-states (GuC RC) + PCIe Gen5 Limitations ===================== diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst index 068a5906b177..21500c1cc1fe 100644 --- a/Documentation/hid/intel-ish-hid.rst +++ b/Documentation/hid/intel-ish-hid.rst @@ -163,8 +163,8 @@ The transport layer is a bi-directional protocol, which defines: - A flow control mechanism to avoid buffer overflows This protocol resembles bus messages described in the following document: -http://www.intel.com/content/dam/www/public/us/en/documents/technical-\ -specifications/dcmi-hi-1-0-spec.pdf "Chapter 7: Bus Message Layer" +http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/dcmi-hi-1-0-spec.pdf +"Chapter 7: Bus Message Layer". Connection and Flow Control Mechanism ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/hwmon/aps-379.rst b/Documentation/hwmon/aps-379.rst new file mode 100644 index 000000000000..6d4e63283e34 --- /dev/null +++ b/Documentation/hwmon/aps-379.rst @@ -0,0 +1,57 @@ +Kernel driver aps-379 +===================== + +Supported chips: + + * Sony APS-379 + + Prefix: 'aps-379' + + Addresses scanned: - + + Authors: + - Chris Packham + +Description +----------- + +This driver implements support for the PMBus monitor on the Sony APS-379 +modular power supply. The APS-379 deviates from the PMBus standard for the +READ_VOUT command by using the linear11 format instead of linear16. + +The known supported PMBus commands are: + +=== ============================= ========= ======= ===== +Cmd Function Protocol Scaling Bytes +=== ============================= ========= ======= ===== +01 On / Off Command (OPERATION) Byte R/W -- 1 +10 WRITE_PROTECT Byte R/W -- 1 +3B FAN_COMMAND_1 Word R/W -- 2 +46 Current Limit (in percent) Word R/W 2^0 2 +47 Current Limit Fault Response Byte R/W -- 1 +79 Alarm Data Bits (STATUS_WORD) Word Rd -- 2 +8B Output Voltage (READ_VOUT) Word Rd 2^-4 2 +8C Output Current (READ_IOUT) Word Rd 2^-2 2 +8D Power Supply Ambient Temp Word Rd 2^0 2 +90 READ_FAN_SPEED_1 Word Rd 2^6 2 +91 READ_FAN_SPEED_2 Word Rd 2^6 2 +96 Output Wattage (READ_POUT) Word Rd 2^1 2 +97 Input Wattage (READ_PIN) Word Rd 2^1 2 +9A Unit Model Number (MFR_MODEL) Block R/W -- 10 +9B Unit Revision Number Block R/W -- 10 +9E Unit Serial Number Block R/W -- 8 +99 Unit Manufacturer ID (MFR_ID) Block R/W -- 8 +D0 Unit Run Time Information Block Rd -- 4 +D5 Firmware Version Rd cust -- 8 +B0 User Data 1 (USER_DATA_00) Block R/W -- 4 +B1 User Data 2 (USER_DATA_01) Block R/W -- 4 +B2 User Data 3 (USER_DATA_02) Block R/W -- 4 +B3 User Data 4 (USER_DATA_03) Block R/W -- 4 +B4 User Data 5 (USER_DATA_04) Block R/W -- 4 +B5 User Data 6 (USER_DATA_05) Block R/W -- 4 +B6 User Data 7 (USER_DATA_06) Block R/W -- 4 +B7 User Data 8 (USER_DATA_07) Block R/W -- 4 +F0 Calibration command Byte R/W -- 1 +F1 Calibration data Word Wr 2^9 2 +F2 Unlock Calibration Byte Wr -- 1 +=== ============================= ========= ======= ===== diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst index 58986546c723..9ad3f0a57f55 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -22,6 +22,7 @@ Supported boards: * ROG CROSSHAIR VIII FORMULA * ROG CROSSHAIR VIII HERO * ROG CROSSHAIR VIII IMPACT + * ROG CROSSHAIR X670E EXTREME * ROG CROSSHAIR X670E HERO * ROG CROSSHAIR X670E GENE * ROG MAXIMUS X HERO @@ -32,6 +33,7 @@ Supported boards: * ROG STRIX B550-I GAMING * ROG STRIX B650E-I GAMING WIFI * ROG STRIX B850-I GAMING WIFI + * ROG STRIX X470-F GAMING * ROG STRIX X470-I GAMING * ROG STRIX X570-E GAMING * ROG STRIX X570-E GAMING WIFI II @@ -48,6 +50,7 @@ Supported boards: * ROG STRIX Z690-A GAMING WIFI D4 * ROG STRIX Z690-E GAMING WIFI * ROG STRIX Z790-E GAMING WIFI II + * ROG STRIX Z790-H GAMING WIFI * ROG STRIX Z790-I GAMING WIFI * ROG ZENITH II EXTREME * ROG ZENITH II EXTREME ALPHA diff --git a/Documentation/hwmon/bt1-pvt.rst b/Documentation/hwmon/bt1-pvt.rst deleted file mode 100644 index cbb0c0613132..000000000000 --- a/Documentation/hwmon/bt1-pvt.rst +++ /dev/null @@ -1,117 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0-only - -Kernel driver bt1-pvt -===================== - -Supported chips: - - * Baikal-T1 PVT sensor (in SoC) - - Prefix: 'bt1-pvt' - - Addresses scanned: - - - Datasheet: Provided by BAIKAL ELECTRONICS upon request and under NDA - -Authors: - Maxim Kaurkin <maxim.kaurkin@baikalelectronics.ru> - Serge Semin <Sergey.Semin@baikalelectronics.ru> - -Description ------------ - -This driver implements support for the hardware monitoring capabilities of the -embedded into Baikal-T1 process, voltage and temperature sensors. PVT IP-core -consists of one temperature and four voltage sensors, which can be used to -monitor the chip internal environment like heating, supply voltage and -transistors performance. The driver can optionally provide the hwmon alarms -for each sensor the PVT controller supports. The alarms functionality is made -compile-time configurable due to the hardware interface implementation -peculiarity, which is connected with an ability to convert data from only one -sensor at a time. Additional limitation is that the controller performs the -thresholds checking synchronously with the data conversion procedure. Due to -these in order to have the hwmon alarms automatically detected the driver code -must switch from one sensor to another, read converted data and manually check -the threshold status bits. Depending on the measurements timeout settings -(update_interval sysfs node value) this design may cause additional burden on -the system performance. So in case if alarms are unnecessary in your system -design it's recommended to have them disabled to prevent the PVT IRQs being -periodically raised to get the data cache/alarms status up to date. By default -in alarm-less configuration the data conversion is performed by the driver -on demand when read operation is requested via corresponding _input-file. - -Temperature Monitoring ----------------------- - -Temperature is measured with 10-bit resolution and reported in millidegree -Celsius. The driver performs all the scaling by itself therefore reports true -temperatures that don't need any user-space adjustments. While the data -translation formulae isn't linear, which gives us non-linear discreteness, -it's close to one, but giving a bit better accuracy for higher temperatures. -The temperature input is mapped as follows (the last column indicates the input -ranges):: - - temp1: CPU embedded diode -48.38C - +147.438C - -In case if the alarms kernel config is enabled in the driver the temperature input -has associated min and max limits which trigger an alarm when crossed. - -Voltage Monitoring ------------------- - -The voltage inputs are also sampled with 10-bit resolution and reported in -millivolts. But in this case the data translation formulae is linear, which -provides a constant measurements discreteness. The data scaling is also -performed by the driver, so returning true millivolts. The voltage inputs are -mapped as follows (the last column indicates the input ranges):: - - in0: VDD (processor core) 0.62V - 1.168V - in1: Low-Vt (low voltage threshold) 0.62V - 1.168V - in2: High-Vt (high voltage threshold) 0.62V - 1.168V - in3: Standard-Vt (standard voltage threshold) 0.62V - 1.168V - -In case if the alarms config is enabled in the driver the voltage inputs -have associated min and max limits which trigger an alarm when crossed. - -Sysfs Attributes ----------------- - -Following is a list of all sysfs attributes that the driver provides, their -permissions and a short description: - -=============================== ======= ======================================= -Name Perm Description -=============================== ======= ======================================= -update_interval RW Measurements update interval per - sensor. -temp1_type RO Sensor type (always 1 as CPU embedded - diode). -temp1_label RO CPU Core Temperature sensor. -temp1_input RO Measured temperature in millidegree - Celsius. -temp1_min RW Low limit for temp input. -temp1_max RW High limit for temp input. -temp1_min_alarm RO Temperature input alarm. Returns 1 if - temperature input went below min limit, - 0 otherwise. -temp1_max_alarm RO Temperature input alarm. Returns 1 if - temperature input went above max limit, - 0 otherwise. -temp1_offset RW Temperature offset in millidegree - Celsius which is added to the - temperature reading by the chip. It can - be used to manually adjust the - temperature measurements within 7.130 - degrees Celsius. -in[0-3]_label RO CPU Voltage sensor (either core or - low/high/standard thresholds). -in[0-3]_input RO Measured voltage in millivolts. -in[0-3]_min RW Low limit for voltage input. -in[0-3]_max RW High limit for voltage input. -in[0-3]_min_alarm RO Voltage input alarm. Returns 1 if - voltage input went below min limit, - 0 otherwise. -in[0-3]_max_alarm RO Voltage input alarm. Returns 1 if - voltage input went above max limit, - 0 otherwise. -=============================== ======= ======================================= diff --git a/Documentation/hwmon/ina2xx.rst b/Documentation/hwmon/ina2xx.rst index a3860aae444c..d64e7af46a12 100644 --- a/Documentation/hwmon/ina2xx.rst +++ b/Documentation/hwmon/ina2xx.rst @@ -74,6 +74,16 @@ Supported chips: https://us1.silergy.com/ + * Texas Instruments INA234 + + Prefix: 'ina234' + + Addresses: I2C 0x40 - 0x43 + + Datasheet: Publicly available at the Texas Instruments website + + https://www.ti.com/ + Author: Lothar Felten <lothar.felten@gmail.com> Description @@ -89,7 +99,7 @@ interface. The INA220 monitors both shunt drop and supply voltage. The INA226 is a current shunt and power monitor with an I2C interface. The INA226 monitors both a shunt voltage drop and bus supply voltage. -INA230 and INA231 are high or low side current shunt and power monitors +INA230, INA231, and INA234 are high or low side current shunt and power monitors with an I2C interface. The chips monitor both a shunt voltage drop and bus supply voltage. @@ -124,8 +134,17 @@ power1_input Power(uW) measurement channel shunt_resistor Shunt resistance(uOhm) channel (not for ina260) ======================= =============================================== -Additional sysfs entries for ina226, ina230, ina231, ina260, and sy24655 ------------------------------------------------------------------------- +Additional sysfs entries +------------------------ + +Additional entries are available for the following chips: + + * ina226 + * ina230 + * ina231 + * ina234 + * ina260 + * sy24655 ======================= ==================================================== curr1_lcrit Critical low current diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index b2ca8513cfcd..8b655e5d6b68 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -41,6 +41,7 @@ Hardware Monitoring Kernel Drivers adt7475 aht10 amc6821 + aps-379 aquacomputer_d5next asb100 asc7621 @@ -52,7 +53,6 @@ Hardware Monitoring Kernel Drivers bcm54140 bel-pfe bpa-rs600 - bt1-pvt cgbc-hwmon chipcap2 coretemp @@ -111,6 +111,7 @@ Hardware Monitoring Kernel Drivers kbatt kfan lan966x + lattepanda-sigma-ec lineage-pem lm25066 lm63 @@ -174,6 +175,7 @@ Hardware Monitoring Kernel Drivers mc33xs2410_hwmon mc34vr500 mcp3021 + mcp9982 menf21bmc mlxreg-fan mp2856 @@ -282,4 +284,5 @@ Hardware Monitoring Kernel Drivers xdp710 xdpe12284 xdpe152c4 + yogafan zl6100 diff --git a/Documentation/hwmon/isl68137.rst b/Documentation/hwmon/isl68137.rst index e77f582c2850..0ce20d09164f 100644 --- a/Documentation/hwmon/isl68137.rst +++ b/Documentation/hwmon/isl68137.rst @@ -394,6 +394,26 @@ Supported chips: Provided by Renesas upon request and NDA + * Renesas RAA228942 + + Prefix: 'raa228942' + + Addresses scanned: - + + Datasheet: + + Provided by Renesas upon request and NDA + + * Renesas RAA228943 + + Prefix: 'raa228943' + + Addresses scanned: - + + Datasheet: + + Provided by Renesas upon request and NDA + * Renesas RAA229001 Prefix: 'raa229001' diff --git a/Documentation/hwmon/it87.rst b/Documentation/hwmon/it87.rst index 5cef4f265000..fc1c90b023ae 100644 --- a/Documentation/hwmon/it87.rst +++ b/Documentation/hwmon/it87.rst @@ -25,6 +25,14 @@ Supported chips: Datasheet: Not publicly available + * IT8689E + + Prefix: 'it8689' + + Addresses scanned: from Super I/O config space (8 I/O ports) + + Datasheet: Not publicly available + * IT8705F Prefix: 'it87' @@ -228,9 +236,9 @@ Description ----------- This driver implements support for the IT8603E, IT8620E, IT8623E, IT8628E, -IT8705F, IT8712F, IT8716F, IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8732F, -IT8758E, IT8771E, IT8772E, IT8781F, IT8782F, IT8783E/F, IT8786E, IT8790E, -IT8792E/IT8795E, IT87952E and SiS950 chips. +IT8689E, IT8705F, IT8712F, IT8716F, IT8718F, IT8720F, IT8721F, IT8726F, +IT8728F, IT8732F, IT8758E, IT8771E, IT8772E, IT8781F, IT8782F, IT8783E/F, +IT8786E, IT8790E, IT8792E/IT8795E, IT87952E and SiS950 chips. These chips are 'Super I/O chips', supporting floppy disks, infrared ports, joysticks and other miscellaneous stuff. For hardware monitoring, they @@ -274,6 +282,9 @@ of the fan is not supported (value 0 of pwmX_enable). The IT8620E and IT8628E are custom designs, hardware monitoring part is similar to IT8728F. It only supports 16-bit fan mode. Both chips support up to 6 fans. +The IT8689E supports newer autopwm, 12mV ADC, 16-bit fans, six fans, six PWM +channels, PWM frequency 2, six temperature inputs, and AVCC3 (in9). + The IT8790E, IT8792E/IT8795E and IT87952E support up to 3 fans. 16-bit fan mode is always enabled. @@ -301,12 +312,15 @@ of 0.016 volt. IT8603E, IT8721F/IT8758E and IT8728F can measure between 0 and 2.8 volts with a resolution of 0.0109 volt. The battery voltage in8 does not have limit registers. -On the IT8603E, IT8620E, IT8628E, IT8721F/IT8758E, IT8732F, IT8781F, IT8782F, -and IT8783E/F, some voltage inputs are internal and scaled inside the chip: +On the IT8603E, IT8620E, IT8628E, IT8689E, IT8721F/IT8758E, IT8732F, IT8781F, +IT8782F, and IT8783E/F, some voltage inputs are internal and scaled inside the +chip: + * in3 (optional) * in7 (optional for IT8781F, IT8782F, and IT8783E/F) * in8 (always) -* in9 (relevant for IT8603E only) +* in9 (IT8603E, IT8622E, and IT8689E: always AVCC3; others: optional) + The driver handles this transparently so user-space doesn't have to care. The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value: diff --git a/Documentation/hwmon/lattepanda-sigma-ec.rst b/Documentation/hwmon/lattepanda-sigma-ec.rst new file mode 100644 index 000000000000..8a521ee1fef1 --- /dev/null +++ b/Documentation/hwmon/lattepanda-sigma-ec.rst @@ -0,0 +1,61 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver lattepanda-sigma-ec +================================= + +Supported systems: + + * LattePanda Sigma (Intel 13th Gen i5-1340P) + + DMI vendor: LattePanda + + DMI product: LattePanda Sigma + + BIOS version: 5.27 (verified) + + Datasheet: Not available (EC registers discovered empirically) + +Author: Mariano Abad <weimaraner@gmail.com> + +Description +----------- + +This driver provides hardware monitoring for the LattePanda Sigma +single-board computer made by DFRobot. The board uses an ITE IT8613E +Embedded Controller to manage a CPU cooling fan and thermal sensors. + +The BIOS declares the ACPI Embedded Controller (``PNP0C09``) with +``_STA`` returning 0, preventing the kernel's ACPI EC subsystem from +initializing. This driver reads the EC directly via the standard ACPI +EC I/O ports (``0x62`` data, ``0x66`` command/status). + +Sysfs attributes +---------------- + +======================= =============================================== +``fan1_input`` Fan speed in RPM (EC registers 0x2E:0x2F, + 16-bit big-endian) +``fan1_label`` "CPU Fan" +``temp1_input`` Board/ambient temperature in millidegrees + Celsius (EC register 0x60, unsigned) +``temp1_label`` "Board Temp" +``temp2_input`` CPU proximity temperature in millidegrees + Celsius (EC register 0x70, unsigned) +``temp2_label`` "CPU Temp" +======================= =============================================== + +Module parameters +----------------- + +``force`` (bool, default false) + Force loading on BIOS versions other than 5.27. The driver still + requires DMI vendor and product name matching. + +Known limitations +----------------- + +* Fan speed control is not supported. The fan is always under EC + automatic control. +* The EC register map was verified only on BIOS version 5.27. + Other versions may use different register offsets; use the ``force`` + parameter at your own risk. diff --git a/Documentation/hwmon/ltc4282.rst b/Documentation/hwmon/ltc4282.rst index a87ec3564998..dd730207b141 100644 --- a/Documentation/hwmon/ltc4282.rst +++ b/Documentation/hwmon/ltc4282.rst @@ -9,8 +9,7 @@ Supported chips: Prefix: 'ltc4282' - Addresses scanned: - I2C 0x40 - 0x5A (7-bit) - Addresses scanned: - I2C 0x80 - 0xB4 with a step of 2 (8-bit) + Addresses scanned: - Datasheet: diff --git a/Documentation/hwmon/mcp9982.rst b/Documentation/hwmon/mcp9982.rst new file mode 100644 index 000000000000..790ee1697b45 --- /dev/null +++ b/Documentation/hwmon/mcp9982.rst @@ -0,0 +1,111 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Kernel driver MCP998X +===================== + +Supported chips: + + * Microchip Technology MCP998X/MCP9933 and MCP998XD/MCP9933D + + Prefix: 'mcp9982' + + Datasheet: + https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/MCP998X-Family-Data-Sheet-DS20006827.pdf + +Authors: + + - Victor Duicu <victor.duicu@microchip.com> + +Description +----------- + +This driver implements support for the MCP998X family containing: MCP9982, +MCP9982D, MCP9983, MCP9983D, MCP9984, MCP9984D, MCP9985, MCP9985D, +MCP9933 and MCP9933D. + +The MCP998X Family is a high accuracy 2-wire multichannel automotive +temperature monitor. + +The chips in the family have different numbers of external channels, +ranging from 1 (MCP9982) to 4 channels (MCP9985). Reading diodes in +anti-parallel connection is supported by MCP9984/85/33 and +MCP9984D/85D/33D. Dedicated hardware shutdown circuitry is present +only in MCP998XD and MCP9933D. + +Temperatures are read in millidegrees Celsius, ranging from -64 to +191.875 with 0.125 precision. + +Each channel has a minimum, maximum, and critical limit alongside associated alarms. +The chips also implement a hysteresis mechanism which applies only to the maximum +and critical limits. The relative difference between a limit and its hysteresis +is the same for both and the value is kept in a single register. + +The chips measure temperatures with a variable conversion rate. +Update_interval = Conversion/Second, so the available options are: +- 16000 (ms) = 1 conv/16 sec +- 8000 (ms) = 1 conv/8 sec +- 4000 (ms) = 1 conv/4 sec +- 2000 (ms) = 1 conv/2 sec +- 1000 (ms) = 1 conv/sec +- 500 (ms) = 2 conv/sec +- 250 (ms) = 4 conv/sec +- 125 (ms) = 8 conv/sec +- 64 (ms) = 16 conv/sec +- 32 (ms) = 32 conv/sec +- 16 (ms) = 64 conv/sec + +Usage Notes +----------- + +Parameters that can be configured in devicetree: +- anti-parallel diode mode operation +- resistance error correction on channels 1 and 2 +- resistance error correction on channels 3 and 4 +- power state + +Chips 82/83 and 82D/83D do not support anti-parallel diode mode. +For chips with "D" in the name resistance error correction must be on. +Please see Documentation/devicetree/bindings/hwmon/microchip,mcp9982.yaml +for details. + +There are two power states: +- Active state: in which the chip is converting on all channels at the +programmed rate. + +- Standby state: in which the host must initiate a conversion cycle. + +Chips with "D" in the name work in Active state only and those without +can work in either state. + +Chips with "D" in the name can't set update interval slower than 1 second. + +Among the hysteresis attributes, only the tempX_crit_hyst ones are writeable +while the others are read only. Setting tempX_crit_hyst writes the difference +between tempX_crit and tempX_crit_hyst in the hysteresis register. The new value +applies automatically to the other limits. At power up the device starts with +a 10 degree hysteresis. + +Sysfs entries +------------- + +The following attributes are supported. The temperature limits and +update_interval are read-write. The attribute tempX_crit_hyst is read-write, +while tempX_max_hyst is read only. All other attributes are read only. + +======================= ================================================== +temp[1-5]_label User name for channel. +temp[1-5]_input Measured temperature for channel. + +temp[1-5]_crit Critical temperature limit. +temp[1-5]_crit_alarm Critical temperature limit alarm. +temp[1-5]_crit_hyst Critical temperature limit hysteresis. + +temp[1-5]_max High temperature limit. +temp[1-5]_max_alarm High temperature limit alarm. +temp[1-5]_max_hyst High temperature limit hysteresis. + +temp[1-5]_min Low temperature limit. +temp[1-5]_min_alarm Low temperature limit alarm. + +update_interval The interval at which the chip will update readings. +======================= ================================================== diff --git a/Documentation/hwmon/tmp102.rst b/Documentation/hwmon/tmp102.rst index b1f585531a88..425a09a3c9b3 100644 --- a/Documentation/hwmon/tmp102.rst +++ b/Documentation/hwmon/tmp102.rst @@ -11,6 +11,22 @@ Supported chips: Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp102.html + * Texas Instruments TMP110 + + Prefix: 'tmp110' + + Addresses scanned: none + + Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp110.html + + * Texas Instruments TMP113 + + Prefix: 'tmp113' + + Addresses scanned: none + + Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp113.html + Author: Steven King <sfking@fdwdc.com> @@ -25,7 +41,25 @@ degree from -40 to +125 C. Resolution of the sensor is 0.0625 degree. The operating temperature has a minimum of -55 C and a maximum of +150 C. The TMP102 has a programmable update rate that can select between 8, 4, 1, and -0.5 Hz. (Currently the driver only supports the default of 4 Hz). +0.25 Hz. + +The TMP110 and TMP113 are software compatible with TMP102, but have different +accuracy (maximum error) specifications. The TMP110 has an accuracy (maximum error) +of 1.0 degree, TMP113 has an accuracy (maximum error) of 0.3 degree, while TMP102 +has an accuracy (maximum error) of 2.0 degree. + +sysfs-Interface +--------------- + +The following list includes the sysfs attributes that the driver provides, their +permissions and a short description: -The driver provides the common sysfs-interface for temperatures (see -Documentation/hwmon/sysfs-interface.rst under Temperatures). +=============================== ======= =========================================== +Name Perm Description +=============================== ======= =========================================== +temp1_input: RO Temperature input +temp1_label: RO Descriptive name for the sensor +temp1_max: RW Maximum temperature +temp1_max_hyst: RW Maximum hysteresis temperature +update_interval RW Update conversions interval in milliseconds +=============================== ======= =========================================== diff --git a/Documentation/hwmon/yogafan.rst b/Documentation/hwmon/yogafan.rst new file mode 100644 index 000000000000..c553a381f772 --- /dev/null +++ b/Documentation/hwmon/yogafan.rst @@ -0,0 +1,138 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +=============================================================================================== +Kernel driver yogafan +=============================================================================================== + +Supported chips: + + * Lenovo Yoga, Legion, IdeaPad, Slim, Flex, and LOQ Embedded Controllers + * Prefix: 'yogafan' + * Addresses: ACPI handle (See Database Below) + +Author: Sergio Melas <sergiomelas@gmail.com> + +Description +----------- + +This driver provides fan speed monitoring for modern Lenovo consumer laptops. +Most Lenovo laptops do not provide fan tachometer data through standard +ISA/LPC hardware monitoring chips. Instead, the data is stored in the +Embedded Controller (EC) and exposed via ACPI. + +The driver implements a **Rate-Limited Lag (RLLag)** filter to handle +the low-resolution and jittery sampling found in Lenovo EC firmware. + +Hardware Identification and Multiplier Logic +-------------------------------------------- + +The driver supports two distinct EC architectures. Differentiation is handled +deterministically via a DMI Product Family quirk table during the probe phase, +eliminating the need for runtime heuristics. + +1. 8-bit EC Architecture (Multiplier: 100) + + - **Families:** Yoga, IdeaPad, Slim, Flex. + - **Technical Detail:** These models allocate a single 8-bit register for + tachometer data. Since 8-bit fields are limited to a value of 255, the + BIOS stores fan speed in units of 100 RPM (e.g., 42 = 4200 RPM). + +2. 16-bit EC Architecture (Multiplier: 1) + + - **Families:** Legion, LOQ. + - **Technical Detail:** High-performance gaming models require greater + precision for fans exceeding 6000 RPM. These use a 16-bit word (2 bytes) + storing the raw RPM value directly. + +Filter Details +-------------- + +The RLLag filter is a passive discrete-time first-order lag model that ensures: + - **Smoothing:** Low-resolution step increments are smoothed into 1-RPM increments. + - **Slew-Rate Limiting:** Prevents unrealistic readings by capping the change + to 1500 RPM/s, matching physical fan inertia. + - **Polling Independence:** The filter math scales based on the time delta + between userspace reads, ensuring a consistent physical curve regardless + of polling frequency. + +Suspend and Resume +------------------ + +The driver utilizes the boottime clock (ktime_get_boottime()) to calculate the +sampling delta. This ensures that time spent in system suspend is accounted +for. If the delta exceeds 5 seconds (e.g., after waking the laptop), the +filter automatically resets to the current hardware value to prevent +reporting "ghost" RPM data from before the sleep state. + +Usage +----- + +The driver exposes standard hwmon sysfs attributes: + +=============== ============================ +Attribute Description +fanX_input Filtered fan speed in RPM. +=============== ============================ + + +Note: If the hardware reports 0 RPM, the filter is bypassed and 0 is reported +immediately to ensure the user knows the fan has stopped. + + +==================================================================================================== + LENOVO FAN CONTROLLER: MASTER REFERENCE DATABASE (2026) +==================================================================================================== + +:: + + MODEL (DMI PN) | FAMILY / SERIES | EC OFFSET | FULL ACPI OBJECT PATH | WIDTH | MULTiplier + ---------------------------------------------------------------------------------------------------- + 82N7 | Yoga 14cACN | 0x06 | \_SB.PCI0.LPC0.EC0.FANS | 8-bit | 100 + 80V2 / 81C3 | Yoga 710/720 | 0x06 | \_SB.PCI0.LPC0.EC0.FAN0 | 8-bit | 100 + 83E2 / 83DN | Yoga Pro 7/9 | 0xFE | \_SB.PCI0.LPC0.EC0.FANS | 8-bit | 100 + 82A2 / 82A3 | Yoga Slim 7 | 0x06 | \_SB.PCI0.LPC0.EC0.FANS | 8-bit | 100 + 81YM / 82FG | IdeaPad 5 | 0x06 | \_SB.PCI0.LPC0.EC0.FAN0 | 8-bit | 100 + 82JW / 82JU | Legion 5 (AMD) | 0xFE/0xFF | \_SB.PCI0.LPC0.EC0.FANS (Fan1) | 16-bit | 1 + 82JW / 82JU | Legion 5 (AMD) | 0xFE/0xFF | \_SB.PCI0.LPC0.EC0.FA2S (Fan2) | 16-bit | 1 + 82WQ | Legion 7i (Int) | 0xFE/0xFF | \_SB.PCI0.LPC0.EC0.FANS (Fan1) | 16-bit | 1 + 82WQ | Legion 7i (Int) | 0xFE/0xFF | \_SB.PCI0.LPC0.EC0.FA2S (Fan2) | 16-bit | 1 + 82XV / 83DV | LOQ 15/16 | 0xFE/0xFF | \_SB.PCI0.LPC0.EC0.FANS /FA2S | 16-bit | 1 + 83AK | ThinkBook G6 | 0x06 | \_SB.PCI0.LPC0.EC0.FAN0 | 8-bit | 100 + 81X1 | Flex 5 | 0x06 | \_SB.PCI0.LPC0.EC0.FAN0 | 8-bit | 100 + *Legacy* | Pre-2020 Models | 0x06 | \_SB.PCI0.LPC.EC.FAN0 | 8-bit | 100 + ---------------------------------------------------------------------------------------------------- + +METHODOLOGY & IDENTIFICATION: + +1. DSDT ANALYSIS (THE PATH): + BIOS ACPI tables were analyzed using 'iasl' and cross-referenced with + public dumps. Internal labels (FANS, FAN0, FA2S) are mapped to + EmbeddedControl OperationRegion offsets. + +2. EC MEMORY MAPPING (THE OFFSET): + Validated by matching NBFC (NoteBook FanControl) XML logic with DSDT Field + definitions found in BIOS firmware. + +3. DATA-WIDTH ANALYSIS (THE MULTIPLIER): + - 8-bit (Multiplier 100): Standard for Yoga/IdeaPad. Raw values (0-255). + - 16-bit (Multiplier 1): Standard for Legion/LOQ. Two registers (0xFE/0xFF). + + +References +---------- + +1. **ACPI Specification (Field Objects):** Documentation on how 8-bit vs 16-bit + fields are accessed in OperationRegions. + https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#field-objects + +2. **NBFC Projects:** Community-driven reverse engineering + of Lenovo Legion/LOQ EC memory maps (16-bit raw registers). + https://github.com/hirschmann/nbfc/tree/master/Configs + +3. **Linux Kernel Timekeeping API:** Documentation for ktime_get_boottime() and + handling deltas across suspend states. + https://www.kernel.org/doc/html/latest/core-api/timekeeping.html + +4. **Lenovo IdeaPad Laptop Driver:** Reference for DMI-based hardware + feature gating in Lenovo laptops. + https://github.com/torvalds/linux/blob/master/drivers/platform/x86/ideapad-laptop.c diff --git a/Documentation/infiniband/index.rst b/Documentation/infiniband/index.rst index c11049d25703..f57387a92338 100644 --- a/Documentation/infiniband/index.rst +++ b/Documentation/infiniband/index.rst @@ -9,7 +9,6 @@ InfiniBand core_locking ipoib - opa_vnic sysfs tag_matching ucaps diff --git a/Documentation/infiniband/opa_vnic.rst b/Documentation/infiniband/opa_vnic.rst deleted file mode 100644 index 2f888d9ffec0..000000000000 --- a/Documentation/infiniband/opa_vnic.rst +++ /dev/null @@ -1,159 +0,0 @@ -================================================================= -Intel Omni-Path (OPA) Virtual Network Interface Controller (VNIC) -================================================================= - -Intel Omni-Path (OPA) Virtual Network Interface Controller (VNIC) feature -supports Ethernet functionality over Omni-Path fabric by encapsulating -the Ethernet packets between HFI nodes. - -Architecture -============= -The patterns of exchanges of Omni-Path encapsulated Ethernet packets -involves one or more virtual Ethernet switches overlaid on the Omni-Path -fabric topology. A subset of HFI nodes on the Omni-Path fabric are -permitted to exchange encapsulated Ethernet packets across a particular -virtual Ethernet switch. The virtual Ethernet switches are logical -abstractions achieved by configuring the HFI nodes on the fabric for -header generation and processing. In the simplest configuration all HFI -nodes across the fabric exchange encapsulated Ethernet packets over a -single virtual Ethernet switch. A virtual Ethernet switch, is effectively -an independent Ethernet network. The configuration is performed by an -Ethernet Manager (EM) which is part of the trusted Fabric Manager (FM) -application. HFI nodes can have multiple VNICs each connected to a -different virtual Ethernet switch. The below diagram presents a case -of two virtual Ethernet switches with two HFI nodes:: - - +-------------------+ - | Subnet/ | - | Ethernet | - | Manager | - +-------------------+ - / / - / / - / / - / / - +-----------------------------+ +------------------------------+ - | Virtual Ethernet Switch | | Virtual Ethernet Switch | - | +---------+ +---------+ | | +---------+ +---------+ | - | | VPORT | | VPORT | | | | VPORT | | VPORT | | - +--+---------+----+---------+-+ +-+---------+----+---------+---+ - | \ / | - | \ / | - | \/ | - | / \ | - | / \ | - +-----------+------------+ +-----------+------------+ - | VNIC | VNIC | | VNIC | VNIC | - +-----------+------------+ +-----------+------------+ - | HFI | | HFI | - +------------------------+ +------------------------+ - - -The Omni-Path encapsulated Ethernet packet format is as described below. - -==================== ================================ -Bits Field -==================== ================================ -Quad Word 0: -0-19 SLID (lower 20 bits) -20-30 Length (in Quad Words) -31 BECN bit -32-51 DLID (lower 20 bits) -52-56 SC (Service Class) -57-59 RC (Routing Control) -60 FECN bit -61-62 L2 (=10, 16B format) -63 LT (=1, Link Transfer Head Flit) - -Quad Word 1: -0-7 L4 type (=0x78 ETHERNET) -8-11 SLID[23:20] -12-15 DLID[23:20] -16-31 PKEY -32-47 Entropy -48-63 Reserved - -Quad Word 2: -0-15 Reserved -16-31 L4 header -32-63 Ethernet Packet - -Quad Words 3 to N-1: -0-63 Ethernet packet (pad extended) - -Quad Word N (last): -0-23 Ethernet packet (pad extended) -24-55 ICRC -56-61 Tail -62-63 LT (=01, Link Transfer Tail Flit) -==================== ================================ - -Ethernet packet is padded on the transmit side to ensure that the VNIC OPA -packet is quad word aligned. The 'Tail' field contains the number of bytes -padded. On the receive side the 'Tail' field is read and the padding is -removed (along with ICRC, Tail and OPA header) before passing packet up -the network stack. - -The L4 header field contains the virtual Ethernet switch id the VNIC port -belongs to. On the receive side, this field is used to de-multiplex the -received VNIC packets to different VNIC ports. - -Driver Design -============== -Intel OPA VNIC software design is presented in the below diagram. -OPA VNIC functionality has a HW dependent component and a HW -independent component. - -The support has been added for IB device to allocate and free the RDMA -netdev devices. The RDMA netdev supports interfacing with the network -stack thus creating standard network interfaces. OPA_VNIC is an RDMA -netdev device type. - -The HW dependent VNIC functionality is part of the HFI1 driver. It -implements the verbs to allocate and free the OPA_VNIC RDMA netdev. -It involves HW resource allocation/management for VNIC functionality. -It interfaces with the network stack and implements the required -net_device_ops functions. It expects Omni-Path encapsulated Ethernet -packets in the transmit path and provides HW access to them. It strips -the Omni-Path header from the received packets before passing them up -the network stack. It also implements the RDMA netdev control operations. - -The OPA VNIC module implements the HW independent VNIC functionality. -It consists of two parts. The VNIC Ethernet Management Agent (VEMA) -registers itself with IB core as an IB client and interfaces with the -IB MAD stack. It exchanges the management information with the Ethernet -Manager (EM) and the VNIC netdev. The VNIC netdev part allocates and frees -the OPA_VNIC RDMA netdev devices. It overrides the net_device_ops functions -set by HW dependent VNIC driver where required to accommodate any control -operation. It also handles the encapsulation of Ethernet packets with an -Omni-Path header in the transmit path. For each VNIC interface, the -information required for encapsulation is configured by the EM via VEMA MAD -interface. It also passes any control information to the HW dependent driver -by invoking the RDMA netdev control operations:: - - +-------------------+ +----------------------+ - | | | Linux | - | IB MAD | | Network | - | | | Stack | - +-------------------+ +----------------------+ - | | | - | | | - +----------------------------+ | - | | | - | OPA VNIC Module | | - | (OPA VNIC RDMA Netdev | | - | & EMA functions) | | - | | | - +----------------------------+ | - | | - | | - +------------------+ | - | IB core | | - +------------------+ | - | | - | | - +--------------------------------------------+ - | | - | HFI1 Driver with VNIC support | - | | - +--------------------------------------------+ diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index bc8a283bc44b..441d8786fcbc 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -71,10 +71,6 @@ recommend:: PATH=/path/to/llvm/:$PATH make LLVM=-14 -``LLVM=0`` is not the same as omitting ``LLVM`` altogether, it will behave like -``LLVM=1``. If you only wish to use certain LLVM utilities, use their -respective make variables. - The same value used for ``LLVM=`` should be set for each invocation of ``make`` if configuring and building via distinct commands. ``LLVM=`` should also be set as an environment variable when running scripts that will eventually run diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst index d0703605bfa4..b3a26a36ee17 100644 --- a/Documentation/kbuild/modules.rst +++ b/Documentation/kbuild/modules.rst @@ -426,11 +426,12 @@ Symbols From the Kernel (vmlinux + modules) Version Information Formats --------------------------- - Exported symbols have information stored in __ksymtab or __ksymtab_gpl - sections. Symbol names and namespaces are stored in __ksymtab_strings, - using a format similar to the string table used for ELF. If - CONFIG_MODVERSIONS is enabled, the CRCs corresponding to exported - symbols will be added to the __kcrctab or __kcrctab_gpl. + Exported symbols have information stored in the __ksymtab and + __kflagstab sections. Symbol names and namespaces are stored in + __ksymtab_strings section, using a format similar to the string + table used for ELF. If CONFIG_MODVERSIONS is enabled, the CRCs + corresponding to exported symbols will be added to the + __kcrctab section. If CONFIG_BASIC_MODVERSIONS is enabled (default with CONFIG_MODVERSIONS), imported symbols will have their symbol name and diff --git a/Documentation/kbuild/reproducible-builds.rst b/Documentation/kbuild/reproducible-builds.rst index 96d208e578cd..bc1eb82211df 100644 --- a/Documentation/kbuild/reproducible-builds.rst +++ b/Documentation/kbuild/reproducible-builds.rst @@ -50,8 +50,10 @@ Absolute filenames ------------------ When the kernel is built out-of-tree, debug information may include -absolute filenames for the source files. This must be overridden by -including the ``-fdebug-prefix-map`` option in the `KCFLAGS`_ variable. +absolute filenames for the source files and build directory. These must +be overridden by including a ``-fdebug-prefix-map`` option for each in +the `KCFLAGS`_ and `KAFLAGS`_ variables to cover both ``.c`` and ``.S`` +files. Depending on the compiler used, the ``__FILE__`` macro may also expand to an absolute filename in an out-of-tree build. Kbuild automatically @@ -135,6 +137,7 @@ See ``scripts/setlocalversion`` for details. .. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp .. _KBUILD_BUILD_USER and KBUILD_BUILD_HOST: kbuild.html#kbuild-build-user-kbuild-build-host .. _KCFLAGS: kbuild.html#kcflags +.. _KAFLAGS: kbuild.html#kaflags .. _prefix-map options: https://reproducible-builds.org/docs/build-path/ .. _Reproducible Builds project: https://reproducible-builds.org/ .. _SOURCE_DATE_EPOCH: https://reproducible-builds.org/docs/source-date-epoch/ diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst index dd64f5d7f319..afc7d52bda2f 100644 --- a/Documentation/mm/damon/design.rst +++ b/Documentation/mm/damon/design.rst @@ -150,6 +150,8 @@ address on the given address space. Support of ``address unit`` parameter is up to each operations set implementation. ``paddr`` is the only operations set implementation that supports the parameter. +If the value is smaller than ``PAGE_SIZE``, only a power of two should be used. + .. _damon_core_logic: Core Logics @@ -165,6 +167,13 @@ monitoring attributes, ``sampling interval``, ``aggregation interval``, ``update interval``, ``minimum number of regions``, and ``maximum number of regions``. +Note that ``minimum number of regions`` must be 3 or higher. This is because the +virtual address space monitoring is designed to handle at least three regions to +accommodate two large unmapped areas commonly found in normal virtual address +spaces. While this restriction might not be strictly necessary for other +operation sets like ``paddr``, it is currently enforced across all DAMON +operations for consistency. + To know how user-space can set the attributes via :ref:`DAMON sysfs interface <sysfs_interface>`, refer to :ref:`monitoring_attrs <sysfs_monitoring_attrs>` part of the documentation. @@ -458,9 +467,13 @@ that supports each action are as below. - ``pageout``: Reclaim the region. Supported by ``vaddr``, ``fvaddr`` and ``paddr`` operations set. - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``. - Supported by ``vaddr`` and ``fvaddr`` operations set. + Supported by ``vaddr`` and ``fvaddr`` operations set. When + TRANSPARENT_HUGEPAGE is disabled, the application of the action will just + fail. - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``. - Supported by ``vaddr`` and ``fvaddr`` operations set. + Supported by ``vaddr`` and ``fvaddr`` operations set. When + TRANSPARENT_HUGEPAGE is disabled, the application of the action will just + fail. - ``lru_prio``: Prioritize the region on its LRU lists. Supported by ``paddr`` operations set. - ``lru_deprio``: Deprioritize the region on its LRU lists. @@ -564,6 +577,18 @@ aggressiveness (the quota) of the corresponding scheme. For example, if DAMOS is under achieving the goal, DAMOS automatically increases the quota. If DAMOS is over achieving the goal, it decreases the quota. +There are two such tuning algorithms that users can select as they need. + +- ``consist``: A proportional feedback loop based algorithm. Tries to find an + optimum quota that should be consistently kept, to keep achieving the goal. + Useful for kernel-only operation on dynamic and long-running environments. + This is the default selection. If unsure, use this. +- ``temporal``: More straightforward algorithm. Tries to achieve the goal as + fast as possible, using maximum allowed quota, but only for a temporal short + time. When the quota is under-achieved, this algorithm keeps tuning quota to + a maximum allowed one. Once the quota is [over]-achieved, this sets the + quota zero. Useful for deterministic control required environments. + The goal can be specified with five parameters, namely ``target_metric``, ``target_value``, ``current_value``, ``nid`` and ``path``. The auto-tuning mechanism tries to make ``current_value`` of ``target_metric`` be same to @@ -839,6 +864,10 @@ more detail, please read the usage documents for those (:doc:`/admin-guide/mm/damon/stat`, :doc:`/admin-guide/mm/damon/reclaim` and :doc:`/admin-guide/mm/damon/lru_sort`). +.. _damon_design_special_purpose_modules_exclusivity: + +Note that these modules currently run in an exclusive manner. If one of those +is already running, others will return ``-EBUSY`` upon start requests. Sample DAMON Modules -------------------- diff --git a/Documentation/mm/damon/index.rst b/Documentation/mm/damon/index.rst index 82f6c5eea49a..318f6a7bfea4 100644 --- a/Documentation/mm/damon/index.rst +++ b/Documentation/mm/damon/index.rst @@ -12,7 +12,7 @@ DAMON is a Linux kernel subsystem for efficient :ref:`data access monitoring - *light-weight* (for production online usages), - *scalable* (in terms of memory size), - *tunable* (for flexible usages), and - - *autoamted* (for production operation without manual tunings). + - *automated* (for production operation without manual tunings). .. toctree:: :maxdepth: 2 diff --git a/Documentation/mm/damon/maintainer-profile.rst b/Documentation/mm/damon/maintainer-profile.rst index 41b1d73b9bd7..bcb9798a27a8 100644 --- a/Documentation/mm/damon/maintainer-profile.rst +++ b/Documentation/mm/damon/maintainer-profile.rst @@ -63,10 +63,10 @@ management subsystem maintainer. Review cadence -------------- -The DAMON maintainer does the work on the usual work hour (09:00 to 17:00, -Mon-Fri) in PT (Pacific Time). The response to patches will occasionally be -slow. Do not hesitate to send a ping if you have not heard back within a week -of sending a patch. +The DAMON maintainer usually work in a flexible way, except early morning in PT +(Pacific Time). The response to patches will occasionally be slow. Do not +hesitate to send a ping if you have not heard back within a week of sending a +patch. Mailing tool ------------ diff --git a/Documentation/mm/hugetlbfs_reserv.rst b/Documentation/mm/hugetlbfs_reserv.rst index 4914fbf07966..a49115db18c7 100644 --- a/Documentation/mm/hugetlbfs_reserv.rst +++ b/Documentation/mm/hugetlbfs_reserv.rst @@ -155,7 +155,7 @@ are enough free huge pages to accommodate the reservation. If there are, the global reservation count resv_huge_pages is adjusted something like the following:: - if (resv_needed <= (resv_huge_pages - free_huge_pages)) + if (resv_needed <= (free_huge_pages - resv_huge_pages) resv_huge_pages += resv_needed; Note that the global lock hugetlb_lock is held when checking and adjusting diff --git a/Documentation/mm/hwpoison.rst b/Documentation/mm/hwpoison.rst index 483b72aa7c11..71b4b45c3505 100644 --- a/Documentation/mm/hwpoison.rst +++ b/Documentation/mm/hwpoison.rst @@ -38,7 +38,7 @@ To quote the overview comment:: for the mapping from a vma to a process. Since this case is expected to be rare we hope we can get away with this. -The code consists of a the high level handler in mm/memory-failure.c, +The code consists of the high level handler in mm/memory-failure.c, a new page poison bit and various checks in the VM to handle poisoned pages. diff --git a/Documentation/mm/numa.rst b/Documentation/mm/numa.rst index 0f1b56809dca..b765295c6e85 100644 --- a/Documentation/mm/numa.rst +++ b/Documentation/mm/numa.rst @@ -140,7 +140,7 @@ this. If the architecture supports--does not hide--memoryless nodes, then CPUs attached to memoryless nodes would always incur the fallback path overhead -or some subsystems would fail to initialize if they attempted to allocated +or some subsystems would fail to initialize if they attempted to allocate memory exclusively from a node without memory. To support such architectures transparently, kernel subsystems can use the numa_mem_id() or cpu_to_mem() function to locate the "local memory node" for the calling or diff --git a/Documentation/mm/vmemmap_dedup.rst b/Documentation/mm/vmemmap_dedup.rst index b4a55b6569fa..9fa8642ded48 100644 --- a/Documentation/mm/vmemmap_dedup.rst +++ b/Documentation/mm/vmemmap_dedup.rst @@ -24,7 +24,7 @@ For each base page, there is a corresponding ``struct page``. Within the HugeTLB subsystem, only the first 4 ``struct page`` are used to contain unique information about a HugeTLB page. ``__NR_USED_SUBPAGE`` provides this upper limit. The only 'useful' information in the remaining ``struct page`` -is the compound_head field, and this field is the same for all tail pages. +is the compound_info field, and this field is the same for all tail pages. By removing redundant ``struct page`` for HugeTLB pages, memory can be returned to the buddy allocator for other uses. @@ -124,33 +124,35 @@ Here is how things look before optimization:: | | +-----------+ -The value of page->compound_head is the same for all tail pages. The first -page of ``struct page`` (page 0) associated with the HugeTLB page contains the 4 -``struct page`` necessary to describe the HugeTLB. The only use of the remaining -pages of ``struct page`` (page 1 to page 7) is to point to page->compound_head. -Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of ``struct page`` -will be used for each HugeTLB page. This will allow us to free the remaining -7 pages to the buddy allocator. +The first page of ``struct page`` (page 0) associated with the HugeTLB page +contains the 4 ``struct page`` necessary to describe the HugeTLB. The remaining +pages of ``struct page`` (page 1 to page 7) are tail pages. + +The optimization is only applied when the size of the struct page is a power +of 2. In this case, all tail pages of the same order are identical. See +compound_head(). This allows us to remap the tail pages of the vmemmap to a +shared, read-only page. The head page is also remapped to a new page. This +allows the original vmemmap pages to be freed. Here is how things look after remapping:: - HugeTLB struct pages(8 pages) page frame(8 pages) - +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ - | | | 0 | -------------> | 0 | - | | +-----------+ +-----------+ - | | | 1 | ---------------^ ^ ^ ^ ^ ^ ^ - | | +-----------+ | | | | | | - | | | 2 | -----------------+ | | | | | - | | +-----------+ | | | | | - | | | 3 | -------------------+ | | | | - | | +-----------+ | | | | - | | | 4 | ---------------------+ | | | - | PMD | +-----------+ | | | - | level | | 5 | -----------------------+ | | - | mapping | +-----------+ | | - | | | 6 | -------------------------+ | - | | +-----------+ | - | | | 7 | ---------------------------+ + HugeTLB struct pages(8 pages) page frame (new) + +-----------+ ---virt_to_page---> +-----------+ mapping to +----------------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +----------------+ + | | | 1 | ------┐ + | | +-----------+ | + | | | 2 | ------┼ +----------------------------+ + | | +-----------+ | | A single, per-zone page | + | | | 3 | ------┼------> | frame shared among all | + | | +-----------+ | | hugepages of the same size | + | | | 4 | ------┼ +----------------------------+ + | | +-----------+ | + | | | 5 | ------┼ + | PMD | +-----------+ | + | level | | 6 | ------┼ + | mapping | +-----------+ | + | | | 7 | ------┘ | | +-----------+ | | | | @@ -172,16 +174,6 @@ The contiguous bit is used to increase the mapping size at the pmd and pte (last) level. So this type of HugeTLB page can be optimized only when its size of the ``struct page`` structs is greater than **1** page. -Notice: The head vmemmap page is not freed to the buddy allocator and all -tail vmemmap pages are mapped to the head vmemmap page frame. So we can see -more than one ``struct page`` struct with ``PG_head`` (e.g. 8 per 2 MB HugeTLB -page) associated with each HugeTLB page. The ``compound_head()`` can handle -this correctly. There is only **one** head ``struct page``, the tail -``struct page`` with ``PG_head`` are fake head ``struct page``. We need an -approach to distinguish between those two different types of ``struct page`` so -that ``compound_head()`` can return the real head ``struct page`` when the -parameter is the tail ``struct page`` but with ``PG_head``. - Device DAX ========== diff --git a/Documentation/netlink/genetlink.yaml b/Documentation/netlink/genetlink.yaml index b020a537d8ac..a1194d5d93fc 100644 --- a/Documentation/netlink/genetlink.yaml +++ b/Documentation/netlink/genetlink.yaml @@ -262,7 +262,7 @@ properties: description: Command flags. type: array items: - enum: [ admin-perm ] + enum: [ admin-perm, uns-admin-perm ] dont-validate: description: Kernel attribute validation flags. type: array diff --git a/Documentation/netlink/netlink-raw.yaml b/Documentation/netlink/netlink-raw.yaml index 0166a7e4afbb..dd98dda55bd0 100644 --- a/Documentation/netlink/netlink-raw.yaml +++ b/Documentation/netlink/netlink-raw.yaml @@ -19,6 +19,12 @@ $defs: type: [ string, integer ] pattern: ^[0-9A-Za-z_-]+( - 1)?$ minimum: 0 + len-or-limit: + # literal int, const name, or limit based on fixed-width type + # e.g. u8-min, u16-max, etc. + type: [ string, integer ] + pattern: ^[0-9A-Za-z_-]+$ + minimum: 0 # Schema for specs title: Protocol @@ -270,7 +276,10 @@ properties: type: string min: description: Min value for an integer attribute. - type: integer + $ref: '#/$defs/len-or-limit' + max: + description: Max value for an integer attribute. + $ref: '#/$defs/len-or-limit' min-len: description: Min length for a binary attribute. $ref: '#/$defs/len-or-define' diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml index 837112da6738..247b147d689f 100644 --- a/Documentation/netlink/specs/devlink.yaml +++ b/Documentation/netlink/specs/devlink.yaml @@ -159,6 +159,14 @@ definitions: name: entry - type: enum + name: resource-scope + entries: + - + name: dev + - + name: port + - + type: enum name: reload-action entries: - @@ -867,6 +875,22 @@ attribute-sets: type: flag doc: Request restoring parameter to its default value. value: 183 + - + name: index + type: uint + doc: Unique devlink instance index. + checks: + max: u32-max + - + name: resource-scope-mask + type: u32 + enum: resource-scope + enum-as-flags: true + doc: | + Bitmask selecting which resource classes to include in a + resource-dump response. Bit 0 (dev) selects device-level + resources; bit 1 (port) selects port-level resources. + When absent all classes are returned. - name: dl-dev-stats subset-of: devlink @@ -1306,11 +1330,13 @@ operations: attributes: &dev-id-attrs - bus-name - dev-name + - index reply: &get-reply value: 3 attributes: - bus-name - dev-name + - index - reload-failed - dev-stats dump: @@ -1329,6 +1355,7 @@ operations: attributes: &port-id-attrs - bus-name - dev-name + - index - port-index reply: value: 7 @@ -1353,6 +1380,7 @@ operations: attributes: - bus-name - dev-name + - index - port-index - port-type - port-function @@ -1370,6 +1398,7 @@ operations: attributes: - bus-name - dev-name + - index - port-index - port-flavour - port-pci-pf-number @@ -1404,6 +1433,7 @@ operations: attributes: - bus-name - dev-name + - index - port-index - port-split-count @@ -1432,6 +1462,7 @@ operations: attributes: &sb-id-attrs - bus-name - dev-name + - index - sb-index reply: &sb-get-reply value: 13 @@ -1454,6 +1485,7 @@ operations: attributes: &sb-pool-id-attrs - bus-name - dev-name + - index - sb-index - sb-pool-index reply: &sb-pool-get-reply @@ -1477,6 +1509,7 @@ operations: attributes: - bus-name - dev-name + - index - sb-index - sb-pool-index - sb-pool-threshold-type @@ -1495,6 +1528,7 @@ operations: attributes: &sb-port-pool-id-attrs - bus-name - dev-name + - index - port-index - sb-index - sb-pool-index @@ -1519,6 +1553,7 @@ operations: attributes: - bus-name - dev-name + - index - port-index - sb-index - sb-pool-index @@ -1537,6 +1572,7 @@ operations: attributes: &sb-tc-pool-bind-id-attrs - bus-name - dev-name + - index - port-index - sb-index - sb-pool-type @@ -1562,6 +1598,7 @@ operations: attributes: - bus-name - dev-name + - index - port-index - sb-index - sb-pool-index @@ -1583,6 +1620,7 @@ operations: attributes: - bus-name - dev-name + - index - sb-index - @@ -1598,6 +1636,7 @@ operations: attributes: - bus-name - dev-name + - index - sb-index - @@ -1616,6 +1655,7 @@ operations: attributes: &eswitch-attrs - bus-name - dev-name + - index - eswitch-mode - eswitch-inline-mode - eswitch-encap-mode @@ -1644,12 +1684,14 @@ operations: attributes: - bus-name - dev-name + - index - dpipe-table-name reply: value: 31 attributes: - bus-name - dev-name + - index - dpipe-tables - @@ -1664,11 +1706,13 @@ operations: attributes: - bus-name - dev-name + - index - dpipe-table-name reply: attributes: - bus-name - dev-name + - index - dpipe-entries - @@ -1683,10 +1727,12 @@ operations: attributes: - bus-name - dev-name + - index reply: attributes: - bus-name - dev-name + - index - dpipe-headers - @@ -1702,6 +1748,7 @@ operations: attributes: - bus-name - dev-name + - index - dpipe-table-name - dpipe-table-counters-enabled @@ -1718,6 +1765,7 @@ operations: attributes: - bus-name - dev-name + - index - resource-id - resource-size @@ -1727,18 +1775,30 @@ operations: attribute-set: devlink dont-validate: [strict] do: - pre: devlink-nl-pre-doit + pre: devlink-nl-pre-doit-port-optional post: devlink-nl-post-doit request: attributes: - bus-name - dev-name - reply: + - index + - port-index + reply: &resource-dump-reply value: 36 attributes: - bus-name - dev-name + - index + - port-index - resource-list + dump: + request: + attributes: + - bus-name + - dev-name + - index + - resource-scope-mask + reply: *resource-dump-reply - name: reload @@ -1753,6 +1813,7 @@ operations: attributes: - bus-name - dev-name + - index - reload-action - reload-limits - netns-pid @@ -1762,6 +1823,7 @@ operations: attributes: - bus-name - dev-name + - index - reload-actions-performed - @@ -1776,6 +1838,7 @@ operations: attributes: ¶m-id-attrs - bus-name - dev-name + - index - param-name reply: ¶m-get-reply attributes: *param-id-attrs @@ -1797,6 +1860,7 @@ operations: attributes: - bus-name - dev-name + - index - param-name - param-type # param-value-data is missing here as the type is variable @@ -1816,6 +1880,7 @@ operations: attributes: ®ion-id-attrs - bus-name - dev-name + - index - port-index - region-name reply: ®ion-get-reply @@ -1840,6 +1905,7 @@ operations: attributes: ®ion-snapshot-id-attrs - bus-name - dev-name + - index - port-index - region-name - region-snapshot-id @@ -1870,6 +1936,7 @@ operations: attributes: - bus-name - dev-name + - index - port-index - region-name - region-snapshot-id @@ -1881,6 +1948,7 @@ operations: attributes: - bus-name - dev-name + - index - port-index - region-name @@ -1930,6 +1998,7 @@ operations: attributes: - bus-name - dev-name + - index - info-driver-name - info-serial-number - info-version-fixed @@ -1951,6 +2020,7 @@ operations: attributes: &health-reporter-id-attrs - bus-name - dev-name + - index - port-index - health-reporter-name reply: &health-reporter-get-reply @@ -1973,6 +2043,7 @@ operations: attributes: - bus-name - dev-name + - index - port-index - health-reporter-name - health-reporter-graceful-period @@ -2043,6 +2114,7 @@ operations: attributes: - bus-name - dev-name + - index - flash-update-file-name - flash-update-component - flash-update-overwrite-mask @@ -2060,6 +2132,7 @@ operations: attributes: &trap-id-attrs - bus-name - dev-name + - index - trap-name reply: &trap-get-reply value: 63 @@ -2082,6 +2155,7 @@ operations: attributes: - bus-name - dev-name + - index - trap-name - trap-action @@ -2098,6 +2172,7 @@ operations: attributes: &trap-group-id-attrs - bus-name - dev-name + - index - trap-group-name reply: &trap-group-get-reply value: 67 @@ -2120,6 +2195,7 @@ operations: attributes: - bus-name - dev-name + - index - trap-group-name - trap-action - trap-policer-id @@ -2137,6 +2213,7 @@ operations: attributes: &trap-policer-id-attrs - bus-name - dev-name + - index - trap-policer-id reply: &trap-policer-get-reply value: 71 @@ -2159,6 +2236,7 @@ operations: attributes: - bus-name - dev-name + - index - trap-policer-id - trap-policer-rate - trap-policer-burst @@ -2189,6 +2267,7 @@ operations: attributes: &rate-id-attrs - bus-name - dev-name + - index - port-index - rate-node-name reply: &rate-get-reply @@ -2212,6 +2291,7 @@ operations: attributes: - bus-name - dev-name + - index - rate-node-name - rate-tx-share - rate-tx-max @@ -2233,6 +2313,7 @@ operations: attributes: - bus-name - dev-name + - index - rate-node-name - rate-tx-share - rate-tx-max @@ -2254,6 +2335,7 @@ operations: attributes: - bus-name - dev-name + - index - rate-node-name - @@ -2269,6 +2351,7 @@ operations: attributes: &linecard-id-attrs - bus-name - dev-name + - index - linecard-index reply: &linecard-get-reply value: 80 @@ -2291,6 +2374,7 @@ operations: attributes: - bus-name - dev-name + - index - linecard-index - linecard-type @@ -2324,6 +2408,7 @@ operations: attributes: - bus-name - dev-name + - index - selftests - @@ -2335,4 +2420,5 @@ operations: attributes: - bus-name - dev-name + - index - port-index diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml index 3dd48a32f783..40465a3d7fc2 100644 --- a/Documentation/netlink/specs/dpll.yaml +++ b/Documentation/netlink/specs/dpll.yaml @@ -241,6 +241,20 @@ definitions: Value of (DPLL_A_PHASE_OFFSET % DPLL_PHASE_OFFSET_DIVIDER) is a fractional part of a measured phase offset value. - + type: const + name: pin-measured-frequency-divider + value: 1000 + doc: | + pin measured frequency divider allows userspace to calculate + a value of measured input frequency as a fractional value with + three digit decimal precision (millihertz). + Value of (DPLL_A_PIN_MEASURED_FREQUENCY / + DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is an integer part of + a measured frequency value. + Value of (DPLL_A_PIN_MEASURED_FREQUENCY % + DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part of + a measured frequency value. + - type: enum name: feature-state doc: | @@ -319,6 +333,13 @@ attribute-sets: name: phase-offset-avg-factor type: u32 doc: Averaging factor applied to calculation of reported phase offset. + - + name: frequency-monitor + type: u32 + enum: feature-state + doc: Current or desired state of the frequency monitor feature. + If enabled, dpll device shall measure all currently available + inputs for their actual input frequency. - name: pin enum-name: dpll_a_pin @@ -456,6 +477,17 @@ attribute-sets: Value is in PPT (parts per trillion, 10^-12). Note: This attribute provides higher resolution than the standard fractional-frequency-offset (which is in PPM). + - + name: measured-frequency + type: u64 + doc: | + The measured frequency of the input pin in millihertz (mHz). + Value of (DPLL_A_PIN_MEASURED_FREQUENCY / + DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is an integer part (Hz) + of a measured frequency value. + Value of (DPLL_A_PIN_MEASURED_FREQUENCY % + DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part + of a measured frequency value. - name: pin-parent-device @@ -544,6 +576,7 @@ operations: - type - phase-offset-monitor - phase-offset-avg-factor + - frequency-monitor dump: reply: *dev-attrs @@ -563,6 +596,7 @@ operations: - mode - phase-offset-monitor - phase-offset-avg-factor + - frequency-monitor - name: device-create-ntf doc: Notification about device appearing @@ -643,6 +677,7 @@ operations: - esync-frequency-supported - esync-pulse - reference-sync + - measured-frequency dump: request: diff --git a/Documentation/netlink/specs/drm_ras.yaml b/Documentation/netlink/specs/drm_ras.yaml new file mode 100644 index 000000000000..79af25dac3c5 --- /dev/null +++ b/Documentation/netlink/specs/drm_ras.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) +--- +name: drm-ras +protocol: genetlink +uapi-header: drm/drm_ras.h + +doc: >- + DRM RAS (Reliability, Availability, Serviceability) over Generic Netlink. + Provides a standardized mechanism for DRM drivers to register "nodes" + representing hardware/software components capable of reporting error counters. + Userspace tools can query the list of nodes or individual error counters + via the Generic Netlink interface. + +definitions: + - + type: enum + name: node-type + value-start: 1 + entries: [error-counter] + doc: >- + Type of the node. Currently, only error-counter nodes are + supported, which expose reliability counters for a hardware/software + component. + +attribute-sets: + - + name: node-attrs + attributes: + - + name: node-id + type: u32 + doc: >- + Unique identifier for the node. + Assigned dynamically by the DRM RAS core upon registration. + - + name: device-name + type: string + doc: >- + Device name chosen by the driver at registration. + Can be a PCI BDF, UUID, or module name if unique. + - + name: node-name + type: string + doc: >- + Node name chosen by the driver at registration. + Can be an IP block name, or any name that identifies the + RAS node inside the device. + - + name: node-type + type: u32 + doc: Type of this node, identifying its function. + enum: node-type + - + name: error-counter-attrs + attributes: + - + name: node-id + type: u32 + doc: Node ID targeted by this error counter operation. + - + name: error-id + type: u32 + doc: Unique identifier for a specific error counter within an node. + - + name: error-name + type: string + doc: Name of the error. + - + name: error-value + type: u32 + doc: Current value of the requested error counter. + +operations: + list: + - + name: list-nodes + doc: >- + Retrieve the full list of currently registered DRM RAS nodes. + Each node includes its dynamically assigned ID, name, and type. + **Important:** User space must call this operation first to obtain + the node IDs. These IDs are required for all subsequent + operations on nodes, such as querying error counters. + attribute-set: node-attrs + flags: [admin-perm] + dump: + reply: + attributes: + - node-id + - device-name + - node-name + - node-type + - + name: get-error-counter + doc: >- + Retrieve error counter for a given node. + The response includes the id, the name, and even the current + value of each counter. + attribute-set: error-counter-attrs + flags: [admin-perm] + do: + request: + attributes: + - node-id + - error-id + reply: + attributes: &errorinfo + - error-id + - error-name + - error-value + dump: + request: + attributes: + - node-id + reply: + attributes: *errorinfo diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml index 0a2d2343f79a..5dd4d1b5d94b 100644 --- a/Documentation/netlink/specs/ethtool.yaml +++ b/Documentation/netlink/specs/ethtool.yaml @@ -311,10 +311,6 @@ attribute-sets: type: unused value: 0 - - name: unspec - type: unused - value: 0 - - name: string type: nest multi-attr: true @@ -861,6 +857,12 @@ attribute-sets: name: tx-profile type: nest nested-attributes: profile + - + name: rx-cqe-frames + type: u32 + - + name: rx-cqe-nsecs + type: u32 - name: pause-stat @@ -879,6 +881,19 @@ attribute-sets: - name: rx-frames type: u64 + - + name: tx-pause-storm-events + type: u64 + doc: >- + TX pause storm event count. Increments each time device + detects that its pause assertion condition has been true + for too long for normal operation. As a result, the device + has temporarily disabled its own Pause TX function to + protect the network from itself. + This counter should never increment under normal overload + conditions; it indicates catastrophic failure like an OS + crash. The rate of incrementing is implementation specific. + - name: pause attr-cnt-name: __ethtool-a-pause-cnt @@ -2244,6 +2259,8 @@ operations: - tx-aggr-time-usecs - rx-profile - tx-profile + - rx-cqe-frames + - rx-cqe-nsecs dump: *coalesce-get-op - name: coalesce-set diff --git a/Documentation/netlink/specs/netdev.yaml b/Documentation/netlink/specs/netdev.yaml index 596c306ce52b..b93beb247a11 100644 --- a/Documentation/netlink/specs/netdev.yaml +++ b/Documentation/netlink/specs/netdev.yaml @@ -339,6 +339,15 @@ attribute-sets: doc: XSK information for this queue, if any. type: nest nested-attributes: xsk-info + - + name: lease + doc: | + A queue from a virtual device can have a lease which refers to + another queue from a physical device. This is useful for memory + providers and AF_XDP operations which take an ifindex and queue id + to allow applications to bind against virtual devices in containers. + type: nest + nested-attributes: lease - name: qstats doc: | @@ -538,6 +547,26 @@ attribute-sets: - name: type - + name: lease + attributes: + - + name: ifindex + doc: The netdev ifindex to lease the queue from. + type: u32 + checks: + min: 1 + - + name: queue + doc: The netdev queue to lease from. + type: nest + nested-attributes: queue-id + - + name: netns-id + doc: The network namespace id of the netdev. + type: s32 + checks: + min: 0 + - name: dmabuf attributes: - @@ -686,6 +715,7 @@ operations: - dmabuf - io-uring - xsk + - lease dump: request: attributes: @@ -797,6 +827,22 @@ operations: reply: attributes: - id + - + name: queue-create + doc: | + Create a new queue for the given netdevice. Whether this operation + is supported depends on the device and the driver. + attribute-set: queue + flags: [admin-perm] + do: + request: + attributes: + - ifindex + - type + - lease + reply: &queue-create-op + attributes: + - id kernel-family: headers: ["net/netdev_netlink.h"] diff --git a/Documentation/netlink/specs/nfsd.yaml b/Documentation/netlink/specs/nfsd.yaml index f87b5a05e5e9..8ab43c8253b2 100644 --- a/Documentation/netlink/specs/nfsd.yaml +++ b/Documentation/netlink/specs/nfsd.yaml @@ -81,6 +81,11 @@ attribute-sets: - name: min-threads type: u32 + - + name: fh-key + type: binary + checks: + exact-len: 16 - name: version attributes: @@ -163,6 +168,7 @@ operations: - leasetime - scope - min-threads + - fh-key - name: threads-get doc: get the maximum number of running threads diff --git a/Documentation/netlink/specs/nftables.yaml b/Documentation/netlink/specs/nftables.yaml index 17ad707fa0d5..21edf3d25f34 100644 --- a/Documentation/netlink/specs/nftables.yaml +++ b/Documentation/netlink/specs/nftables.yaml @@ -66,9 +66,21 @@ definitions: name: bitwise-ops type: enum entries: - - bool - - lshift - - rshift + - + name: mask-xor # aka bool (old name) + doc: >- + mask-and-xor operation used to implement NOT, AND, OR and XOR boolean + operations + - + name: lshift + - + name: rshift + - + name: and + - + name: or + - + name: xor - name: cmp-ops type: enum @@ -133,6 +145,12 @@ definitions: - concat - expr - + name: set-elem-flags + type: flags + entries: + - interval-end + - catchall + - name: lookup-flags type: flags entries: @@ -225,19 +243,244 @@ definitions: - icmp-unreach - tcp-rst - icmpx-unreach + - + name: reject-inet-code + doc: These codes are mapped to real ICMP and ICMPv6 codes. + type: enum + entries: + - icmpx-no-route + - icmpx-port-unreach + - icmpx-host-unreach + - icmpx-admin-prohibited + - + name: payload-base + type: enum + entries: + - link-layer-header + - network-header + - transport-header + - inner-header + - tun-header + - + name: range-ops + doc: Range operator + type: enum + entries: + - eq + - neq + - + name: registers + doc: | + nf_tables registers. + nf_tables used to have five registers: a verdict register and four data + registers of size 16. The data registers have been changed to 16 registers + of size 4. For compatibility reasons, the NFT_REG_[1-4] registers still + map to areas of size 16, the 4 byte registers are addressed using + NFT_REG32_00 - NFT_REG32_15. + type: enum + entries: + - + name: reg-verdict + - + name: reg-1 + - + name: reg-2 + - + name: reg-3 + - + name: reg-4 + - + name: reg32-00 + value: 8 + - + name: reg32-01 + - + name: reg32-02 + - + name: reg32-03 + - + name: reg32-04 + - + name: reg32-05 + - + name: reg32-06 + - + name: reg32-07 + - + name: reg32-08 + - + name: reg32-09 + - + name: reg32-10 + - + name: reg32-11 + - + name: reg32-12 + - + name: reg32-13 + - + name: reg32-14 + - + name: reg32-15 + - + name: numgen-types + type: enum + entries: + - incremental + - random + - + name: log-level + doc: nf_tables log levels + type: enum + entries: + - + name: emerg + doc: system is unusable + - + name: alert + doc: action must be taken immediately + - + name: crit + doc: critical conditions + - + name: err + doc: error conditions + - + name: warning + doc: warning conditions + - + name: notice + doc: normal but significant condition + - + name: info + doc: informational + - + name: debug + doc: debug-level messages + - + name: audit + doc: enabling audit logging + - + name: log-flags + doc: nf_tables log flags + header: linux/netfilter/nf_log.h + type: flags + entries: + - + name: tcpseq + doc: Log TCP sequence numbers + - + name: tcpopt + doc: Log TCP options + - + name: ipopt + doc: Log IP options + - + name: uid + doc: Log UID owning local socket + - + name: nflog + doc: Unsupported, don't reuse + - + name: macdecode + doc: Decode MAC header attribute-sets: - - name: empty-attrs + name: log-attrs + doc: log expression netlink attributes attributes: + # Mentioned in nft_log_init() - - name: name + name: group + doc: netlink group to send messages to + type: u16 + byte-order: big-endian + - + name: prefix + doc: prefix to prepend to log messages type: string + - + name: snaplen + doc: length of payload to include in netlink message + type: u32 + byte-order: big-endian + - + name: qthreshold + doc: queue threshold + type: u16 + byte-order: big-endian + - + name: level + doc: log level + type: u32 + enum: log-level + byte-order: big-endian + - + name: flags + doc: logging flags + type: u32 + enum: log-flags + byte-order: big-endian + - + name: numgen-attrs + doc: nf_tables number generator expression netlink attributes + attributes: + - + name: dreg + doc: destination register + type: u32 + enum: registers + - + name: modulus + doc: maximum counter value + type: u32 + byte-order: big-endian + - + name: type + doc: operation type + type: u32 + byte-order: big-endian + enum: numgen-types + - + name: offset + doc: offset to be added to the counter + type: u32 + byte-order: big-endian + - + name: range-attrs + attributes: + # Mentioned in net/netfilter/nft_range.c + - + name: sreg + doc: source register of data to compare + type: u32 + byte-order: big-endian + enum: registers + - + name: op + doc: cmp operation + type: u32 + byte-order: big-endian + enum: range-ops + checks: + max: 255 + - + name: from-data + doc: data range from + type: nest + nested-attributes: data-attrs + - + name: to-data + doc: data range to + type: nest + nested-attributes: data-attrs - name: batch-attrs attributes: - name: genid + doc: generation ID for this changeset type: u32 byte-order: big-endian - @@ -265,9 +508,17 @@ attribute-sets: byte-order: big-endian doc: numeric handle of the table - + name: pad + type: pad + - name: userdata type: binary doc: user data + - + name: owner + type: u32 + byte-order: big-endian + doc: owner of this table through netlink portID - name: chain-attrs attributes: @@ -371,9 +622,11 @@ attribute-sets: - name: bytes type: u64 + byte-order: big-endian - name: packets type: u64 + byte-order: big-endian - name: rule-attrs attributes: @@ -443,15 +696,18 @@ attribute-sets: selector: name doc: type specific data - + # Mentioned in nft_parse_compat() in net/netfilter/nft_compat.c name: rule-compat-attrs attributes: - name: proto - type: binary + type: u32 + byte-order: big-endian doc: numeric value of the handled protocol - name: flags - type: binary + type: u32 + byte-order: big-endian doc: bitmask of flags - name: set-attrs @@ -540,6 +796,15 @@ attribute-sets: type: nest nested-attributes: set-list-attrs doc: list of expressions + - + name: type + type: string + doc: set backend type + - + name: count + type: u32 + byte-order: big-endian + doc: number of set elements - name: set-desc-attrs attributes: @@ -767,6 +1032,22 @@ attribute-sets: nested-attributes: hook-dev-attrs - name: expr-bitwise-attrs + doc: | + The bitwise expression supports boolean and shift operations. It + implements the boolean operations by performing the following + operation:: + + dreg = (sreg & mask) ^ xor + + with these mask and xor values: + + op mask xor + ---- ---- --- + NOT: 1 1 + OR: ~x x + XOR: 1 x + AND: x 0 + attributes: - name: sreg @@ -793,6 +1074,8 @@ attribute-sets: type: u32 byte-order: big-endian enum: bitwise-ops + checks: + max: 255 - name: data type: nest @@ -829,25 +1112,31 @@ attribute-sets: attributes: - name: code + doc: nf_tables verdict type: u32 byte-order: big-endian enum: verdict-code - name: chain + doc: jump target chain name type: string - name: chain-id + doc: jump target chain ID type: u32 + byte-order: big-endian - name: expr-counter-attrs attributes: - name: bytes type: u64 + byte-order: big-endian doc: Number of bytes - name: packets type: u64 + byte-order: big-endian doc: Number of packets - name: pad @@ -933,6 +1222,25 @@ attribute-sets: byte-order: big-endian enum: lookup-flags - + name: expr-masq-attrs + attributes: + - + name: flags + type: u32 + byte-order: big-endian + enum: nat-range-flags + enum-as-flags: true + - + name: reg-proto-min + type: u32 + byte-order: big-endian + enum: registers + - + name: reg-proto-max + type: u32 + byte-order: big-endian + enum: registers + - name: expr-meta-attrs attributes: - @@ -983,37 +1291,49 @@ attribute-sets: enum-as-flags: true - name: expr-payload-attrs + doc: nf_tables payload expression netlink attributes attributes: - name: dreg + doc: destination register to load data into type: u32 byte-order: big-endian + enum: registers - name: base + doc: payload base type: u32 + enum: payload-base byte-order: big-endian - name: offset + doc: payload offset relative to base type: u32 byte-order: big-endian - name: len + doc: payload length type: u32 byte-order: big-endian - name: sreg + doc: source register to load data from type: u32 byte-order: big-endian + enum: registers - name: csum-type + doc: checksum type type: u32 byte-order: big-endian - name: csum-offset + doc: checksum offset relative to base type: u32 byte-order: big-endian - name: csum-flags + doc: checksum flags type: u32 byte-order: big-endian - @@ -1079,6 +1399,61 @@ attribute-sets: type: u32 byte-order: big-endian doc: id of object map + - + name: compat-target-attrs + header: linux/netfilter/nf_tables_compat.h + attributes: + - + name: name + type: string + checks: + max-len: 32 + - + name: rev + type: u32 + byte-order: big-endian + checks: + max: 255 + - + name: info + type: binary + - + name: compat-match-attrs + header: linux/netfilter/nf_tables_compat.h + attributes: + - + name: name + type: string + checks: + max-len: 32 + - + name: rev + type: u32 + byte-order: big-endian + checks: + max: 255 + - + name: info + type: binary + - + name: compat-attrs + header: linux/netfilter/nf_tables_compat.h + attributes: + - + name: name + type: string + checks: + max-len: 32 + - + name: rev + type: u32 + byte-order: big-endian + checks: + max: 255 + - + name: type + type: u32 + byte-order: big-endian sub-messages: - @@ -1106,15 +1481,24 @@ sub-messages: value: immediate attribute-set: expr-immediate-attrs - + value: log + attribute-set: log-attrs + - value: lookup attribute-set: expr-lookup-attrs - + value: match + attribute-set: compat-match-attrs + - value: meta attribute-set: expr-meta-attrs - value: nat attribute-set: expr-nat-attrs - + value: numgen + attribute-set: numgen-attrs + - value: objref attribute-set: expr-objref-attrs - @@ -1124,6 +1508,9 @@ sub-messages: value: quota attribute-set: quota-attrs - + value: range + attribute-set: range-attrs + - value: reject attribute-set: expr-reject-attrs - @@ -1132,6 +1519,9 @@ sub-messages: - value: tproxy attribute-set: expr-tproxy-attrs + # There're more sub-messages to go: + # grep -A10 nft_expr_type + # and look for .name\s*=\s*"..." - name: obj-data formats: @@ -1178,7 +1568,10 @@ operations: request: value: 0xa00 attributes: + # Mentioned in nf_tables_newtable() - name + - flags + - userdata - name: gettable doc: Get / dump tables. @@ -1188,11 +1581,21 @@ operations: request: value: 0xa01 attributes: + # Mentioned in nf_tables_gettable() - name reply: value: 0xa00 - attributes: + attributes: &get-table + # Mentioned in nf_tables_fill_table_info() - name + - use + - handle + - flags + - owner + - userdata + dump: + reply: + attributes: *get-table - name: deltable doc: Delete an existing table. @@ -1201,8 +1604,10 @@ operations: do: request: value: 0xa02 - attributes: + attributes: &del-table + # Mentioned in nf_tables_deltable() - name + - handle - name: destroytable doc: | @@ -1213,8 +1618,7 @@ operations: do: request: value: 0xa1a - attributes: - - name + attributes: *del-table - name: newchain doc: Create a new chain. @@ -1224,7 +1628,19 @@ operations: request: value: 0xa03 attributes: + # Mentioned in nf_tables_newchain() + - table + - handle + - policy + - flags + # Mentioned in nf_tables_updchain() + - hook - name + - counters + # Mentioned in nf_tables_addchain() + - userdata + # Mentioned in nft_chain_parse_hook() + - type - name: getchain doc: Get / dump chains. @@ -1234,11 +1650,27 @@ operations: request: value: 0xa04 attributes: + # Mentioned in nf_tables_getchain() + - table - name reply: value: 0xa03 - attributes: + attributes: &get-chain + # Mentioned in nf_tables_fill_chain_info() + - table - name + - handle + - hook + - policy + - type + - flags + - counters + - id + - use + - userdata + dump: + reply: + attributes: *get-chain - name: delchain doc: Delete an existing chain. @@ -1247,8 +1679,12 @@ operations: do: request: value: 0xa05 - attributes: + attributes: &del-chain + # Mentioned in nf_tables_delchain() + - table + - handle - name + - hook - name: destroychain doc: | @@ -1259,8 +1695,7 @@ operations: do: request: value: 0xa1b - attributes: - - name + attributes: *del-chain - name: newrule doc: Create a new rule. @@ -1270,7 +1705,16 @@ operations: request: value: 0xa06 attributes: - - name + # Mentioned in nf_tables_newrule() + - table + - chain + - chain-id + - handle + - position + - position-id + - expressions + - userdata + - compat - name: getrule doc: Get / dump rules. @@ -1279,12 +1723,30 @@ operations: do: request: value: 0xa07 - attributes: - - name + attributes: &get-rule-request + # Mentioned in nf_tables_getrule_single() + - table + - chain + - handle reply: value: 0xa06 + attributes: &get-rule + # Mentioned in nf_tables_fill_rule_info() + - table + - chain + - handle + - position + - expressions + - userdata + dump: + request: attributes: - - name + # Mentioned in nf_tables_dump_rules_start() + - table + - chain + reply: + attributes: *get-rule + - name: getrule-reset doc: Get / dump rules and reset stateful expressions. @@ -1293,12 +1755,15 @@ operations: do: request: value: 0xa19 - attributes: - - name + attributes: *get-rule-request reply: value: 0xa06 - attributes: - - name + attributes: *get-rule + dump: + request: + attributes: *get-rule-request + reply: + attributes: *get-rule - name: delrule doc: Delete an existing rule. @@ -1307,8 +1772,11 @@ operations: do: request: value: 0xa08 - attributes: - - name + attributes: &del-rule + - table + - chain + - handle + - id - name: destroyrule doc: | @@ -1318,8 +1786,7 @@ operations: do: request: value: 0xa1c - attributes: - - name + attributes: *del-rule - name: newset doc: Create a new set. @@ -1329,7 +1796,21 @@ operations: request: value: 0xa09 attributes: + # Mentioned in nf_tables_newset() + - table - name + - key-len + - id + - key-type + - flags + - data-type + - data-len + - obj-type + - timeout + - gc-interval + - policy + - desc + - userdata - name: getset doc: Get / dump sets. @@ -1339,11 +1820,35 @@ operations: request: value: 0xa0a attributes: + # Mentioned in nf_tables_getset() + - table - name reply: value: 0xa09 - attributes: + attributes: &get-set + # Mentioned in nf_tables_fill_set() + - table - name + - handle + - flags + - key-len + - key-type + - data-type + - data-len + - obj-type + - gc-interval + - policy + - userdata + - desc + - expr + - expressions + dump: + request: + attributes: + # Mentioned in nf_tables_getset() + - table + reply: + attributes: *get-set - name: delset doc: Delete an existing set. @@ -1352,7 +1857,10 @@ operations: do: request: value: 0xa0b - attributes: + attributes: &del-set + # Mentioned in nf_tables_delset() + - table + - handle - name - name: destroyset @@ -1363,8 +1871,7 @@ operations: do: request: value: 0xa1d - attributes: - - name + attributes: *del-set - name: newsetelem doc: Create a new set element. @@ -1374,7 +1881,11 @@ operations: request: value: 0xa0c attributes: - - name + # Mentioned in nf_tables_newsetelem() + - table + - set + - set-id + - elements - name: getsetelem doc: Get / dump set elements. @@ -1384,11 +1895,27 @@ operations: request: value: 0xa0d attributes: - - name + # Mentioned in nf_tables_getsetelem() + - table + - set + - elements reply: value: 0xa0c attributes: - - name + # Mentioned in nf_tables_fill_setelem_info() + - elements + dump: + request: + attributes: &dump-set-request + # Mentioned in nft_set_dump_ctx_init() + - table + - set + reply: + attributes: &dump-set + # Mentioned in nf_tables_dump_set() + - table + - set + - elements - name: getsetelem-reset doc: Get / dump set elements and reset stateful expressions. @@ -1398,11 +1925,20 @@ operations: request: value: 0xa21 attributes: - - name + # Mentioned in nf_tables_getsetelem_reset() + - elements reply: value: 0xa0c attributes: - - name + # Mentioned in nf_tables_dumpreset_set() + - table + - set + - elements + dump: + request: + attributes: *dump-set-request + reply: + attributes: *dump-set - name: delsetelem doc: Delete an existing set element. @@ -1411,8 +1947,11 @@ operations: do: request: value: 0xa0e - attributes: - - name + attributes: &del-setelem + # Mentioned in nf_tables_delsetelem() + - table + - set + - elements - name: destroysetelem doc: Delete an existing set element with destroy semantics. @@ -1421,8 +1960,7 @@ operations: do: request: value: 0xa1e - attributes: - - name + attributes: *del-setelem - name: getgen doc: Get / dump rule-set generation. @@ -1431,12 +1969,16 @@ operations: do: request: value: 0xa10 - attributes: - - name reply: value: 0xa0f - attributes: - - name + attributes: &get-gen + # Mentioned in nf_tables_fill_gen_info() + - id + - proc-pid + - proc-name + dump: + reply: + attributes: *get-gen - name: newobj doc: Create a new stateful object. @@ -1446,7 +1988,12 @@ operations: request: value: 0xa12 attributes: + # Mentioned in nf_tables_newobj() + - type - name + - data + - table + - userdata - name: getobj doc: Get / dump stateful objects. @@ -1456,11 +2003,29 @@ operations: request: value: 0xa13 attributes: + # Mentioned in nf_tables_getobj_single() - name + - type + - table reply: value: 0xa12 - attributes: + attributes: &obj-info + # Mentioned in nf_tables_fill_obj_info() + - table - name + - type + - handle + - use + - data + - userdata + dump: + request: + attributes: + # Mentioned in nf_tables_dump_obj_start() + - table + - type + reply: + attributes: *obj-info - name: delobj doc: Delete an existing stateful object. @@ -1470,7 +2035,11 @@ operations: request: value: 0xa14 attributes: + # Mentioned in nf_tables_delobj() + - table - name + - type + - handle - name: destroyobj doc: Delete an existing stateful object with destroy semantics. @@ -1480,7 +2049,11 @@ operations: request: value: 0xa1f attributes: + # Mentioned in nf_tables_delobj() + - table - name + - type + - handle - name: newflowtable doc: Create a new flow table. @@ -1490,7 +2063,11 @@ operations: request: value: 0xa16 attributes: + # Mentioned in nf_tables_newflowtable() + - table - name + - hook + - flags - name: getflowtable doc: Get / dump flow tables. @@ -1500,11 +2077,22 @@ operations: request: value: 0xa17 attributes: + # Mentioned in nf_tables_getflowtable() - name + - table reply: value: 0xa16 - attributes: + attributes: &flowtable-info + # Mentioned in nf_tables_fill_flowtable_info() + - table - name + - handle + - use + - flags + - hook + dump: + reply: + attributes: *flowtable-info - name: delflowtable doc: Delete an existing flow table. @@ -1513,8 +2101,12 @@ operations: do: request: value: 0xa18 - attributes: + attributes: &del-flowtable + # Mentioned in nf_tables_delflowtable() + - table - name + - handle + - hook - name: destroyflowtable doc: Delete an existing flow table with destroy semantics. @@ -1523,8 +2115,7 @@ operations: do: request: value: 0xa20 - attributes: - - name + attributes: *del-flowtable mcast-groups: list: diff --git a/Documentation/netlink/specs/ovpn.yaml b/Documentation/netlink/specs/ovpn.yaml index 1b91045cee2e..b0c782e59a32 100644 --- a/Documentation/netlink/specs/ovpn.yaml +++ b/Documentation/netlink/specs/ovpn.yaml @@ -43,7 +43,8 @@ attribute-sets: type: u32 doc: >- The unique ID of the peer in the device context. To be used to - identify peers during operations for a specific device + identify peers during operations for a specific device. + Also used to match packets received from this peer. checks: max: 0xFFFFFF - @@ -160,6 +161,16 @@ attribute-sets: name: link-tx-packets type: uint doc: Number of packets transmitted at the transport level + - + name: tx-id + type: u32 + doc: >- + The ID value used when transmitting packets to this peer. This + way outgoing packets can have a different ID than incoming ones. + Useful in multipeer-to-multipeer connections, where each peer + will advertise the tx-id to be used on the link. + checks: + max: 0xFFFFFF - name: peer-new-input subset-of: peer @@ -188,6 +199,8 @@ attribute-sets: name: keepalive-interval - name: keepalive-timeout + - + name: tx-id - name: peer-set-input subset-of: peer @@ -214,6 +227,8 @@ attribute-sets: name: keepalive-interval - name: keepalive-timeout + - + name: tx-id - name: peer-del-input subset-of: peer @@ -502,6 +517,12 @@ operations: - ifindex - keyconf + - + name: peer-float-ntf + doc: Notification about a peer floating (changing its remote UDP endpoint) + notify: peer-get + mcgrp: peers + mcast-groups: list: - diff --git a/Documentation/netlink/specs/psp.yaml b/Documentation/netlink/specs/psp.yaml index f3a57782d2cf..100c36cda8e5 100644 --- a/Documentation/netlink/specs/psp.yaml +++ b/Documentation/netlink/specs/psp.yaml @@ -267,6 +267,14 @@ operations: - dev-id - key-rotations - stale-events + - rx-packets + - rx-bytes + - rx-auth-fail + - rx-error + - rx-bad + - tx-packets + - tx-bytes + - tx-error pre: psp-device-get-locked post: psp-device-unlock dump: diff --git a/Documentation/netlink/specs/rt-link.yaml b/Documentation/netlink/specs/rt-link.yaml index df4b56beb818..f23aa5f229c5 100644 --- a/Documentation/netlink/specs/rt-link.yaml +++ b/Documentation/netlink/specs/rt-link.yaml @@ -826,6 +826,13 @@ definitions: - name: none - name: default - + name: netkit-pairing + type: enum + enum-name: netkit-pairing + entries: + - name: pair + - name: single + - name: ovpn-mode enum-name: ovpn-mode name-prefix: ovpn-mode @@ -833,6 +840,14 @@ definitions: entries: - p2p - mp + - + name: br-stp-mode + type: enum + enum-name: br-stp-mode + entries: + - auto + - user + - kernel attribute-sets: - @@ -1543,6 +1558,10 @@ attribute-sets: - name: fdb-max-learned type: u32 + - + name: stp-mode + type: u32 + enum: br-stp-mode - name: linkinfo-brport-attrs name-prefix: ifla-brport- @@ -2299,6 +2318,10 @@ attribute-sets: - name: tailroom type: u16 + - + name: pairing + type: u32 + enum: netkit-pairing - name: linkinfo-ovpn-attrs name-prefix: ifla-ovpn- diff --git a/Documentation/networking/bridge.rst b/Documentation/networking/bridge.rst index ef8b73e157b2..c1e6ea52c9e5 100644 --- a/Documentation/networking/bridge.rst +++ b/Documentation/networking/bridge.rst @@ -148,6 +148,28 @@ called by the kernel when STP is enabled/disabled on a bridge stp_state <0|1>``). The kernel enables user_stp mode if that command returns 0, or enables kernel_stp mode if that command returns any other value. +STP mode selection +------------------ + +The ``IFLA_BR_STP_MODE`` bridge attribute allows explicit control over how +STP operates when enabled, bypassing the ``/sbin/bridge-stp`` helper +entirely for the ``user`` and ``kernel`` modes. + +.. kernel-doc:: include/uapi/linux/if_link.h + :doc: Bridge STP mode values + +The default mode is ``BR_STP_MODE_AUTO``, which preserves the traditional +behavior of invoking the ``/sbin/bridge-stp`` helper. The ``user`` and +``kernel`` modes are particularly useful in network namespace environments +where the helper mechanism is not available, as ``call_usermodehelper()`` +is restricted to the initial network namespace. + +Example:: + + ip link set dev br0 type bridge stp_mode user stp_state 1 + +The mode can only be changed while STP is disabled. + VLAN ==== diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst index a52850602cd8..c31c6c197cdb 100644 --- a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst @@ -323,7 +323,7 @@ Setup HTB offload # ethtool -K <interface> hw-tc-offload on -2. Crate htb root:: +2. Create htb root:: # tc qdisc add dev <interface> clsact # tc qdisc replace dev <interface> root handle 1: htb offload diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst index 34e911480108..b45d6871492c 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst @@ -114,13 +114,13 @@ Enabling the driver and kconfig options **CONFIG_MLX5_SF=(y/n)** | Build support for subfunction. -| Subfunctons are more light weight than PCI SRIOV VFs. Choosing this option +| Subfunctions are more light weight than PCI SRIOV VFs. Choosing this option | will enable support for creating subfunction devices. **CONFIG_MLX5_SF_MANAGER=(y/n)** -| Build support for subfuction port in the NIC. A Mellanox subfunction +| Build support for subfunction port in the NIC. A Mellanox subfunction | port is managed through devlink. A subfunction supports RDMA, netdevice | and vdpa device. It is similar to a SRIOV VF but it doesn't require | SRIOV support. diff --git a/Documentation/networking/devlink/devlink-resource.rst b/Documentation/networking/devlink/devlink-resource.rst index 3d5ae51e65a2..47eec8f875b4 100644 --- a/Documentation/networking/devlink/devlink-resource.rst +++ b/Documentation/networking/devlink/devlink-resource.rst @@ -74,3 +74,73 @@ attribute, which represents the pending change in size. For example: Note that changes in resource size may require a device reload to properly take effect. + +Port-level Resources and Full Dump +================================== + +In addition to device-level resources, ``devlink`` also supports port-level +resources. These resources are associated with a specific devlink port rather +than the device as a whole. + +To list resources for all devlink devices and ports: + +.. code:: shell + + $ devlink resource show + pci/0000:03:00.0: + name max_local_SFs size 128 unit entry dpipe_tables none + name max_external_SFs size 128 unit entry dpipe_tables none + pci/0000:03:00.0/196608: + name max_SFs size 128 unit entry dpipe_tables none + pci/0000:03:00.0/196609: + name max_SFs size 128 unit entry dpipe_tables none + pci/0000:03:00.1: + name max_local_SFs size 128 unit entry dpipe_tables none + name max_external_SFs size 128 unit entry dpipe_tables none + pci/0000:03:00.1/196708: + name max_SFs size 128 unit entry dpipe_tables none + pci/0000:03:00.1/196709: + name max_SFs size 128 unit entry dpipe_tables none + +To show resources for a specific port: + +.. code:: shell + + $ devlink resource show pci/0000:03:00.0/196608 + pci/0000:03:00.0/196608: + name max_SFs size 128 unit entry dpipe_tables none + +Resource Scope Filtering +======================== + +When dumping resources for all devices, ``devlink resource show`` accepts +an optional ``scope`` parameter to restrict the response to device-level +resources, port-level resources, or both (the default). + +To dump only device-level resources across all devices: + +.. code:: shell + + $ devlink resource show scope dev + pci/0000:03:00.0: + name max_local_SFs size 128 unit entry dpipe_tables none + name max_external_SFs size 128 unit entry dpipe_tables none + pci/0000:03:00.1: + name max_local_SFs size 128 unit entry dpipe_tables none + name max_external_SFs size 128 unit entry dpipe_tables none + +To dump only port-level resources across all devices: + +.. code:: shell + + $ devlink resource show scope port + pci/0000:03:00.0/196608: + name max_SFs size 128 unit entry dpipe_tables none + pci/0000:03:00.0/196609: + name max_SFs size 128 unit entry dpipe_tables none + pci/0000:03:00.1/196708: + name max_SFs size 128 unit entry dpipe_tables none + pci/0000:03:00.1/196709: + name max_SFs size 128 unit entry dpipe_tables none + +Note that port-level resources are read-only. diff --git a/Documentation/networking/devlink/devlink-shared.rst b/Documentation/networking/devlink/devlink-shared.rst new file mode 100644 index 000000000000..16bf6a7d25d9 --- /dev/null +++ b/Documentation/networking/devlink/devlink-shared.rst @@ -0,0 +1,97 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================== +Devlink Shared Instances +======================== + +Overview +======== + +Shared devlink instances allow multiple physical functions (PFs) on the same +chip to share a devlink instance for chip-wide operations. + +Multiple PFs may reside on the same physical chip, running a single firmware. +Some of the resources and configurations may be shared among these PFs. The +shared devlink instance provides an object to pin configuration knobs on. + +There are two possible usage models: + +1. The shared devlink instance is used alongside individual PF devlink + instances, providing chip-wide configuration in addition to per-PF + configuration. +2. The shared devlink instance is the only devlink instance, without + per-PF instances. + +It is up to the driver to decide which usage model to use. + +The shared devlink instance is not backed by any struct *device*. + +Implementation +============== + +Architecture +------------ + +The implementation uses: + +* **Chip identification**: PFs are grouped by chip using a driver-specific identifier +* **Shared instance management**: Global list of shared instances with reference counting + +API Functions +------------- + +The following functions are provided for managing shared devlink instances: + +* ``devlink_shd_get()``: Get or create a shared devlink instance identified by a string ID +* ``devlink_shd_put()``: Release a reference on a shared devlink instance +* ``devlink_shd_get_priv()``: Get private data from shared devlink instance + +Initialization Flow +------------------- + +1. **PF calls shared devlink init** during driver probe +2. **Chip identification** using driver-specific method to determine device identity +3. **Get or create shared instance** using ``devlink_shd_get()``: + + * The function looks up existing instance by identifier + * If none exists, creates new instance: + - Allocates and registers devlink instance + - Adds to global shared instances list + - Increments reference count + +4. **Set nested devlink instance** for the PF devlink instance using + ``devl_nested_devlink_set()`` before registering the PF devlink instance + +Cleanup Flow +------------ + +1. **Cleanup** when PF is removed +2. **Call** ``devlink_shd_put()`` to release reference (decrements reference count) +3. **Shared instance is automatically destroyed** when the last PF removes (reference count reaches zero) + +Chip Identification +------------------- + +PFs belonging to the same chip are identified using a driver-specific method. +The driver is free to choose any identifier that is suitable for determining +whether two PFs are part of the same device. Examples include: + +* **PCI VPD serial numbers**: Extract from PCI VPD +* **Device tree properties**: Read chip identifier from device tree +* **Other hardware-specific identifiers**: Any unique identifier that groups PFs by chip + +Locking +------- + +A global mutex (``shd_mutex``) protects the shared instances list during registration/deregistration. + +Similarly to other nested devlink instance relationships, devlink lock of +the shared instance should be always taken after the devlink lock of PF. + +Reference Counting +------------------ + +Each shared devlink instance maintains a reference count (``refcount_t refcount``). +The reference count is incremented when ``devlink_shd_get()`` is called and decremented +when ``devlink_shd_put()`` is called. When the reference count reaches zero, the shared +instance is automatically destroyed. diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index 35b12a2bfeba..f7ba7dcf477d 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -68,6 +68,7 @@ general. devlink-resource devlink-selftests devlink-trap + devlink-shared Driver-specific documentation ----------------------------- diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 5c79740a533b..fd3c254ced1d 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -383,11 +383,6 @@ DSA data structures are defined in ``include/net/dsa.h`` as well as well as various properties of its ports: names/labels, and finally a routing table indication (when cascading switches) -- ``dsa_platform_data``: platform device configuration data which can reference - a collection of dsa_chip_data structures if multiple switches are cascaded, - the conduit network device this switch tree is attached to needs to be - referenced - - ``dsa_switch_tree``: structure assigned to the conduit network device under ``dsa_ptr``, this structure references a dsa_platform_data structure as well as the tagging protocol supported by the switch tree, and which receive/transmit diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index af56c304cef4..e92abf45faf5 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -96,7 +96,7 @@ For short bitmaps of (reasonably) fixed length, standard ``NLA_BITFIELD32`` type is used. For arbitrary length bitmaps, ethtool netlink uses a nested attribute with contents of one of two forms: compact (two binary bitmaps representing bit values and mask of affected bits) and bit-by-bit (list of -bits identified by either index or name). +bits identified by index or name). Verbose (bit-by-bit) bitsets allow sending symbolic names for bits together with their values which saves a round trip (when the bitset is passed in a @@ -156,12 +156,16 @@ Bit-by-bit form: nested (bitset) attribute contents: | | | ``ETHTOOL_A_BITSET_BIT_VALUE`` | flag | present if bit is set | +-+-+--------------------------------+--------+-----------------------------+ -Bit size is optional for bit-by-bit form. ``ETHTOOL_A_BITSET_BITS`` nest can +For bit-by-bit form, ``ETHTOOL_A_BITSET_SIZE`` is optional, and +``ETHTOOL_A_BITSET_BITS`` is mandatory. ``ETHTOOL_A_BITSET_BITS`` nest can only contain ``ETHTOOL_A_BITSET_BITS_BIT`` attributes but there can be an arbitrary number of them. A bit may be identified by its index or by its name. When used in requests, listed bits are set to 0 or 1 according to -``ETHTOOL_A_BITSET_BIT_VALUE``, the rest is preserved. A request fails if -index exceeds kernel bit length or if name is not recognized. +``ETHTOOL_A_BITSET_BIT_VALUE``, the rest is preserved. + +A request fails if index exceeds kernel bit length or if name is not +recognized. If both name and index are set, the request will fail if they +point to different bits. When ``ETHTOOL_A_BITSET_NOMASK`` flag is present, bitset is interpreted as a simple bitmap. ``ETHTOOL_A_BITSET_BIT_VALUE`` attributes are not used in @@ -1072,6 +1076,8 @@ Kernel response contents: ``ETHTOOL_A_COALESCE_TX_AGGR_TIME_USECS`` u32 time (us), aggr, Tx ``ETHTOOL_A_COALESCE_RX_PROFILE`` nested profile of DIM, Rx ``ETHTOOL_A_COALESCE_TX_PROFILE`` nested profile of DIM, Tx + ``ETHTOOL_A_COALESCE_RX_CQE_FRAMES`` u32 max packets, Rx CQE + ``ETHTOOL_A_COALESCE_RX_CQE_NSECS`` u32 delay (ns), Rx CQE =========================================== ====== ======================= Attributes are only included in reply if their value is not zero or the @@ -1105,6 +1111,13 @@ well with frequent small-sized URBs transmissions. to DIM parameters, see `Generic Network Dynamic Interrupt Moderation (Net DIM) <https://www.kernel.org/doc/Documentation/networking/net_dim.rst>`_. +Rx CQE coalescing allows multiple received packets to be coalesced into a +single Completion Queue Entry (CQE) or descriptor writeback. +``ETHTOOL_A_COALESCE_RX_CQE_FRAMES`` describes the maximum number of +frames that can be coalesced into a CQE or writeback. +``ETHTOOL_A_COALESCE_RX_CQE_NSECS`` describes max time in nanoseconds after +the first packet arrival in a coalesced CQE or writeback to be sent. + COALESCE_SET ============ @@ -1143,6 +1156,8 @@ Request contents: ``ETHTOOL_A_COALESCE_TX_AGGR_TIME_USECS`` u32 time (us), aggr, Tx ``ETHTOOL_A_COALESCE_RX_PROFILE`` nested profile of DIM, Rx ``ETHTOOL_A_COALESCE_TX_PROFILE`` nested profile of DIM, Tx + ``ETHTOOL_A_COALESCE_RX_CQE_FRAMES`` u32 max packets, Rx CQE + ``ETHTOOL_A_COALESCE_RX_CQE_NSECS`` u32 delay (ns), Rx CQE =========================================== ====== ======================= Request is rejected if it attributes declared as unsupported by driver (i.e. diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 6921d8594b84..2e3a746fcc6d 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -202,6 +202,24 @@ neigh/default/gc_thresh3 - INTEGER Default: 1024 +neigh/default/gc_interval - INTEGER + Specifies how often the garbage collector for neighbor entries + should run. This value applies to the entire table, not + individual entries. Unused since kernel v2.6.8. + + Default: 30 seconds + +neigh/default/gc_stale_time - INTEGER + Determines how long a neighbor entry can remain unused before it is + considered stale and eligible for garbage collection. Entries that have + not been used for longer than this time will be removed by the garbage + collector, unless they have active references, are marked as PERMANENT, + or carry the NTF_EXT_LEARNED or NTF_EXT_VALIDATED flag. Stale entries + are only removed by the periodic GC when there are at least gc_thresh1 + neighbors in the table. + + Default: 60 seconds + neigh/default/unres_qlen_bytes - INTEGER The maximum number of bytes which may be used by packets queued for each unresolved address by other network layers. @@ -1612,6 +1630,22 @@ ip_local_reserved_ports - list of comma separated ranges Default: Empty +ip_local_port_step_width - INTEGER + Defines the numerical maximum increment between successive port + allocations within the ephemeral port range when an unavailable port is + reached. This can be used to mitigate accumulated nodes in port + distribution when reserved ports have been configured. Please note that + port collisions may be more frequent in a system with a very high load. + + It is recommended to set this value strictly larger than the largest + contiguous block of ports configure in ip_local_reserved_ports. For + large reserved port ranges, setting this to 3x or 4x the size of the + largest block is advised. Using a value equal or greater than the local + port range size completely solves the uneven port distribution problem, + but it can degrade performance under port exhaustion situations. + + Default: 0 (disabled) + ip_unprivileged_port_start - INTEGER This is a per-namespace sysctl. It defines the first unprivileged port in the network namespace. Privileged ports @@ -1747,14 +1781,14 @@ icmp_msgs_per_sec - INTEGER controlled by this limit. For security reasons, the precise count of messages per second is randomized. - Default: 1000 + Default: 10000 icmp_msgs_burst - INTEGER icmp_msgs_per_sec controls number of ICMP packets sent per second, - while icmp_msgs_burst controls the burst size of these packets. + while icmp_msgs_burst controls the token bucket size. For security reasons, the precise burst size is randomized. - Default: 50 + Default: 10000 icmp_ratemask - INTEGER Mask made of ICMP types for which rates are being limited. diff --git a/Documentation/networking/ipvs-sysctl.rst b/Documentation/networking/ipvs-sysctl.rst index 3fb5fa142eef..a556439f8be7 100644 --- a/Documentation/networking/ipvs-sysctl.rst +++ b/Documentation/networking/ipvs-sysctl.rst @@ -29,6 +29,33 @@ backup_only - BOOLEAN If set, disable the director function while the server is in backup mode to avoid packet loops for DR/TUN methods. +conn_lfactor - INTEGER + Possible values: -8 (larger table) .. 8 (smaller table) + + Default: -4 + + Controls the sizing of the connection hash table based on the + load factor (number of connections per table buckets): + + 2^conn_lfactor = nodes / buckets + + As result, the table grows if load increases and shrinks when + load decreases in the range of 2^8 - 2^conn_tab_bits (module + parameter). + The value is a shift count where negative values select + buckets = (connection hash nodes << -value) while positive + values select buckets = (connection hash nodes >> value). The + negative values reduce the collisions and reduce the time for + lookups but increase the table size. Positive values will + tolerate load above 100% when using smaller table is + preferred with the cost of more collisions. If using NAT + connections consider decreasing the value with one because + they add two nodes in the hash table. + + Example: + -4: grow if load goes above 6% (buckets = nodes * 16) + 2: grow if load goes above 400% (buckets = nodes / 4) + conn_reuse_mode - INTEGER 1 - default @@ -219,6 +246,16 @@ secure_tcp - INTEGER The value definition is the same as that of drop_entry and drop_packet. +svc_lfactor - INTEGER + Possible values: -8 (larger table) .. 8 (smaller table) + + Default: -3 + + Controls the sizing of the service hash table based on the + load factor (number of services per table buckets). The table + will grow and shrink in the range of 2^4 - 2^20. + See conn_lfactor for explanation. + sync_threshold - vector of 2 INTEGERs: sync_threshold, sync_period default 3 50 diff --git a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst index beaf1880a19b..6dbd97d435e9 100644 --- a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst +++ b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst @@ -52,6 +52,7 @@ u8 sysctl_ip_fwd_update_priority u8 sysctl_ip_nonlocal_bind u8 sysctl_ip_autobind_reuse u8 sysctl_ip_dynaddr +u32 sysctl_ip_local_port_step_width u8 sysctl_ip_early_demux read_mostly ip(6)_rcv_finish_core u8 sysctl_raw_l3mdev_accept u8 sysctl_tcp_early_demux read_mostly ip(6)_rcv_finish_core @@ -104,6 +105,7 @@ u8 sysctl_tcp_nometrics_save u8 sysctl_tcp_no_ssthresh_metrics_save TCP_LAST_ACK/tcp_(update/init)_metrics u8 sysctl_tcp_moderate_rcvbuf read_mostly tcp_rcvbuf_grow() u32 sysctl_tcp_rcvbuf_low_rtt read_mostly tcp_rcvbuf_grow() +u8 sysctl_tcp_shrink_window read_mostly read_mostly __tcp_select_window() u8 sysctl_tcp_tso_win_divisor read_mostly tcp_tso_should_defer(tcp_write_xmit) u8 sysctl_tcp_workaround_signed_windows tcp_select_window int sysctl_tcp_limit_output_bytes read_mostly tcp_small_queue_check(tcp_write_xmit) diff --git a/Documentation/networking/net_cachelines/tcp_sock.rst b/Documentation/networking/net_cachelines/tcp_sock.rst index 563daea10d6c..fecf61166a54 100644 --- a/Documentation/networking/net_cachelines/tcp_sock.rst +++ b/Documentation/networking/net_cachelines/tcp_sock.rst @@ -121,6 +121,7 @@ u64 delivered_mstamp read_write u32 rate_delivered read_mostly tcp_rate_gen u32 rate_interval_us read_mostly rate_delivered,rate_app_limited u32 rcv_wnd read_write read_mostly tcp_select_window,tcp_receive_window,tcp_fast_path_check +u32 rcv_mwnd_seq read_write tcp_select_window u32 write_seq read_write tcp_rate_check_app_limited,tcp_write_queue_empty,tcp_skb_entail,forced_push,tcp_mark_push u32 notsent_lowat read_mostly tcp_stream_memory_free u32 pushed_seq read_write tcp_mark_push,forced_push diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index 35704d115312..83e28b96884f 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -329,6 +329,12 @@ by setting ``request_ops_lock`` to true. Code comments and docs refer to drivers which have ops called under the instance lock as "ops locked". See also the documentation of the ``lock`` member of struct net_device. +There is also a case of taking two per-netdev locks in sequence when netdev +queues are leased, that is, the netdev-scope lock is taken for both the +virtual and the physical device. To prevent deadlocks, the virtual device's +lock must always be acquired before the physical device's (see +``netdev_nl_queue_create_doit``). + In the future, there will be an option for individual drivers to opt out of using ``rtnl_lock`` and instead perform their control operations directly under the netdev instance lock. diff --git a/Documentation/networking/scaling.rst b/Documentation/networking/scaling.rst index 0023afa530ec..6c261eb48845 100644 --- a/Documentation/networking/scaling.rst +++ b/Documentation/networking/scaling.rst @@ -403,16 +403,21 @@ Both of these need to be set before RFS is enabled for a receive queue. Values for both are rounded up to the nearest power of two. The suggested flow count depends on the expected number of active connections at any given time, which may be significantly less than the number of open -connections. We have found that a value of 32768 for rps_sock_flow_entries -works fairly well on a moderately loaded server. +connections. We have found that a value of 65536 for rps_sock_flow_entries +works fairly well on a moderately loaded server. Big servers might +need 1048576 or even higher values. + +On a NUMA host it is advisable to spread rps_sock_flow_entries on all nodes. + +numactl --interleave=all bash -c "echo 1048576 >/proc/sys/net/core/rps_sock_flow_entries" For a single queue device, the rps_flow_cnt value for the single queue would normally be configured to the same value as rps_sock_flow_entries. For a multi-queue device, the rps_flow_cnt for each queue might be configured as rps_sock_flow_entries / N, where N is the number of -queues. So for instance, if rps_sock_flow_entries is set to 32768 and there +queues. So for instance, if rps_sock_flow_entries is set to 131072 and there are 16 configured receive queues, rps_flow_cnt for each queue might be -configured as 2048. +configured as 8192. Accelerated RFS diff --git a/Documentation/networking/smc-sysctl.rst b/Documentation/networking/smc-sysctl.rst index 904a910f198e..a8b4f357174e 100644 --- a/Documentation/networking/smc-sysctl.rst +++ b/Documentation/networking/smc-sysctl.rst @@ -23,17 +23,17 @@ autocorking_size - INTEGER Default: 64K smcr_buf_type - INTEGER - Controls which type of sndbufs and RMBs to use in later newly created - SMC-R link group. Only for SMC-R. + Controls which type of sndbufs and RMBs to use in later newly created + SMC-R link group. Only for SMC-R. - Default: 0 (physically contiguous sndbufs and RMBs) + Default: 0 (physically contiguous sndbufs and RMBs) - Possible values: + Possible values: - - 0 - Use physically contiguous buffers - - 1 - Use virtually contiguous buffers - - 2 - Mixed use of the two types. Try physically contiguous buffers first. - If not available, use virtually contiguous buffers then. + - 0 - Use physically contiguous buffers + - 1 - Use virtually contiguous buffers + - 2 - Mixed use of the two types. Try physically contiguous buffers first. + If not available, use virtually contiguous buffers then. smcr_testlink_time - INTEGER How frequently SMC-R link sends out TEST_LINK LLC messages to confirm @@ -111,3 +111,30 @@ smcr_max_recv_wr - INTEGER like before having this control. Default: 48 + +limit_smc_hs - INTEGER + Whether to limit SMC handshake for newly created sockets. + + When enabled, SMC listen path applies handshake limitation based on + handshake worker congestion and queued SMC handshake load. + + Possible values: + + - 0 - Disable handshake limitation + - 1 - Enable handshake limitation + + Default: 0 (disable) + +hs_ctrl - STRING + Select the SMC handshake control profile by name. + + This string refers to the name of a user-implemented + BPF struct_ops instance of type smc_hs_ctrl. + + The selected profile controls whether SMC options are advertised + during TCP SYN/SYN-ACK handshake. + + Only available when CONFIG_SMC_HS_CTRL_BPF is enabled. + Write an empty string to clear the current profile. + + Default: empty string diff --git a/Documentation/networking/tls-handshake.rst b/Documentation/networking/tls-handshake.rst index 6f5ea1646a47..4f7bc1087df9 100644 --- a/Documentation/networking/tls-handshake.rst +++ b/Documentation/networking/tls-handshake.rst @@ -7,7 +7,7 @@ In-Kernel TLS Handshake Overview ======== -Transport Layer Security (TLS) is a Upper Layer Protocol (ULP) that runs +Transport Layer Security (TLS) is an Upper Layer Protocol (ULP) that runs over TCP. TLS provides end-to-end data integrity and confidentiality in addition to peer authentication. diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst index 57fa8cac58a6..77f3f80e7cd7 100644 --- a/Documentation/process/2.Process.rst +++ b/Documentation/process/2.Process.rst @@ -291,7 +291,7 @@ Use of the MMOTM tree is likely to be a frustrating experience, though; there is a definite chance that it will not even compile. The primary tree for next-cycle patch merging is linux-next, maintained by -Stephen Rothwell. The linux-next tree is, by design, a snapshot of what +Mark Brown. The linux-next tree is, by design, a snapshot of what the mainline is expected to look like after the next merge window closes. Linux-next trees are announced on the linux-kernel and linux-next mailing lists when they are assembled; they can be downloaded from: diff --git a/Documentation/process/backporting.rst b/Documentation/process/backporting.rst index c42779fbcd33..0de9eacd46a7 100644 --- a/Documentation/process/backporting.rst +++ b/Documentation/process/backporting.rst @@ -432,7 +432,7 @@ The same goes for added ``return``, ``break``, and ``continue`` statements. Error handling is typically located at the bottom of the function, so it -may not be part of the conflict even though could have been changed by +may not be part of the conflict even though it could have been changed by other patches. A good way to ensure that you review the error paths is to always use diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index 6b373e193548..9a99037270ff 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -19,50 +19,52 @@ Current Minimal Requirements Upgrade to at **least** these software revisions before thinking you've encountered a bug! If you're unsure what version you're currently -running, the suggested command should tell you. +running, the suggested command should tell you. For a list of the programs +on your system including their version execute ./scripts/ver_linux Again, keep in mind that this list assumes you are already functionally running a Linux kernel. Also, not all tools are necessary on all systems; obviously, if you don't have any PC Card hardware, for example, -you probably needn't concern yourself with pcmciautils. +you probably do not need to concern yourself with pcmciautils. ====================== =============== ======================================== Program Minimal version Command to check the version ====================== =============== ======================================== -GNU C 8.1 gcc --version -Clang/LLVM (optional) 15.0.0 clang --version -Rust (optional) 1.78.0 rustc --version -bindgen (optional) 0.65.1 bindgen --version -GNU make 4.0 make --version bash 4.2 bash --version +bc 1.06.95 bc --version +bindgen (optional) 0.71.1 bindgen --version binutils 2.30 ld -v -flex 2.5.35 flex --version bison 2.0 bison --version -pahole 1.22 pahole --version -util-linux 2.10o mount --version -kmod 13 depmod -V +btrfs-progs 0.18 btrfs --version +Clang/LLVM (optional) 15.0.0 clang --version e2fsprogs 1.41.4 e2fsck -V +flex 2.5.35 flex --version +gdb 7.2 gdb --version +GNU awk (optional) 5.1.0 gawk --version +GNU C 8.1 gcc --version +GNU make 4.0 make --version +GNU tar 1.28 tar --version +GRUB 0.93 grub --version || grub-install --version +gtags (optional) 6.6.5 gtags --version +iptables 1.4.2 iptables -V jfsutils 1.1.3 fsck.jfs -V -xfsprogs 2.6.0 xfs_db -V -squashfs-tools 4.0 mksquashfs -version -btrfs-progs 0.18 btrfs --version +kmod 13 kmod -V +mcelog 0.6 mcelog --version +mkimage (optional) 2017.01 mkimage --version +nfs-utils 1.0.5 showmount --version +openssl & libcrypto 1.0.0 openssl version +pahole 1.22 pahole --version pcmciautils 004 pccardctl -V -quota-tools 3.09 quota -V PPP 2.4.0 pppd --version -nfs-utils 1.0.5 showmount --version procps 3.2.0 ps --version -udev 081 udevd --version -grub 0.93 grub --version || grub-install --version -mcelog 0.6 mcelog --version -iptables 1.4.2 iptables -V -openssl & libcrypto 1.0.0 openssl version -bc 1.06.95 bc --version -Sphinx\ [#f1]_ 3.4.3 sphinx-build --version -GNU tar 1.28 tar --version -gtags (optional) 6.6.5 gtags --version -mkimage (optional) 2017.01 mkimage --version Python 3.9.x python3 --version -GNU AWK (optional) 5.1.0 gawk --version +quota-tools 3.09 quota -V +Rust (optional) 1.85.0 rustc --version +Sphinx\ [#f1]_ 3.4.3 sphinx-build --version +squashfs-tools 4.0 mksquashfs -version +udev 081 udevadm --version +util-linux 2.10o mount --version +xfsprogs 2.6.0 xfs_db -V ====================== =============== ======================================== .. [#f1] Sphinx is needed only to build the Kernel documentation @@ -391,7 +393,7 @@ Kernel documentation Sphinx ------ -Please see :ref:`sphinx_install` in :ref:`Documentation/doc-guide/sphinx.rst <sphinxdoc>` +Please see :ref:`sphinx_install` in Documentation/doc-guide/sphinx.rst for details about Sphinx requirements. rustdoc diff --git a/Documentation/process/debugging/gdb-kernel-debugging.rst b/Documentation/process/debugging/gdb-kernel-debugging.rst index 9475c759c722..53e225760a4d 100644 --- a/Documentation/process/debugging/gdb-kernel-debugging.rst +++ b/Documentation/process/debugging/gdb-kernel-debugging.rst @@ -173,3 +173,12 @@ this is just a snapshot of the initial version:: Detailed help can be obtained via "help <command-name>" for commands and "help function <function-name>" for convenience functions. + +Debugging GDB scripts +--------------------- + +GDB does not enable a full Python backtrace which can make debugging GDB +scripts more difficult than necessary. The following will allow for printing a +full backtrace of the python environment:: + + (gdb) set python print-stack full diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst index 1f5ab49c48a4..c71b5d403f0c 100644 --- a/Documentation/process/handling-regressions.rst +++ b/Documentation/process/handling-regressions.rst @@ -461,325 +461,556 @@ which both cover more details than the above section. Quotes from Linus about regression ---------------------------------- -Find below a few real life examples of how Linus Torvalds expects regressions to -be handled: +The following statements from Linus Torvalds provide some insight into Linux +"no regressions" rule and how he expects regressions to be handled: - * From `2017-10-26 (1/2) - <https://lore.kernel.org/lkml/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_:: +On how quickly regressions should be fixed +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - If you break existing user space setups THAT IS A REGRESSION. +* From `2026-01-22 <https://lore.kernel.org/all/CAHk-=wheQNiW_WtHGO7bKkT7Uib-p+ai2JP9M+z+FYcZ6CAxYA@mail.gmail.com/>`_:: - It's not ok to say "but we'll fix the user space setup". + But a user complaining should basically result in an immediate fix - + possibly a "revert and rethink". - Really. NOT OK. + With a later clarification on `2026-01-28 <https://lore.kernel.org/all/CAHk-%3Dwi86AosXs66-yi54%2BmpQjPu0upxB8ZAfG%2BLsMyJmcuMSA@mail.gmail.com/>`_:: - [...] + It's also worth noting that "immediate" obviously doesn't mean "right + this *second* when the problem has been reported". - The first rule is: + But if it's a regression with a known commit that caused it, I think + the rule of thumb should generally be "within a week", preferably + before the next rc. - - we don't cause regressions +* From `2023-04-21 <https://lore.kernel.org/all/CAHk-=wgD98pmSK3ZyHk_d9kZ2bhgN6DuNZMAJaV0WTtbkf=RDw@mail.gmail.com/>`_:: - and the corollary is that when regressions *do* occur, we admit to - them and fix them, instead of blaming user space. + Known-broken commits either + (a) get a timely fix that doesn't have other questions + or + (b) get reverted - The fact that you have apparently been denying the regression now for - three weeks means that I will revert, and I will stop pulling apparmor - requests until the people involved understand how kernel development - is done. +* From `2021-09-20(2) <https://lore.kernel.org/all/CAHk-=wgOvmtRw1TNbMC1rn5YqyTKyn0hz+sc4k0DGNn++u9aYw@mail.gmail.com/>`_:: - * From `2017-10-26 (2/2) - <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_:: + [...] review shouldn't hold up reported regressions of existing code. That's + just basic _testing_ - either the fix should be applied, or - if the fix is + too invasive or too ugly - the problematic source of the regression should + be reverted. - People should basically always feel like they can update their kernel - and simply not have to worry about it. + Review should be about new code, it shouldn't be holding up "there's a + bug report, here's the obvious fix". - I refuse to introduce "you can only update the kernel if you also - update that other program" kind of limitations. If the kernel used to - work for you, the rule is that it continues to work for you. +* From `2023-05-08 <https://lore.kernel.org/all/CAHk-=wgzU8_dGn0Yg+DyX7ammTkDUCyEJ4C=NvnHRhxKWC7Wpw@mail.gmail.com/>`_:: - There have been exceptions, but they are few and far between, and they - generally have some major and fundamental reasons for having happened, - that were basically entirely unavoidable, and people _tried_hard_ to - avoid them. Maybe we can't practically support the hardware any more - after it is decades old and nobody uses it with modern kernels any - more. Maybe there's a serious security issue with how we did things, - and people actually depended on that fundamentally broken model. Maybe - there was some fundamental other breakage that just _had_ to have a - flag day for very core and fundamental reasons. + If something doesn't even build, it should damn well be fixed ASAP. - And notice that this is very much about *breaking* peoples environments. +On how fixing regressions with reverts can help prevent maintainer burnout +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Behavioral changes happen, and maybe we don't even support some - feature any more. There's a number of fields in /proc/<pid>/stat that - are printed out as zeroes, simply because they don't even *exist* in - the kernel any more, or because showing them was a mistake (typically - an information leak). But the numbers got replaced by zeroes, so that - the code that used to parse the fields still works. The user might not - see everything they used to see, and so behavior is clearly different, - but things still _work_, even if they might no longer show sensitive - (or no longer relevant) information. +* From `2026-01-28 <https://lore.kernel.org/all/CAHk-%3Dwi86AosXs66-yi54%2BmpQjPu0upxB8ZAfG%2BLsMyJmcuMSA@mail.gmail.com/>`_:: - But if something actually breaks, then the change must get fixed or - reverted. And it gets fixed in the *kernel*. Not by saying "well, fix - your user space then". It was a kernel change that exposed the - problem, it needs to be the kernel that corrects for it, because we - have a "upgrade in place" model. We don't have a "upgrade with new - user space". + > So how can I/we make "immediate fixes" happen more often without + > contributing to maintainer burnout? - And I seriously will refuse to take code from people who do not - understand and honor this very simple rule. + [...] the "revert and rethink" model [...] often a good idea in general [...] - This rule is also not going to change. + Exactly so that maintainers don't get stressed out over having a pending + problem report that people keep pestering them about. - And yes, I realize that the kernel is "special" in this respect. I'm - proud of it. + I think people are sometimes a bit too bought into whatever changes + they made, and reverting is seen as "too drastic", but I think it's + often the quick and easy solution for when there isn't some obvious + response to a regression report. - I have seen, and can point to, lots of projects that go "We need to - break that use case in order to make progress" or "you relied on - undocumented behavior, it sucks to be you" or "there's a better way to - do what you want to do, and you have to change to that new better - way", and I simply don't think that's acceptable outside of very early - alpha releases that have experimental users that know what they signed - up for. The kernel hasn't been in that situation for the last two - decades. +On mainlining fixes when the last -rc or a new release is close +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - We do API breakage _inside_ the kernel all the time. We will fix - internal problems by saying "you now need to do XYZ", but then it's - about internal kernel API's, and the people who do that then also - obviously have to fix up all the in-kernel users of that API. Nobody - can say "I now broke the API you used, and now _you_ need to fix it - up". Whoever broke something gets to fix it too. +* From `2026-02-01 <https://lore.kernel.org/all/CAHk-%3DwhXTw1oPsa%2BTLuY1Rc9D1OAiPVOdR_-R2xG45kwDObKdA@mail.gmail.com/>`_:: - And we simply do not break user space. + So I think I'd rather see them hit rc8 (later today) and have a week + of testing in my tree and be reverted if they cause problems, than + have them go in after rc8 and then cause problems in the 6.19 release + instead. - * From `2020-05-21 - <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_:: +* From `2023-04-20 <https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/>`_:: - The rules about regressions have never been about any kind of - documented behavior, or where the code lives. + But something like this, where the regression was in the previous release + and it's just a clear fix with no semantic subtlety, I consider to be just a + regular regression that should be expedited - partly to make it into stable, + and partly to avoid having to put the fix into _another_ stable kernel. - The rules about regressions are always about "breaks user workflow". +On sending merge requests with just one fix +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Users are literally the _only_ thing that matters. +* From `2024-04-24 <https://lore.kernel.org/all/CAHk-=wjy_ph9URuFt-pq+2AJ__p7gFDx=yzVSCsx16xAYvNw9g@mail.gmail.com/>`_:: - No amount of "you shouldn't have used this" or "that behavior was - undefined, it's your own fault your app broke" or "that used to work - simply because of a kernel bug" is at all relevant. + If the issue is just that there's nothing else happening, I think people + should just point me to the patch and say "can you apply this single fix?" - Now, reality is never entirely black-and-white. So we've had things - like "serious security issue" etc that just forces us to make changes - that may break user space. But even then the rule is that we don't - really have other options that would allow things to continue. +* From `2023-04-20 <https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/>`_:: - And obviously, if users take years to even notice that something - broke, or if we have sane ways to work around the breakage that - doesn't make for too much trouble for users (ie "ok, there are a - handful of users, and they can use a kernel command line to work - around it" kind of things) we've also been a bit less strict. + I'm always open to direct fixes when there is no controversy about the fix. + No problem. I still happily deal with individual patches. - But no, "that was documented to be broken" (whether it's because the - code was in staging or because the man-page said something else) is - irrelevant. If staging code is so useful that people end up using it, - that means that it's basically regular kernel code with a flag saying - "please clean this up". +On the importance of pointing to bug reports using Link:/Closes: tags +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - The other side of the coin is that people who talk about "API - stability" are entirely wrong. API's don't matter either. You can make - any changes to an API you like - as long as nobody notices. +* From `2025-07-29(1) <https://lore.kernel.org/all/CAHk-=wj2kJRPWx8B09AAtzj+_g+T6UBX11TP0ebs1WJdTtv=WQ@mail.gmail.com/>`_:: - Again, the regression rule is not about documentation, not about - API's, and not about the phase of the moon. + [...] revert like this, it really would be good to link to the problems, so + that when people try to re-enable it, they have the history for why it + didn't work the first time. - It's entirely about "we caused problems for user space that used to work". +* From `2022-05-08 <https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/>`_:: - * From `2017-11-05 - <https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-qsd4Dcw@mail.gmail.com/>`_:: + So I have to once more complain [...] - And our regression rule has never been "behavior doesn't change". - That would mean that we could never make any changes at all. + [...] There's no link to the actual problem the patch fixes. - For example, we do things like add new error handling etc all the - time, which we then sometimes even add tests for in our kselftest - directory. +* From `2022-06-22 <https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/>`_:: - So clearly behavior changes all the time and we don't consider that a - regression per se. + See, *that* link [to the report] would have been useful in the commit. - The rule for a regression for the kernel is that some real user - workflow breaks. Not some test. Not a "look, I used to be able to do - X, now I can't". +On why the "no regressions" rule exists +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - * From `2018-08-03 - <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_:: +* From `2026-01-22 <https://lore.kernel.org/all/CAHk-=wheQNiW_WtHGO7bKkT7Uib-p+ai2JP9M+z+FYcZ6CAxYA@mail.gmail.com/>`_:: - YOU ARE MISSING THE #1 KERNEL RULE. + But the basic rule is: be so good about backwards compatibility that + users never have to worry about upgrading. They should absolutely feel + confident that any kernel-reported problem will either be solved, or + have an easy solution that is appropriate for *them* (ie a + non-technical user shouldn't be expected to be able to do a lot). - We do not regress, and we do not regress exactly because your are 100% wrong. + Because the last thing we want is people holding back from trying new + kernels. - And the reason you state for your opinion is in fact exactly *WHY* you - are wrong. +* From `2024-05-28 <https://lore.kernel.org/all/CAHk-=wgtb7y-bEh7tPDvDWru7ZKQ8-KMjZ53Tsk37zsPPdwXbA@mail.gmail.com/>`_:: - Your "good reasons" are pure and utter garbage. + I introduced that "no regressions" rule something like two decades + ago, because people need to be able to update their kernel without + fear of something they relied on suddenly stopping to work. - The whole point of "we do not regress" is so that people can upgrade - the kernel and never have to worry about it. +* From `2018-08-03 <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_:: - > Kernel had a bug which has been fixed + The whole point of "we do not regress" is so that people can upgrade + the kernel and never have to worry about it. - That is *ENTIRELY* immaterial. + [...] - Guys, whether something was buggy or not DOES NOT MATTER. + Because the only thing that matters IS THE USER. - Why? +* From `2017-10-26(1) <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_:: - Bugs happen. That's a fact of life. Arguing that "we had to break - something because we were fixing a bug" is completely insane. We fix - tens of bugs every single day, thinking that "fixing a bug" means that - we can break something is simply NOT TRUE. + If the kernel used to work for you, the rule is that it continues to work + for you. - So bugs simply aren't even relevant to the discussion. They happen, - they get found, they get fixed, and it has nothing to do with "we - break users". + [...] - Because the only thing that matters IS THE USER. + People should basically always feel like they can update their kernel + and simply not have to worry about it. - How hard is that to understand? + I refuse to introduce "you can only update the kernel if you also + update that other program" kind of limitations. If the kernel used to + work for you, the rule is that it continues to work for you. - Anybody who uses "but it was buggy" as an argument is entirely missing - the point. As far as the USER was concerned, it wasn't buggy - it - worked for him/her. +On exceptions to the "no regressions" rule +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Maybe it worked *because* the user had taken the bug into account, - maybe it worked because the user didn't notice - again, it doesn't - matter. It worked for the user. +* From `2026-01-22 <https://lore.kernel.org/all/CAHk-=wheQNiW_WtHGO7bKkT7Uib-p+ai2JP9M+z+FYcZ6CAxYA@mail.gmail.com/>`_:: - Breaking a user workflow for a "bug" is absolutely the WORST reason - for breakage you can imagine. + There are _very_ few exceptions to that rule, the main one being "the + problem was a fundamental huge and gaping security issue and we *had* to + make that change, and we couldn't even make your limited use-case just + continue to work". - It's basically saying "I took something that worked, and I broke it, - but now it's better". Do you not see how f*cking insane that statement - is? + The other exception is "the problem was reported years after it was + introduced, and now most people rely on the new behavior". - And without users, your program is not a program, it's a pointless - piece of code that you might as well throw away. + [...] - Seriously. This is *why* the #1 rule for kernel development is "we - don't break users". Because "I fixed a bug" is absolutely NOT AN - ARGUMENT if that bug fix broke a user setup. You actually introduced a - MUCH BIGGER bug by "fixing" something that the user clearly didn't - even care about. + Now, if it's one or two users and you can just get them to recompile, + that's one thing. Niche hardware and odd use-cases can sometimes be + solved that way, and regressions can sometimes be fixed by handholding + every single reporter if the reporter is willing and able to change + his or her workflow. - And dammit, we upgrade the kernel ALL THE TIME without upgrading any - other programs at all. It is absolutely required, because flag-days - and dependencies are horribly bad. +* From `2023-04-20 <https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/>`_:: - And it is also required simply because I as a kernel developer do not - upgrade random other tools that I don't even care about as I develop - the kernel, and I want any of my users to feel safe doing the same - time. + And yes, I do consider "regression in an earlier release" to be a + regression that needs fixing. - So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel - without upgrading some other random binary, then we have a problem. + There's obviously a time limit: if that "regression in an earlier + release" was a year or more ago, and just took forever for people to + notice, and it had semantic changes that now mean that fixing the + regression could cause a _new_ regression, then that can cause me to + go "Oh, now the new semantics are what we have to live with". - * From `2021-06-05 - <https://lore.kernel.org/all/CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`_:: +* From `2017-10-26(2) <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_:: - THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS. + There have been exceptions, but they are few and far between, and they + generally have some major and fundamental reasons for having happened, + that were basically entirely unavoidable, and people _tried_hard_ to + avoid them. Maybe we can't practically support the hardware any more + after it is decades old and nobody uses it with modern kernels any + more. Maybe there's a serious security issue with how we did things, + and people actually depended on that fundamentally broken model. Maybe + there was some fundamental other breakage that just _had_ to have a + flag day for very core and fundamental reasons. - Honestly, security people need to understand that "not working" is not - a success case of security. It's a failure case. +On situations where updating something in userspace can resolve regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Yes, "not working" may be secure. But security in that case is *pointless*. +* From `2018-08-03 <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_:: - * From `2011-05-06 (1/3) - <https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-a5VNg2PvmQ@mail.gmail.com/>`_:: + And dammit, we upgrade the kernel ALL THE TIME without upgrading any + other programs at all. It is absolutely required, because flag-days + and dependencies are horribly bad. - Binary compatibility is more important. + And it is also required simply because I as a kernel developer do not + upgrade random other tools that I don't even care about as I develop the + kernel, and I want any of my users to feel safe doing the same time. - And if binaries don't use the interface to parse the format (or just - parse it wrongly - see the fairly recent example of adding uuid's to - /proc/self/mountinfo), then it's a regression. +* From `2017-10-26(3) <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_:: - And regressions get reverted, unless there are security issues or - similar that makes us go "Oh Gods, we really have to break things". + But if something actually breaks, then the change must get fixed or + reverted. And it gets fixed in the *kernel*. Not by saying "well, fix your + user space then". It was a kernel change that exposed the problem, it needs + to be the kernel that corrects for it, because we have a "upgrade in place" + model. We don't have a "upgrade with new user space". - I don't understand why this simple logic is so hard for some kernel - developers to understand. Reality matters. Your personal wishes matter - NOT AT ALL. + And I seriously will refuse to take code from people who do not understand + and honor this very simple rule. - If you made an interface that can be used without parsing the - interface description, then we're stuck with the interface. Theory - simply doesn't matter. + This rule is also not going to change. - You could help fix the tools, and try to avoid the compatibility - issues that way. There aren't that many of them. + And yes, I realize that the kernel is "special" in this respect. I'm proud + of it. - From `2011-05-06 (2/3) - <https://lore.kernel.org/all/BANLkTi=KVXjKR82sqsz4gwjr+E0vtqCmvA@mail.gmail.com/>`_:: +* From `2017-10-26(4) <https://lore.kernel.org/all/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_:: - it's clearly NOT an internal tracepoint. By definition. It's being - used by powertop. + If you break existing user space setups THAT IS A REGRESSION. - From `2011-05-06 (3/3) - <https://lore.kernel.org/all/BANLkTinazaXRdGovYL7rRVp+j6HbJ7pzhg@mail.gmail.com/>`_:: + It's not ok to say "but we'll fix the user space setup". - We have programs that use that ABI and thus it's a regression if they break. + Really. NOT OK. - * From `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8g@mail.gmail.com/>`_:: +On what qualifies as userspace interface, ABI, API, documented interfaces, etc. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - > Now this got me wondering if Debian _unstable_ actually qualifies as a - > standard distro userspace. +* From `2026-01-20 <https://lore.kernel.org/all/CAHk-=wga8Qu0-OSE9VZbviq9GuqwhPhLUXeAt-S7_9+fMCLkKg@mail.gmail.com/>`_:: - Oh, if the kernel breaks some standard user space, that counts. Tons - of people run Debian unstable + So I absolutely detest the whole notion of "ABI changes". It's a + meaningless concept, and I hate it with a passion, [...] - * From `2019-09-15 - <https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>`_:: + The Linux rule for regressions is basically based on the philosophical + question of "If a tree falls in the forest, and nobody is around to + hear it, does it make a sound?". - One _particularly_ last-minute revert is the top-most commit (ignoring - the version change itself) done just before the release, and while - it's very annoying, it's perhaps also instructive. + So the only thing that matters is if something breaks user-*conscious* + behavior. - What's instructive about it is that I reverted a commit that wasn't - actually buggy. In fact, it was doing exactly what it set out to do, - and did it very well. In fact it did it _so_ well that the much - improved IO patterns it caused then ended up revealing a user-visible - regression due to a real bug in a completely unrelated area. + And when that happens, the distinction between "bug fix" and "new + feature" and "ABI change" matters not one whit, and the change needs + to be done differently. - The actual details of that regression are not the reason I point that - revert out as instructive, though. It's more that it's an instructive - example of what counts as a regression, and what the whole "no - regressions" kernel rule means. The reverted commit didn't change any - API's, and it didn't introduce any new bugs. But it ended up exposing - another problem, and as such caused a kernel upgrade to fail for a - user. So it got reverted. + [...] - The point here being that we revert based on user-reported _behavior_, - not based on some "it changes the ABI" or "it caused a bug" concept. - The problem was really pre-existing, and it just didn't happen to - trigger before. The better IO patterns introduced by the change just - happened to expose an old bug, and people had grown to depend on the - previously benign behavior of that old issue. + I just wanted to point out that the argument about whether it's an ABI + change or not is irrelevant. If it turns out that some program - not a test + script, but something with relevance to conscious user expectations ~ + depended on the old broken behavior, then it needs to be done some other + way. - And never fear, we'll re-introduce the fix that improved on the IO - patterns once we've decided just how to handle the fact that we had a - bad interaction with an interface that people had then just happened - to rely on incidental behavior for before. It's just that we'll have - to hash through how to do that (there are no less than three different - patches by three different developers being discussed, and there might - be more coming...). In the meantime, I reverted the thing that exposed - the problem to users for this release, even if I hope it will be - re-introduced (perhaps even backported as a stable patch) once we have - consensus about the issue it exposed. +* From `2026-02-13 <https://lore.kernel.org/all/CAHk-=whY-N8kjm8kiFUV5Ei-8AuYw--EPGD-AR3Pd+5GTx2sAQ@mail.gmail.com/>`_:: - Take-away from the whole thing: it's not about whether you change the - kernel-userspace ABI, or fix a bug, or about whether the old code - "should never have worked in the first place". It's about whether - something breaks existing users' workflow. + > [...] this should not fall under the don't break user space rule [...] - Anyway, that was my little aside on the whole regression thing. Since - it's that "first rule of kernel programming", I felt it is perhaps - worth just bringing it up every once in a while + Note that the rule is about breaking *users*, not breaking user space per + se. [...] + + If some user setup breaks, things need fixing. + + [...] but I want to make it very clear that there are no excuses about "user + space applications". + +* From `2021-09-20(4) <https://lore.kernel.org/all/CAHk-=wi7DB2SJ-wngVvsJ7Ak2cM556Q8437sOXo4EJt2BWPdEg@mail.gmail.com/>`_:: + + [...] a regression is a bit like Schrödinger's cat - if nobody is around + to notice it and it doesn't actually affect any real workload, then you + can treat the regression as if it doesn't exist. + +* From `2020-05-21 <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_:: + + The rules about regressions have never been about any kind of documented + behavior, or where the code lives. + + The rules about regressions are always about "breaks user workflow". + + Users are literally the _only_ thing that matters. + +* From `2019-09-15 <https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>`_:: + + One _particularly_ last-minute revert is the top-most commit (ignoring + the version change itself) done just before the release, and while + it's very annoying, it's perhaps also instructive. + + What's instructive about it is that I reverted a commit that wasn't + actually buggy. In fact, it was doing exactly what it set out to do, + and did it very well. In fact it did it _so_ well that the much + improved IO patterns it caused then ended up revealing a user-visible + regression due to a real bug in a completely unrelated area. + + The actual details of that regression are not the reason I point that + revert out as instructive, though. It's more that it's an instructive + example of what counts as a regression, and what the whole "no + regressions" kernel rule means. + + [...] The reverted commit didn't change any API's, and it didn't introduce + any new bugs. But it ended up exposing another problem, and as such caused + a kernel upgrade to fail for a user. So it got reverted. + + The point here being that we revert based on user-reported _behavior_, not + based on some "it changes the ABI" or "it caused a bug" concept. The problem + was really pre-existing, and it just didn't happen to trigger before. [...] + + Take-away from the whole thing: it's not about whether you change the + kernel-userspace ABI, or fix a bug, or about whether the old code + "should never have worked in the first place". It's about whether + something breaks existing users' workflow. + +* From `2017-11-05 <https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-qsd4Dcw@mail.gmail.com/>`_:: + + And our regression rule has never been "behavior doesn't change". + That would mean that we could never make any changes at all. + +* From `2020-05-21 <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_:: + + No amount of "you shouldn't have used this" or "that behavior was + undefined, it's your own fault your app broke" or "that used to work + simply because of a kernel bug" is at all relevant. + +* From `2021-05-21 <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_:: + + But no, "that was documented to be broken" (whether it's because the code + was in staging or because the man-page said something else) is irrelevant. + If staging code is so useful that people end up using it, that means that + it's basically regular kernel code with a flag saying "please clean this + up". + + [...] + + The other side of the coin is that people who talk about "API stability" are + entirely wrong. API's don't matter either. You can make any changes to an + API you like - as long as nobody notices. + + Again, the regression rule is not about documentation, not about API's, and + not about the phase of the moon. + +* From `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8g@mail.gmail.com/>`_:: + + > Now this got me wondering if Debian _unstable_ actually qualifies as a + > standard distro userspace. + + Oh, if the kernel breaks some standard user space, that counts. Tons + of people run Debian unstable + +* From `2011-05-06 <https://lore.kernel.org/all/BANLkTi=KVXjKR82sqsz4gwjr+E0vtqCmvA@mail.gmail.com/>`_:: + + It's clearly NOT an internal tracepoint. By definition. It's being + used by powertop. + +On regressions noticed by users or test-suites/CIs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* From `2026-01-22 <https://lore.kernel.org/all/CAHk-=wheQNiW_WtHGO7bKkT7Uib-p+ai2JP9M+z+FYcZ6CAxYA@mail.gmail.com/>`_:: + + Users complaining is the only real line in the end. + + [...] a test-suite complaining is then often a *very* good indication that + maybe users will hit some problem, and test suite issues should be taken + very seriously [...] + + But a test-suite error isn't necessarily where you have to draw the + line - it's a big red flag [...] + +* From `2024-29-01 <https://lore.kernel.org/all/CAHk-=wg8BrZEzjJ5kUyZzHPZmFqH6ooMN1gRBCofxxCfucgjaw@mail.gmail.com/>`_:: + + The "no regressions" rule is not about made-up "if I do this, behavior + changes". + + The "no regressions" rule is about *users*. + + If you have an actual user that has been doing insane things, and we + change something, and now the insane thing no longer works, at that + point it's a regression, and we'll sigh, and go "Users are insane" and + have to fix it. + + But if you have some random test that now behaves differently, it's + not a regression. It's a *warning* sign, sure: tests are useful. + +On accepting when a regression occurred +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* From `2026-01-22 <https://lore.kernel.org/all/CAHk-=wheQNiW_WtHGO7bKkT7Uib-p+ai2JP9M+z+FYcZ6CAxYA@mail.gmail.com/>`_:: + + But starting to argue about users reporting breaking changes is + basically the final line for me. I have a couple of people that I have + in my spam block-list and refuse to have anything to do with, and they + have generally been about exactly that. + + Note how it's not about making mistakes and _causing_ the regression. + That's normal. That's development. But then arguing about it is a + no-no. + +* From `2024-06-23 <https://lore.kernel.org/all/CAHk-=wi_KMO_rJ6OCr8mAWBRg-irziM=T9wxGC+J1VVoQb39gw@mail.gmail.com/>`_:: + + We don't introduce regressions and then blame others. + + There's a very clear rule in kernel development: things that break + other things ARE NOT FIXES. + + EVER. + + They get reverted, or the thing they broke gets fixed. + +* From `2021-06-05 <https://lore.kernel.org/all/CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`_:: + + THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS. + + Honestly, security people need to understand that "not working" is not + a success case of security. It's a failure case. + + Yes, "not working" may be secure. But security in that case is *pointless*. + +* From `2017-10-26(5) <https://lore.kernel.org/lkml/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_:: + + [...] when regressions *do* occur, we admit to them and fix them, instead of + blaming user space. + + The fact that you have apparently been denying the regression now for + three weeks means that I will revert, and I will stop pulling apparmor + requests until the people involved understand how kernel development + is done. + +On back-and-forth +~~~~~~~~~~~~~~~~~ + +* From `2024-05-28 <https://lore.kernel.org/all/CAHk-=wgtb7y-bEh7tPDvDWru7ZKQ8-KMjZ53Tsk37zsPPdwXbA@mail.gmail.com/>`_:: + + The "no regressions" rule is that we do not introduce NEW bugs. + + It *literally* came about because we had an endless dance of "fix two + bugs, introduce one new one", and that then resulted in a system that + you cannot TRUST. + +* From `2021-09-20(1) <https://lore.kernel.org/all/CAHk-=wi7DB2SJ-wngVvsJ7Ak2cM556Q8437sOXo4EJt2BWPdEg@mail.gmail.com/>`_:: + + And the thing that makes regressions special is that back when I + wasn't so strict about these things, we'd end up in endless "seesaw + situations" where somebody would fix something, it would break + something else, then that something else would break, and it would + never actually converge on anything reliable at all. + +* From `2015-08-13 <https://lore.kernel.org/all/CA+55aFxk8-BsiKwr_S-c+4G6wihKPQVMLE34H9wOZpeua6W9+Q@mail.gmail.com/>`_:: + + The strict policy of no regressions actually originally started mainly wrt + suspend/resume issues, where the "fix one machine, break another" kind of + back-and-forth caused endless problems, and meant that we didn't actually + necessarily make any forward progress, just moving a problem around. + +On changes with a risk of causing regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* From `2023-06-02 <https://lore.kernel.org/all/CAHk-=wgyAGUMHmQM-5Eb556z5xiHZB7cF05qjrtUH4F7P-1rSA@mail.gmail.com/>`_:: + + So what I think you should do is to fix the bug right, with a clean + patch, and no crazy hacks. That is something we can then apply and + test. All the while knowing full well that "uhhuh, this is a visible + change, we may have to revert it". + + If then some *real* load ends up showing a regression, we may just be + screwed. Our current behavior may be buggy, but we have the rule that + once user space depends on kernel bugs, they become features pretty + much by definition, however much we might dislike it. + +On in-kernel workarounds to avoid regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* From `2017-10-26(6) <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_:: + + Behavioral changes happen, and maybe we don't even support some + feature any more. There's a number of fields in /proc/<pid>/stat that + are printed out as zeroes, simply because they don't even *exist* in + the kernel any more, or because showing them was a mistake (typically + an information leak). But the numbers got replaced by zeroes, so that + the code that used to parse the fields still works. The user might not + see everything they used to see, and so behavior is clearly different, + but things still _work_, even if they might no longer show sensitive + (or no longer relevant) information. + +On regressions caused by bugfixes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* From `2018-08-03 <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_:: + + > Kernel had a bug which has been fixed + + That is *ENTIRELY* immaterial. + + Guys, whether something was buggy or not DOES NOT MATTER. + + [...] + + It's basically saying "I took something that worked, and I broke it, + but now it's better". Do you not see how f*cking insane that statement + is? + +On internal API changes +~~~~~~~~~~~~~~~~~~~~~~~ + +* From `2017-10-26(7) <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_:: + + We do API breakage _inside_ the kernel all the time. We will fix + internal problems by saying "you now need to do XYZ", but then it's + about internal kernel API's, and the people who do that then also + obviously have to fix up all the in-kernel users of that API. Nobody + can say "I now broke the API you used, and now _you_ need to fix it + up". Whoever broke something gets to fix it too. + +On regressions only found after a long time +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* From `2024-03-28 <https://lore.kernel.org/all/CAHk-=wgFuoHpMk_Z_R3qMXVDgq0N1592+bABkyGjwwSL4zBtHA@mail.gmail.com/>`_:: + + I'm definitely not reverting a patch from almost a decade ago as a + regression. + + If it took that long to find, it can't be that critical of a regression. + + So yes, let's treat it as a regular bug. + +On testing regressions fixes in linux-next +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* On `maintainers summit 2024 <https://lwn.net/Articles/990599/>`_:: + + So running fixes though linux-next is just a waste of time. + +On a few other aspects related to regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* From `2025-07-29(2) <https://lore.kernel.org/all/CAHk-=wjj9DvOZtmTkoLtyfHmy5mNKy6q_96d9=4FUEDXre=cww@mail.gmail.com/>`_ + [which `is not quite a regression, but a huge inconvenience <https://lore.kernel.org/all/CAHk-=wgO0Rx2LcYT4f75Xs46orbJ4JxO2jbAFQnVKDYAjV5HeQ@mail.gmail.com/>`_]:: + + I no longer have sound. + + I also suspect that it's purely because "make oldconfig" doesn't work, + and probably turned off my old Intel HDA settings. Or something. + + Renaming config parameters is *bad*. I've harped on the Kconfig phase + of the kernel build probably being our nastiest point, and a real pain + point to people getting involved with development simply because + building your own kernel can be so daunting with hundreds of fairly + esoteric questions. .. end-of-content diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst index 976391cec528..3d72ad25fc6a 100644 --- a/Documentation/process/maintainer-handbooks.rst +++ b/Documentation/process/maintainer-handbooks.rst @@ -1,7 +1,5 @@ .. SPDX-License-Identifier: GPL-2.0 -.. _maintainer_handbooks_main: - Subsystem and maintainer tree specific development process notes ================================================================ diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index 6bce4507d5d3..bda93b459a05 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -479,8 +479,14 @@ netdevsim ``netdevsim`` is a test driver which can be used to exercise driver configuration APIs without requiring capable hardware. -Mock-ups and tests based on ``netdevsim`` are strongly encouraged when -adding new APIs, but ``netdevsim`` in itself is **not** considered +Mock-ups and tests based on ``netdevsim`` are encouraged when +adding new APIs with complex logic in the stack. The tests should +be written so that they can run both against ``netdevsim`` and a real +device (see ``tools/testing/selftests/drivers/net/README.rst``). +``netdevsim``-only tests should focus on testing corner cases +and failure paths in the core which are hard to exercise with a real driver. + +``netdevsim`` in itself is **not** considered a use case/user. You must also implement the new APIs in a real driver. We give no guarantees that ``netdevsim`` won't change in the future @@ -545,10 +551,12 @@ helpful tips please see :ref:`development_advancedtopics_reviews`. It's safe to assume that netdev maintainers know the community and the level of expertise of the reviewers. The reviewers should not be concerned about -their comments impeding or derailing the patch flow. +their comments impeding or derailing the patch flow. A Reviewed-by tag +is understood to mean "I have reviewed this code to the best of my ability" +rather than "I can attest this code is correct". -Less experienced reviewers are highly encouraged to do more in-depth -review of submissions and not focus exclusively on trivial or subjective +Reviewers are highly encouraged to do more in-depth review of submissions +and not focus exclusively on process issues, trivial or subjective matters like code formatting, tags etc. Testimonials / feedback diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst index bfe877a1a7e4..652dfbe64102 100644 --- a/Documentation/process/maintainer-pgp-guide.rst +++ b/Documentation/process/maintainer-pgp-guide.rst @@ -897,6 +897,8 @@ the new default in GnuPG v2). To set it, add (or modify) the trust-model tofu+pgp +.. _kernel_org_trust_repository: + Using the kernel.org web of trust repository -------------------------------------------- diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst index 41d5855700cd..b2b14439be22 100644 --- a/Documentation/process/maintainer-tip.rst +++ b/Documentation/process/maintainer-tip.rst @@ -352,7 +352,7 @@ following tag ordering scheme: Changelog text starts here.... so the authorship is preserved. The 'From:' line has to be followed - by a empty newline. If that 'From:' line is missing, then the patch + by an empty newline. If that 'From:' line is missing, then the patch would be attributed to the person who sent (transported, handled) it. The 'From:' line is automatically removed when the patch is applied and does not show up in the final git changelog. It merely affects diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst index c0cf93e11565..27b028e85861 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -5,8 +5,138 @@ Security bugs Linux kernel developers take security very seriously. As such, we'd like to know when a security bug is found so that it can be fixed and -disclosed as quickly as possible. Please report security bugs to the -Linux kernel security team. +disclosed as quickly as possible. + +Preparing your report +--------------------- + +Like with any bug report, a security bug report requires a lot of analysis work +from the developers, so the more information you can share about the issue, the +better. Please review the procedure outlined in +Documentation/admin-guide/reporting-issues.rst if you are unclear about what +information is helpful. The following information are absolutely necessary in +**any** security bug report: + + * **affected kernel version range**: with no version indication, your report + will not be processed. A significant part of reports are for bugs that + have already been fixed, so it is extremely important that vulnerabilities + are verified on recent versions (development tree or latest stable + version), at least by verifying that the code has not changed since the + version where it was detected. + + * **description of the problem**: a detailed description of the problem, with + traces showing its manifestation, and why you consider that the observed + behavior as a problem in the kernel, is necessary. + + * **reproducer**: developers will need to be able to reproduce the problem to + consider a fix as effective. This includes both a way to trigger the issue + and a way to confirm it happens. A reproducer with low complexity + dependencies will be needed (source code, shell script, sequence of + instructions, file-system image etc). Binary-only executables are not + accepted. Working exploits are extremely helpful and will not be released + without consent from the reporter, unless they are already public. By + definition if an issue cannot be reproduced, it is not exploitable, thus it + is not a security bug. + + * **conditions**: if the bug depends on certain configuration options, + sysctls, permissions, timing, code modifications etc, these should be + indicated. + +In addition, the following information are highly desirable: + + * **suspected location of the bug**: the file names and functions where the + bug is suspected to be present are very important, at least to help forward + the report to the appropriate maintainers. When not possible (for example, + "system freezes each time I run this command"), the security team will help + identify the source of the bug. + + * **a proposed fix**: bug reporters who have analyzed the cause of a bug in + the source code almost always have an accurate idea on how to fix it, + because they spent a long time studying it and its implications. Proposing + a tested fix will save maintainers a lot of time, even if the fix ends up + not being the right one, because it helps understand the bug. When + proposing a tested fix, please always format it in a way that can be + immediately merged (see Documentation/process/submitting-patches.rst). + This will save some back-and-forth exchanges if it is accepted, and you + will be credited for finding and fixing this issue. Note that in this case + only a ``Signed-off-by:`` tag is needed, without ``Reported-by:`` when the + reporter and author are the same. + + * **mitigations**: very often during a bug analysis, some ways of mitigating + the issue appear. It is useful to share them, as they can be helpful to + keep end users protected during the time it takes them to apply the fix. + +Identifying contacts +-------------------- + +The most effective way to report a security bug is to send it directly to the +affected subsystem's maintainers and Cc: the Linux kernel security team. Do +not send it to a public list at this stage, unless you have good reasons to +consider the issue as being public or trivial to discover (e.g. result of a +widely available automated vulnerability scanning tool that can be repeated by +anyone). + +If you're sending a report for issues affecting multiple parts in the kernel, +even if they're fairly similar issues, please send individual messages (think +that maintainers will not all work on the issues at the same time). The only +exception is when an issue concerns closely related parts maintained by the +exact same subset of maintainers, and these parts are expected to be fixed all +at once by the same commit, then it may be acceptable to report them at once. + +One difficulty for most first-time reporters is to figure the right list of +recipients to send a report to. In the Linux kernel, all official maintainers +are trusted, so the consequences of accidentally including the wrong maintainer +are essentially a bit more noise for that person, i.e. nothing dramatic. As +such, a suitable method to figure the list of maintainers (which kernel +security officers use) is to rely on the get_maintainer.pl script, tuned to +only report maintainers. This script, when passed a file name, will look for +its path in the MAINTAINERS file to figure a hierarchical list of relevant +maintainers. Calling it a first time with the finest level of filtering will +most of the time return a short list of this specific file's maintainers:: + + $ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \ + drivers/example.c + Developer One <dev1@example.com> (maintainer:example driver) + Developer Two <dev2@example.org> (maintainer:example driver) + +These two maintainers should then receive the message. If the command does not +return anything, it means the affected file is part of a wider subsystem, so we +should be less specific:: + + $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c + Developer One <dev1@example.com> (maintainer:example subsystem) + Developer Two <dev2@example.org> (maintainer:example subsystem) + Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL]) + Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL]) + +Here, picking the first, most specific ones, is sufficient. When the list is +long, it is possible to produce a comma-delimited e-mail address list on a +single line suitable for use in the To: field of a mailer like this:: + + $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \ + --no-git-fallback --no-substatus --no-rolestats --no-multiline \ + --pattern-depth 1 drivers/example.c + dev1@example.com, dev2@example.org + +or this for the wider list:: + + $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \ + --no-git-fallback --no-substatus --no-rolestats --no-multiline \ + drivers/example.c + dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org + +If at this point you're still facing difficulties spotting the right +maintainers, **and only in this case**, it's possible to send your report to +the Linux kernel security team only. Your message will be triaged, and you +will receive instructions about whom to contact, if needed. Your message may +equally be forwarded as-is to the relevant maintainers. + +Sending the report +------------------ + +Reports are to be sent over e-mail exclusively. Please use a working e-mail +address, preferably the same that you want to appear in ``Reported-by`` tags +if any. If unsure, send your report to yourself first. The security team and maintainers almost always require additional information beyond what was initially provided in a report and rely on @@ -18,20 +148,12 @@ run additional tests. Reports where the reporter does not respond promptly or cannot effectively discuss their findings may be abandoned if the communication does not quickly improve. -As it is with any bug, the more information provided the easier it -will be to diagnose and fix. Please review the procedure outlined in -'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what -information is helpful. Any exploit code is very helpful and will not -be released without consent from the reporter unless it has already been -made public. - +The report must be sent to maintainers, with the security team in ``Cc:``. The Linux kernel security team can be contacted by email at <security@kernel.org>. This is a private list of security officers -who will help verify the bug report and develop and release a fix. -If you already have a fix, please include it with your report, as -that can speed up the process considerably. It is possible that the -security team will bring in extra help from area maintainers to -understand and fix the security vulnerability. +who will help verify the bug report and assist developers working on a fix. +It is possible that the security team will bring in extra help from area +maintainers to understand and fix the security vulnerability. Please send **plain text** emails without attachments where possible. It is much harder to have a context-quoted discussion about a complex @@ -42,7 +164,9 @@ reproduction steps, and follow it with a proposed fix, all in plain text. Markdown, HTML and RST formatted reports are particularly frowned upon since they're quite hard to read for humans and encourage to use dedicated viewers, sometimes online, which by definition is not acceptable for a confidential -security report. +security report. Note that some mailers tend to mangle formatting of plain +text by default, please consult Documentation/process/email-clients.rst for +more info. Disclosure and embargoed information ------------------------------------ diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index e69d19ad658f..d7290e208e72 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -23,7 +23,7 @@ easier. Some subsystems and maintainer trees have additional information about their workflow and expectations, see -:ref:`Documentation/process/maintainer-handbooks.rst <maintainer_handbooks_main>`. +Documentation/process/maintainer-handbooks.rst. Obtain a current source tree ---------------------------- @@ -634,6 +634,16 @@ bugzilla.kernel.org is a public place in this sense, but email addresses used there are private; so do not expose them in tags, unless the person used them in earlier contributions. +Using Assisted-by: +------------------ + +If you used any sort of advanced coding tool in the creation of your patch, +you need to acknowledge that use by adding an Assisted-by tag. Failure to +do so may impede the acceptance of your work. Please see +Documentation/process/coding-assistants.rst for details regarding the +acknowledgment of coding assistants. + + .. _the_canonical_patch_format: The canonical patch format diff --git a/Documentation/rust/general-information.rst b/Documentation/rust/general-information.rst index 6146b49b6a98..09234bed272c 100644 --- a/Documentation/rust/general-information.rst +++ b/Documentation/rust/general-information.rst @@ -157,5 +157,5 @@ numerical comparisons, one may define a new Kconfig symbol: .. code-block:: kconfig - config RUSTC_VERSION_MIN_107900 - def_bool y if RUSTC_VERSION >= 107900 + config RUSTC_HAS_SPAN_FILE + def_bool RUSTC_VERSION >= 108800 diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst index 152289f0bed2..a6ec3fa94d33 100644 --- a/Documentation/rust/quick-start.rst +++ b/Documentation/rust/quick-start.rst @@ -57,8 +57,8 @@ of the box, e.g.:: Gentoo Linux ************ -Gentoo Linux (and especially the testing branch) provides recent Rust releases -and thus it should generally work out of the box, e.g.:: +Gentoo Linux provides recent Rust releases and thus it should generally work out +of the box, e.g.:: USE='rust-src rustfmt clippy' emerge dev-lang/rust dev-util/bindgen @@ -68,8 +68,8 @@ and thus it should generally work out of the box, e.g.:: Nix *** -Nix (unstable channel) provides recent Rust releases and thus it should -generally work out of the box, e.g.:: +Nix provides recent Rust releases and thus it should generally work out of the +box, e.g.:: { pkgs ? import <nixpkgs> {} }: pkgs.mkShell { @@ -84,16 +84,13 @@ openSUSE openSUSE Slowroll and openSUSE Tumbleweed provide recent Rust releases and thus they should generally work out of the box, e.g.:: - zypper install rust rust1.79-src rust-bindgen clang + zypper install rust rust-src rust-bindgen clang Ubuntu ****** -25.04 -~~~~~ - -The latest Ubuntu releases provide recent Rust releases and thus they should +Ubuntu 25.10 and 26.04 LTS provide recent Rust releases and thus they should generally work out of the box, e.g.:: apt install rustc rust-src bindgen rustfmt rust-clippy @@ -112,33 +109,33 @@ Though Ubuntu 24.04 LTS and older versions still provide recent Rust releases, they require some additional configuration to be set, using the versioned packages, e.g.:: - apt install rustc-1.80 rust-1.80-src bindgen-0.65 rustfmt-1.80 \ - rust-1.80-clippy - ln -s /usr/lib/rust-1.80/bin/rustfmt /usr/bin/rustfmt-1.80 - ln -s /usr/lib/rust-1.80/bin/clippy-driver /usr/bin/clippy-driver-1.80 + apt install rustc-1.85 rust-1.85-src bindgen-0.71 rustfmt-1.85 \ + rust-1.85-clippy + ln -s /usr/lib/rust-1.85/bin/rustfmt /usr/bin/rustfmt-1.85 + ln -s /usr/lib/rust-1.85/bin/clippy-driver /usr/bin/clippy-driver-1.85 None of these packages set their tools as defaults; therefore they should be specified explicitly, e.g.:: - make LLVM=1 RUSTC=rustc-1.80 RUSTDOC=rustdoc-1.80 RUSTFMT=rustfmt-1.80 \ - CLIPPY_DRIVER=clippy-driver-1.80 BINDGEN=bindgen-0.65 + make LLVM=1 RUSTC=rustc-1.85 RUSTDOC=rustdoc-1.85 RUSTFMT=rustfmt-1.85 \ + CLIPPY_DRIVER=clippy-driver-1.85 BINDGEN=bindgen-0.71 -Alternatively, modify the ``PATH`` variable to place the Rust 1.80 binaries +Alternatively, modify the ``PATH`` variable to place the Rust 1.85 binaries first and set ``bindgen`` as the default, e.g.:: - PATH=/usr/lib/rust-1.80/bin:$PATH + PATH=/usr/lib/rust-1.85/bin:$PATH update-alternatives --install /usr/bin/bindgen bindgen \ - /usr/bin/bindgen-0.65 100 - update-alternatives --set bindgen /usr/bin/bindgen-0.65 + /usr/bin/bindgen-0.71 100 + update-alternatives --set bindgen /usr/bin/bindgen-0.71 -``RUST_LIB_SRC`` needs to be set when using the versioned packages, e.g.:: +``RUST_LIB_SRC`` may need to be set when using the versioned packages, e.g.:: - RUST_LIB_SRC=/usr/src/rustc-$(rustc-1.80 --version | cut -d' ' -f2)/library + RUST_LIB_SRC=/usr/src/rustc-$(rustc-1.85 --version | cut -d' ' -f2)/library For convenience, ``RUST_LIB_SRC`` can be exported to the global environment. -In addition, ``bindgen-0.65`` is available in newer releases (24.04 LTS and -24.10), but it may not be available in older ones (20.04 LTS and 22.04 LTS), +In addition, ``bindgen-0.71`` is available in newer releases (24.04 LTS), +but it may not be available in older ones (20.04 LTS and 22.04 LTS), thus ``bindgen`` may need to be built manually (please see below). @@ -355,12 +352,3 @@ Hacking To dive deeper, take a look at the source code of the samples at ``samples/rust/``, the Rust support code under ``rust/`` and the ``Rust hacking`` menu under ``Kernel hacking``. - -If GDB/Binutils is used and Rust symbols are not getting demangled, the reason -is the toolchain does not support Rust's new v0 mangling scheme yet. -There are a few ways out: - -- Install a newer release (GDB >= 10.2, Binutils >= 2.36). - -- Some versions of GDB (e.g. vanilla GDB 10.1) are able to use - the pre-demangled names embedded in the debug info (``CONFIG_DEBUG_INFO``). diff --git a/Documentation/scheduler/sched-deadline.rst b/Documentation/scheduler/sched-deadline.rst index ec543a12f848..3ad93cd7b59a 100644 --- a/Documentation/scheduler/sched-deadline.rst +++ b/Documentation/scheduler/sched-deadline.rst @@ -628,10 +628,21 @@ Deadline Task Scheduling * the new scheduling related syscalls that manipulate it, i.e., sched_setattr() and sched_getattr() are implemented. - For debugging purposes, the leftover runtime and absolute deadline of a - SCHED_DEADLINE task can be retrieved through /proc/<pid>/sched (entries - dl.runtime and dl.deadline, both values in ns). A programmatic way to - retrieve these values from production code is under discussion. + The leftover runtime and absolute deadline of a SCHED_DEADLINE task can be + read using the sched_getattr() syscall, setting the last syscall parameter + flags to the SCHED_GETATTR_FLAG_DL_DYNAMIC=1 value. This updates the + runtime left, converts the absolute deadline in CLOCK_MONOTONIC reference, + then returns these parameters to user-space. The absolute deadline is + returned as the number of nanoseconds since the CLOCK_MONOTONIC time + reference (boot instant), as a u64 in the sched_deadline field of sched_attr, + which can represent nearly 585 years since boot time (calling sched_getattr() + with flags=0 causes retrieval of the static parameters instead). + + For debugging purposes, these parameters can also be retrieved through + /proc/<pid>/sched (entries dl.runtime and dl.deadline, both values in ns), + but: this is highly inefficient; the returned runtime left is not updated as + done by sched_getattr(); the deadline is provided in kernel rq_clock time + reference, that is not directly usable from user-space. 4.3 Default behavior @@ -700,7 +711,8 @@ Deadline Task Scheduling 5.2 Using cgroup v2 cpuset controller ------------------------------------- - Assuming the cgroup v2 root is mounted at ``/sys/fs/cgroup``. + Assuming the cgroup v2 root is mounted at ``/sys/fs/cgroup``, an example of a + simple configuration (pin a -deadline task to CPU0) follows:: cd /sys/fs/cgroup echo '+cpuset' > cgroup.subtree_control diff --git a/Documentation/scheduler/sched-design-CFS.rst b/Documentation/scheduler/sched-design-CFS.rst index b574a2644c77..03998f6c8f9c 100644 --- a/Documentation/scheduler/sched-design-CFS.rst +++ b/Documentation/scheduler/sched-design-CFS.rst @@ -183,9 +183,8 @@ This is the (partial) list of the hooks: - yield_task(...) - This function is basically just a dequeue followed by an enqueue, unless the - compat_yield sysctl is turned on; in that case, it places the scheduling - entity at the right-most end of the red-black tree. + This function yields the CPU by moving the currently running task's position back + in the runqueue, so that other runnable tasks get scheduled first. - wakeup_preempt(...) diff --git a/Documentation/scheduler/sched-ext.rst b/Documentation/scheduler/sched-ext.rst index d74c2c2b9ef3..03d595d178ea 100644 --- a/Documentation/scheduler/sched-ext.rst +++ b/Documentation/scheduler/sched-ext.rst @@ -93,6 +93,55 @@ scheduler has been loaded): # cat /sys/kernel/sched_ext/enable_seq 1 +Each running scheduler also exposes a per-scheduler ``events`` file under +``/sys/kernel/sched_ext/<scheduler-name>/events`` that tracks diagnostic +counters. Each counter occupies one ``name value`` line: + +.. code-block:: none + + # cat /sys/kernel/sched_ext/simple/events + SCX_EV_SELECT_CPU_FALLBACK 0 + SCX_EV_DISPATCH_LOCAL_DSQ_OFFLINE 0 + SCX_EV_DISPATCH_KEEP_LAST 123 + SCX_EV_ENQ_SKIP_EXITING 0 + SCX_EV_ENQ_SKIP_MIGRATION_DISABLED 0 + SCX_EV_REENQ_IMMED 0 + SCX_EV_REENQ_LOCAL_REPEAT 0 + SCX_EV_REFILL_SLICE_DFL 456789 + SCX_EV_BYPASS_DURATION 0 + SCX_EV_BYPASS_DISPATCH 0 + SCX_EV_BYPASS_ACTIVATE 0 + SCX_EV_INSERT_NOT_OWNED 0 + SCX_EV_SUB_BYPASS_DISPATCH 0 + +The counters are described in ``kernel/sched/ext_internal.h``; briefly: + +* ``SCX_EV_SELECT_CPU_FALLBACK``: ops.select_cpu() returned a CPU unusable by + the task and the core scheduler silently picked a fallback CPU. +* ``SCX_EV_DISPATCH_LOCAL_DSQ_OFFLINE``: a local-DSQ dispatch was redirected + to the global DSQ because the target CPU went offline. +* ``SCX_EV_DISPATCH_KEEP_LAST``: a task continued running because no other + task was available (only when ``SCX_OPS_ENQ_LAST`` is not set). +* ``SCX_EV_ENQ_SKIP_EXITING``: an exiting task was dispatched to the local DSQ + directly, bypassing ops.enqueue() (only when ``SCX_OPS_ENQ_EXITING`` is not set). +* ``SCX_EV_ENQ_SKIP_MIGRATION_DISABLED``: a migration-disabled task was + dispatched to its local DSQ directly (only when + ``SCX_OPS_ENQ_MIGRATION_DISABLED`` is not set). +* ``SCX_EV_REENQ_IMMED``: a task dispatched with ``SCX_ENQ_IMMED`` was + re-enqueued because the target CPU was not available for immediate execution. +* ``SCX_EV_REENQ_LOCAL_REPEAT``: a reenqueue of the local DSQ triggered + another reenqueue; recurring counts indicate incorrect ``SCX_ENQ_REENQ`` + handling in the BPF scheduler. +* ``SCX_EV_REFILL_SLICE_DFL``: a task's time slice was refilled with the + default value (``SCX_SLICE_DFL``). +* ``SCX_EV_BYPASS_DURATION``: total nanoseconds spent in bypass mode. +* ``SCX_EV_BYPASS_DISPATCH``: number of tasks dispatched while in bypass mode. +* ``SCX_EV_BYPASS_ACTIVATE``: number of times bypass mode was activated. +* ``SCX_EV_INSERT_NOT_OWNED``: attempted to insert a task not owned by this + scheduler into a DSQ; such attempts are silently ignored. +* ``SCX_EV_SUB_BYPASS_DISPATCH``: tasks dispatched from sub-scheduler bypass + DSQs (only relevant with ``CONFIG_EXT_SUB_SCHED``). + ``tools/sched_ext/scx_show_state.py`` is a drgn script which shows more detailed information: @@ -228,16 +277,23 @@ The following briefly shows how a waking task is scheduled and executed. scheduler can wake up any cpu using the ``scx_bpf_kick_cpu()`` helper, using ``ops.select_cpu()`` judiciously can be simpler and more efficient. - A task can be immediately inserted into a DSQ from ``ops.select_cpu()`` - by calling ``scx_bpf_dsq_insert()``. If the task is inserted into - ``SCX_DSQ_LOCAL`` from ``ops.select_cpu()``, it will be inserted into the - local DSQ of whichever CPU is returned from ``ops.select_cpu()``. - Additionally, inserting directly from ``ops.select_cpu()`` will cause the - ``ops.enqueue()`` callback to be skipped. - Note that the scheduler core will ignore an invalid CPU selection, for example, if it's outside the allowed cpumask of the task. + A task can be immediately inserted into a DSQ from ``ops.select_cpu()`` + by calling ``scx_bpf_dsq_insert()`` or ``scx_bpf_dsq_insert_vtime()``. + + If the task is inserted into ``SCX_DSQ_LOCAL`` from + ``ops.select_cpu()``, it will be added to the local DSQ of whichever CPU + is returned from ``ops.select_cpu()``. Additionally, inserting directly + from ``ops.select_cpu()`` will cause the ``ops.enqueue()`` callback to + be skipped. + + Any other attempt to store a task in BPF-internal data structures from + ``ops.select_cpu()`` does not prevent ``ops.enqueue()`` from being + invoked. This is discouraged, as it can introduce racy behavior or + inconsistent state. + 2. Once the target CPU is selected, ``ops.enqueue()`` is invoked (unless the task was inserted directly from ``ops.select_cpu()``). ``ops.enqueue()`` can make one of the following decisions: @@ -251,6 +307,61 @@ The following briefly shows how a waking task is scheduled and executed. * Queue the task on the BPF side. + **Task State Tracking and ops.dequeue() Semantics** + + A task is in the "BPF scheduler's custody" when the BPF scheduler is + responsible for managing its lifecycle. A task enters custody when it is + dispatched to a user DSQ or stored in the BPF scheduler's internal data + structures. Custody is entered only from ``ops.enqueue()`` for those + operations. The only exception is dispatching to a user DSQ from + ``ops.select_cpu()``: although the task is not yet technically in BPF + scheduler custody at that point, the dispatch has the same semantic + effect as dispatching from ``ops.enqueue()`` for custody-related + purposes. + + Once ``ops.enqueue()`` is called, the task may or may not enter custody + depending on what the scheduler does: + + * **Directly dispatched to terminal DSQs** (``SCX_DSQ_LOCAL``, + ``SCX_DSQ_LOCAL_ON | cpu``, or ``SCX_DSQ_GLOBAL``): the BPF scheduler + is done with the task - it either goes straight to a CPU's local run + queue or to the global DSQ as a fallback. The task never enters (or + exits) BPF custody, and ``ops.dequeue()`` will not be called. + + * **Dispatch to user-created DSQs** (custom DSQs): the task enters the + BPF scheduler's custody. When the task later leaves BPF custody + (dispatched to a terminal DSQ, picked by core-sched, or dequeued for + sleep/property changes), ``ops.dequeue()`` will be called exactly + once. + + * **Stored in BPF data structures** (e.g., internal BPF queues): the + task is in BPF custody. ``ops.dequeue()`` will be called when it + leaves (e.g., when ``ops.dispatch()`` moves it to a terminal DSQ, or + on property change / sleep). + + When a task leaves BPF scheduler custody, ``ops.dequeue()`` is invoked. + The dequeue can happen for different reasons, distinguished by flags: + + 1. **Regular dispatch**: when a task in BPF custody is dispatched to a + terminal DSQ from ``ops.dispatch()`` (leaving BPF custody for + execution), ``ops.dequeue()`` is triggered without any special flags. + + 2. **Core scheduling pick**: when ``CONFIG_SCHED_CORE`` is enabled and + core scheduling picks a task for execution while it's still in BPF + custody, ``ops.dequeue()`` is called with the + ``SCX_DEQ_CORE_SCHED_EXEC`` flag. + + 3. **Scheduling property change**: when a task property changes (via + operations like ``sched_setaffinity()``, ``sched_setscheduler()``, + priority changes, CPU migrations, etc.) while the task is still in + BPF custody, ``ops.dequeue()`` is called with the + ``SCX_DEQ_SCHED_CHANGE`` flag set in ``deq_flags``. + + **Important**: Once a task has left BPF custody (e.g., after being + dispatched to a terminal DSQ), property changes will not trigger + ``ops.dequeue()``, since the task is no longer managed by the BPF + scheduler. + 3. When a CPU is ready to schedule, it first looks at its local DSQ. If empty, it then looks at the global DSQ. If there still isn't a task to run, ``ops.dispatch()`` is invoked which can use the following two @@ -264,9 +375,9 @@ The following briefly shows how a waking task is scheduled and executed. rather than performing them immediately. There can be up to ``ops.dispatch_max_batch`` pending tasks. - * ``scx_bpf_move_to_local()`` moves a task from the specified non-local + * ``scx_bpf_dsq_move_to_local()`` moves a task from the specified non-local DSQ to the dispatching DSQ. This function cannot be called with any BPF - locks held. ``scx_bpf_move_to_local()`` flushes the pending insertions + locks held. ``scx_bpf_dsq_move_to_local()`` flushes the pending insertions tasks before trying to move from the specified DSQ. 4. After ``ops.dispatch()`` returns, if there are tasks in the local DSQ, @@ -297,8 +408,8 @@ for more information. Task Lifecycle -------------- -The following pseudo-code summarizes the entire lifecycle of a task managed -by a sched_ext scheduler: +The following pseudo-code presents a rough overview of the entire lifecycle +of a task managed by a sched_ext scheduler: .. code-block:: c @@ -311,22 +422,37 @@ by a sched_ext scheduler: ops.runnable(); /* Task becomes ready to run */ - while (task is runnable) { - if (task is not in a DSQ && task->scx.slice == 0) { + while (task_is_runnable(task)) { + if (task is not in a DSQ || task->scx.slice == 0) { ops.enqueue(); /* Task can be added to a DSQ */ + /* Task property change (i.e., affinity, nice, etc.)? */ + if (sched_change(task)) { + ops.dequeue(); /* Exiting BPF scheduler custody */ + ops.quiescent(); + + /* Property change callback, e.g. ops.set_weight() */ + + ops.runnable(); + continue; + } + /* Any usable CPU becomes available */ - ops.dispatch(); /* Task is moved to a local DSQ */ + ops.dispatch(); /* Task is moved to a local DSQ */ + ops.dequeue(); /* Exiting BPF scheduler custody */ } + ops.running(); /* Task starts running on its assigned CPU */ - while (task->scx.slice > 0 && task is runnable) + + while (task_is_runnable(task) && task->scx.slice > 0) { ops.tick(); /* Called every 1/HZ seconds */ - ops.stopping(); /* Task stops running (time slice expires or wait) */ - /* Task's CPU becomes available */ + if (task->scx.slice == 0) + ops.dispatch(); /* task->scx.slice can be refilled */ + } - ops.dispatch(); /* task->scx.slice can be refilled */ + ops.stopping(); /* Task stops running (time slice expires or wait) */ } ops.quiescent(); /* Task releases its assigned CPU (wait) */ @@ -335,6 +461,30 @@ by a sched_ext scheduler: ops.disable(); /* Disable BPF scheduling for the task */ ops.exit_task(); /* Task is destroyed */ +Note that the above pseudo-code does not cover all possible state transitions +and edge cases, to name a few examples: + +* ``ops.dispatch()`` may fail to move the task to a local DSQ due to a racing + property change on that task, in which case ``ops.dispatch()`` will be + retried. + +* The task may be direct-dispatched to a local DSQ from ``ops.enqueue()``, + in which case ``ops.dispatch()`` and ``ops.dequeue()`` are skipped and we go + straight to ``ops.running()``. + +* Property changes may occur at virtually any point during the task's lifecycle, + not just when the task is queued and waiting to be dispatched. For example, + changing a property of a running task will lead to the callback sequence + ``ops.stopping()`` -> ``ops.quiescent()`` -> (property change callback) -> + ``ops.runnable()`` -> ``ops.running()``. + +* A sched_ext task can be preempted by a task from a higher-priority scheduling + class, in which case it will exit the tick-dispatch loop even though it is runnable + and has a non-zero slice. + +See the "Scheduling Cycle" section for a more detailed description of how +a freshly woken up task gets on a CPU. + Where to Look ============= @@ -377,6 +527,25 @@ Where to Look scheduling. Tasks with CPU affinity are direct-dispatched in FIFO order; all others are scheduled in user space by a simple vruntime scheduler. +Module Parameters +================= + +sched_ext exposes two module parameters under the ``sched_ext.`` prefix that +control bypass-mode behaviour. These knobs are primarily for debugging; there +is usually no reason to change them during normal operation. They can be read +and written at runtime (mode 0600) via +``/sys/module/sched_ext/parameters/``. + +``sched_ext.slice_bypass_us`` (default: 5000 µs) + The time slice assigned to all tasks when the scheduler is in bypass mode, + i.e. during BPF scheduler load, unload, and error recovery. Valid range is + 100 µs to 100 ms. + +``sched_ext.bypass_lb_intv_us`` (default: 500000 µs) + The interval at which the bypass-mode load balancer redistributes tasks + across CPUs. Set to 0 to disable load balancing during bypass mode. Valid + range is 0 to 10 s. + ABI Instability =============== diff --git a/Documentation/security/ipe.rst b/Documentation/security/ipe.rst index 4a7d953abcdc..5eb3e6265fbd 100644 --- a/Documentation/security/ipe.rst +++ b/Documentation/security/ipe.rst @@ -18,7 +18,7 @@ strong integrity guarantees over both the executable code, and specific *data files* on the system, that were critical to its function. These specific data files would not be readable unless they passed integrity policy. A mandatory access control system would be present, and -as a result, xattrs would have to be protected. This lead to a selection +as a result, xattrs would have to be protected. This led to a selection of what would provide the integrity claims. At the time, there were two main mechanisms considered that could guarantee integrity for the system with these requirements: @@ -195,7 +195,7 @@ of the policy to apply the minute usermode starts. Generally, that storage can be handled in one of three ways: 1. The policy file(s) live on disk and the kernel loads the policy prior - to an code path that would result in an enforcement decision. + to a code path that would result in an enforcement decision. 2. The policy file(s) are passed by the bootloader to the kernel, who parses the policy. 3. There is a policy file that is compiled into the kernel that is @@ -235,8 +235,8 @@ Updatable, Rebootless Policy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As requirements change over time (vulnerabilities are found in previously -trusted applications, keys roll, etcetera). Updating a kernel to change the -meet those security goals is not always a suitable option, as updates are not +trusted applications, keys roll, etcetera), updating a kernel to meet +those security goals is not always a suitable option, as updates are not always risk-free, and blocking a security update leaves systems vulnerable. This means IPE requires a policy that can be completely updated (allowing revocations of existing policy) from a source external to the kernel (allowing @@ -370,7 +370,7 @@ Simplified Policy: Finally, IPE's policy is designed for sysadmins, not kernel developers. Instead of covering individual LSM hooks (or syscalls), IPE covers operations. This means instead of sysadmins needing to know that the syscalls ``mmap``, ``mprotect``, -``execve``, and ``uselib`` must have rules protecting them, they must simple know +``execve``, and ``uselib`` must have rules protecting them, they must simply know that they want to restrict code execution. This limits the amount of bypasses that could occur due to a lack of knowledge of the underlying system; whereas the maintainers of IPE, being kernel developers can make the correct choice to determine diff --git a/Documentation/security/landlock.rst b/Documentation/security/landlock.rst index 3e4d4d04cfae..c5186526e76f 100644 --- a/Documentation/security/landlock.rst +++ b/Documentation/security/landlock.rst @@ -7,7 +7,7 @@ Landlock LSM: kernel documentation ================================== :Author: Mickaël Salaün -:Date: September 2025 +:Date: March 2026 Landlock's goal is to create scoped access-control (i.e. sandboxing). To harden a whole system, this feature should be available to any process, @@ -89,6 +89,46 @@ this is required to keep access controls consistent over the whole system, and this avoids unattended bypasses through file descriptor passing (i.e. confused deputy attack). +.. _scoped-flags-interaction: + +Interaction between scoped flags and other access rights +-------------------------------------------------------- + +The ``scoped`` flags in &struct landlock_ruleset_attr restrict the +use of *outgoing* IPC from the created Landlock domain, while they +permit reaching out to IPC endpoints *within* the created Landlock +domain. + +In the future, scoped flags *may* interact with other access rights, +e.g. so that abstract UNIX sockets can be allow-listed by name, or so +that signals can be allow-listed by signal number or target process. + +When introducing ``LANDLOCK_ACCESS_FS_RESOLVE_UNIX``, we defined it to +implicitly have the same scoping semantics as a +``LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET`` flag would have: connecting to +UNIX sockets within the same domain (where +``LANDLOCK_ACCESS_FS_RESOLVE_UNIX`` is used) is unconditionally +allowed. + +The reasoning is: + +* Like other IPC mechanisms, connecting to named UNIX sockets in the + same domain should be expected and harmless. (If needed, users can + further refine their Landlock policies with nested domains or by + restricting ``LANDLOCK_ACCESS_FS_MAKE_SOCK``.) +* We reserve the option to still introduce + ``LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET`` in the future. (This would + be useful if we wanted to have a Landlock rule to permit IPC access + to other Landlock domains.) +* But we can postpone the point in time when users have to deal with + two interacting flags visible in the userspace API. (In particular, + it is possible that it won't be needed in practice, in which case we + can avoid the second flag altogether.) +* If we *do* introduce ``LANDLOCK_SCOPE_PATHNAME_UNIX_SOCKET`` in the + future, setting this scoped flag in a ruleset does *not reduce* the + restrictions, because access within the same scope is already + allowed based on ``LANDLOCK_ACCESS_FS_RESOLVE_UNIX``. + Tests ===== diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index 55b845d38236..f75f08763941 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -2376,6 +2376,13 @@ quirk_flags Skip the probe-time interface setup (usb_set_interface, init_pitch, init_sample_rate); redundant with snd_usb_endpoint_prepare() at stream-open time + * bit 27: ``mixer_playback_linear_vol`` + Set linear volume mapping for devices where the playback volume + control value is mapped to voltage (instead of dB) level linearly. + In short: ``x(raw) = (raw - raw_min) / (raw_max - raw_min)``; + ``V(x) = k * x``; ``dB(x) = 20 * log10(x)``. Overrides bit 24 + * bit 28: ``mixer_capture_linear_vol`` + Similar to bit 27 but for capture streams. Overrides bit 25 This module supports multiple devices, autoprobe and hotplugging. diff --git a/Documentation/sphinx-static/custom.css b/Documentation/sphinx-static/custom.css index db24f4344e6c..f91393426a50 100644 --- a/Documentation/sphinx-static/custom.css +++ b/Documentation/sphinx-static/custom.css @@ -40,6 +40,13 @@ li { text-indent: 0em; } dl.function, dl.struct, dl.enum { margin-top: 2em; background-color: #ecf0f3; } /* indent lines 2+ of multi-line function prototypes */ dl.function dt { margin-left: 10em; text-indent: -10em; } +/* + * Preserve C API signatures on one line and apply contained horizontal + * scrolling to prevent them from exceeding their container width and + * breaking page layout. + */ +dl.c { overflow-x: auto; overflow-y: hidden; } +dl.c > dt.sig.sig-object { white-space: nowrap; } dt.sig-object { font-size: larger; } div.kernelindent { margin-left: 2em; margin-right: 4em; } @@ -149,6 +156,25 @@ div.language-selection ul li:hover { background: #dddddd; } +/* + * Let long inline literals in paragraph text wrap as needed to prevent + * overflow. + */ +code.docutils.literal span.pre { + white-space: normal; + overflow-wrap: anywhere; +} + +/* Let rendered reference links in tables wrap when needed. */ +div.body table.docutils a.reference { + overflow-wrap: anywhere; +} + +/* Let long link text wrap instead of forcing overflow. */ +a { + overflow-wrap: anywhere; +} + /* Make xrefs more universally visible */ a.reference, a.reference:hover { border-bottom: none; diff --git a/Documentation/sphinx/translations.py b/Documentation/sphinx/translations.py index 32c2b32b2b5e..a03d4402b4f1 100644 --- a/Documentation/sphinx/translations.py +++ b/Documentation/sphinx/translations.py @@ -25,6 +25,7 @@ all_languages = { 'it_IT': 'Italian', 'ja_JP': 'Japanese', 'ko_KR': 'Korean', + 'pt_BR': 'Portuguese (Brazilian)', 'sp_SP': 'Spanish', } diff --git a/Documentation/sunrpc/xdr/nlm4.x b/Documentation/sunrpc/xdr/nlm4.x new file mode 100644 index 000000000000..0c44a80ef674 --- /dev/null +++ b/Documentation/sunrpc/xdr/nlm4.x @@ -0,0 +1,211 @@ +/* + * This file was extracted by hand from + * https://www.rfc-editor.org/rfc/rfc1813.html . + * + * Note that RFC 1813 is Informational. Its official date of + * publication (June 1995) is before the IETF required its RFCs to + * carry an explicit copyright or other IP ownership notices. + * + * Note also that RFC 1813 does not specify the whole NLM4 protocol. + * In particular, the argument and result types are not present in + * that document, and had to be reverse-engineered. + */ + +/* + * The NLMv4 protocol + */ + +pragma header nlm4; + +/* + * The following definitions are missing in RFC 1813, + * but can be found in the OpenNetworking Network Lock + * Manager protocol: + * + * https://pubs.opengroup.org/onlinepubs/9629799/chap10.htm + */ + +const LM_MAXSTRLEN = 1024; + +const LM_MAXNAMELEN = 1025; + +const MAXNETOBJ_SZ = 1024; + +typedef opaque netobj<MAXNETOBJ_SZ>; + +enum fsh4_mode { + fsm_DN = 0, /* deny none */ + fsm_DR = 1, /* deny read */ + fsm_DW = 2, /* deny write */ + fsm_DRW = 3 /* deny read/write */ +}; + +enum fsh4_access { + fsa_NONE = 0, /* for completeness */ + fsa_R = 1, /* read-only */ + fsa_W = 2, /* write-only */ + fsa_RW = 3 /* read/write */ +}; + +/* + * The following definitions come from the OpenNetworking + * Network Status Monitor protocol: + * + * https://pubs.opengroup.org/onlinepubs/9629799/chap11.htm + */ + +const SM_MAXSTRLEN = 1024; + +/* + * The NLM protocol as extracted from: + * https://tools.ietf.org/html/rfc1813 Appendix II + */ + +typedef unsigned hyper uint64; + +typedef hyper int64; + +typedef unsigned long uint32; + +typedef long int32; + +enum nlm4_stats { + NLM4_GRANTED = 0, + NLM4_DENIED = 1, + NLM4_DENIED_NOLOCKS = 2, + NLM4_BLOCKED = 3, + NLM4_DENIED_GRACE_PERIOD = 4, + NLM4_DEADLCK = 5, + NLM4_ROFS = 6, + NLM4_STALE_FH = 7, + NLM4_FBIG = 8, + NLM4_FAILED = 9 +}; + +pragma big_endian nlm4_stats; + +struct nlm4_holder { + bool exclusive; + int32 svid; + netobj oh; + uint64 l_offset; + uint64 l_len; +}; + +union nlm4_testrply switch (nlm4_stats stat) { + case NLM4_DENIED: + nlm4_holder holder; + default: + void; +}; + +struct nlm4_stat { + nlm4_stats stat; +}; + +struct nlm4_res { + netobj cookie; + nlm4_stat stat; +}; + +struct nlm4_testres { + netobj cookie; + nlm4_testrply stat; +}; + +struct nlm4_lock { + string caller_name<LM_MAXSTRLEN>; + netobj fh; + netobj oh; + int32 svid; + uint64 l_offset; + uint64 l_len; +}; + +struct nlm4_lockargs { + netobj cookie; + bool block; + bool exclusive; + nlm4_lock alock; + bool reclaim; + int32 state; +}; + +struct nlm4_cancargs { + netobj cookie; + bool block; + bool exclusive; + nlm4_lock alock; +}; + +struct nlm4_testargs { + netobj cookie; + bool exclusive; + nlm4_lock alock; +}; + +struct nlm4_unlockargs { + netobj cookie; + nlm4_lock alock; +}; + +struct nlm4_share { + string caller_name<LM_MAXSTRLEN>; + netobj fh; + netobj oh; + fsh4_mode mode; + fsh4_access access; +}; + +struct nlm4_shareargs { + netobj cookie; + nlm4_share share; + bool reclaim; +}; + +struct nlm4_shareres { + netobj cookie; + nlm4_stats stat; + int32 sequence; +}; + +struct nlm4_notify { + string name<LM_MAXNAMELEN>; + int32 state; +}; + +/* + * Argument for the Linux-private SM_NOTIFY procedure + */ +const SM_PRIV_SIZE = 16; + +struct nlm4_notifyargs { + nlm4_notify notify; + opaque private[SM_PRIV_SIZE]; +}; + +program NLM4_PROG { + version NLM4_VERS { + void NLMPROC4_NULL(void) = 0; + nlm4_testres NLMPROC4_TEST(nlm4_testargs) = 1; + nlm4_res NLMPROC4_LOCK(nlm4_lockargs) = 2; + nlm4_res NLMPROC4_CANCEL(nlm4_cancargs) = 3; + nlm4_res NLMPROC4_UNLOCK(nlm4_unlockargs) = 4; + nlm4_res NLMPROC4_GRANTED(nlm4_testargs) = 5; + void NLMPROC4_TEST_MSG(nlm4_testargs) = 6; + void NLMPROC4_LOCK_MSG(nlm4_lockargs) = 7; + void NLMPROC4_CANCEL_MSG(nlm4_cancargs) = 8; + void NLMPROC4_UNLOCK_MSG(nlm4_unlockargs) = 9; + void NLMPROC4_GRANTED_MSG(nlm4_testargs) = 10; + void NLMPROC4_TEST_RES(nlm4_testres) = 11; + void NLMPROC4_LOCK_RES(nlm4_res) = 12; + void NLMPROC4_CANCEL_RES(nlm4_res) = 13; + void NLMPROC4_UNLOCK_RES(nlm4_res) = 14; + void NLMPROC4_GRANTED_RES(nlm4_res) = 15; + void NLMPROC4_SM_NOTIFY(nlm4_notifyargs) = 16; + nlm4_shareres NLMPROC4_SHARE(nlm4_shareargs) = 20; + nlm4_shareres NLMPROC4_UNSHARE(nlm4_shareargs) = 21; + nlm4_res NLMPROC4_NM_LOCK(nlm4_lockargs) = 22; + void NLMPROC4_FREE_ALL(nlm4_notify) = 23; + } = 4; +} = 100021; diff --git a/Documentation/tools/kdoc_ancillary.rst b/Documentation/tools/kdoc_ancillary.rst index 3950d0a3f104..249753744d11 100644 --- a/Documentation/tools/kdoc_ancillary.rst +++ b/Documentation/tools/kdoc_ancillary.rst @@ -21,6 +21,15 @@ Regular expression class handler :undoc-members: +C tokenizer +=========== + +.. automodule:: lib.python.kdoc.c_lex + :members: + :show-inheritance: + :undoc-members: + + Chinese, Japanese and Korean variable fonts handler =================================================== @@ -44,3 +53,11 @@ Python version ancillary methods :members: :show-inheritance: :undoc-members: + +Write output on YAML file +========================= + +.. automodule:: lib.python.kdoc.kdoc_yaml_file + :members: + :show-inheritance: + :undoc-members: diff --git a/Documentation/tools/kdoc_parser.rst b/Documentation/tools/kdoc_parser.rst index 03ee54a1b1cc..55b202173195 100644 --- a/Documentation/tools/kdoc_parser.rst +++ b/Documentation/tools/kdoc_parser.rst @@ -4,6 +4,14 @@ Kernel-doc parser stage ======================= +C replacement rules used by the parser +====================================== + +.. automodule:: lib.python.kdoc.xforms_lists + :members: + :show-inheritance: + :undoc-members: + File handler classes ==================== diff --git a/Documentation/tools/python.rst b/Documentation/tools/python.rst index 1444c1816735..3b7299161f20 100644 --- a/Documentation/tools/python.rst +++ b/Documentation/tools/python.rst @@ -11,3 +11,5 @@ Python libraries feat kdoc kabi + + unittest diff --git a/Documentation/tools/rtla/common_appendix.txt b/Documentation/tools/rtla/common_appendix.txt index 53cae7537537..8c90a02588e7 100644 --- a/Documentation/tools/rtla/common_appendix.txt +++ b/Documentation/tools/rtla/common_appendix.txt @@ -1,5 +1,26 @@ .. SPDX-License-Identifier: GPL-2.0 +SIGINT BEHAVIOR +=============== + +On the first SIGINT, RTLA exits after collecting all outstanding samples up to +the point of receiving the signal. + +When receiving more than one SIGINT, RTLA discards any outstanding samples, and +exits while displaying only samples that have already been processed. + +If SIGINT is received during RTLA cleanup, RTLA exits immediately via +the default signal handler. + +Note: For the purpose of SIGINT behavior, the expiry of duration specified via +the -d/--duration option is treated as equivalent to receiving a SIGINT. For +example, a SIGINT received after duration expired but samples have not been +processed yet will drop any outstanding samples. + +Also note that when using the timerlat tool in BPF mode, samples are processed +in-kernel; RTLA only copies them out to display them to the user. A second +SIGINT does not affect in-kernel sample aggregation. + EXIT STATUS =========== diff --git a/Documentation/tools/rtla/common_timerlat_options.txt b/Documentation/tools/rtla/common_timerlat_options.txt index 07a285fcf7cf..ab159b2cbfe7 100644 --- a/Documentation/tools/rtla/common_timerlat_options.txt +++ b/Documentation/tools/rtla/common_timerlat_options.txt @@ -83,3 +83,15 @@ **Note**: BPF actions require BPF support to be available. If BPF is not available or disabled, the tool falls back to tracefs mode and BPF actions are not supported. + +**--stack-format** *format* + + Adjust the format of the stack trace printed during auto-analysis. + + The supported values for *format* are: + + * **truncate** Print the stack trace up to the first unknown address (default). + * **skip** Skip unknown addresses. + * **full** Print the entire stack trace, including unknown addresses. + + For unknown addresses, the raw pointer is printed. diff --git a/Documentation/tools/rtla/rtla-hwnoise.rst b/Documentation/tools/rtla/rtla-hwnoise.rst index 26512b15fe7b..5930bbca4522 100644 --- a/Documentation/tools/rtla/rtla-hwnoise.rst +++ b/Documentation/tools/rtla/rtla-hwnoise.rst @@ -100,7 +100,7 @@ SEE ALSO **rtla-osnoise**\(1) -Osnoise tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html> +`Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>`__ AUTHOR ====== diff --git a/Documentation/tools/rtla/rtla-osnoise-hist.rst b/Documentation/tools/rtla/rtla-osnoise-hist.rst index 007521c865d9..6ddea2c6d490 100644 --- a/Documentation/tools/rtla/rtla-osnoise-hist.rst +++ b/Documentation/tools/rtla/rtla-osnoise-hist.rst @@ -59,7 +59,7 @@ SEE ALSO ======== **rtla-osnoise**\(1), **rtla-osnoise-top**\(1) -*osnoise* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html> +`Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>`__ AUTHOR ====== diff --git a/Documentation/tools/rtla/rtla-osnoise-top.rst b/Documentation/tools/rtla/rtla-osnoise-top.rst index 6ccadae38945..b91c02ac2bbe 100644 --- a/Documentation/tools/rtla/rtla-osnoise-top.rst +++ b/Documentation/tools/rtla/rtla-osnoise-top.rst @@ -54,7 +54,7 @@ SEE ALSO **rtla-osnoise**\(1), **rtla-osnoise-hist**\(1) -Osnoise tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html> +`Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>`__ AUTHOR ====== diff --git a/Documentation/tools/rtla/rtla-osnoise.rst b/Documentation/tools/rtla/rtla-osnoise.rst index 540d2bf6c152..decd9e11fcf2 100644 --- a/Documentation/tools/rtla/rtla-osnoise.rst +++ b/Documentation/tools/rtla/rtla-osnoise.rst @@ -50,7 +50,7 @@ SEE ALSO ======== **rtla-osnoise-top**\(1), **rtla-osnoise-hist**\(1) -Osnoise tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html> +`Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>`__ AUTHOR ====== diff --git a/Documentation/tools/rtla/rtla-timerlat-hist.rst b/Documentation/tools/rtla/rtla-timerlat-hist.rst index f56fe546411b..dab75677b06e 100644 --- a/Documentation/tools/rtla/rtla-timerlat-hist.rst +++ b/Documentation/tools/rtla/rtla-timerlat-hist.rst @@ -104,7 +104,7 @@ SEE ALSO ======== **rtla-timerlat**\(1), **rtla-timerlat-top**\(1) -*timerlat* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/timerlat-tracer.html> +`Timerlat tracer <https://docs.kernel.org/trace/timerlat-tracer.html>`__ AUTHOR ====== diff --git a/Documentation/tools/rtla/rtla-timerlat-top.rst b/Documentation/tools/rtla/rtla-timerlat-top.rst index 72d85e36c193..05959f1a4661 100644 --- a/Documentation/tools/rtla/rtla-timerlat-top.rst +++ b/Documentation/tools/rtla/rtla-timerlat-top.rst @@ -127,7 +127,7 @@ SEE ALSO -------- **rtla-timerlat**\(1), **rtla-timerlat-hist**\(1) -*timerlat* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/timerlat-tracer.html> +`Timerlat tracer <https://docs.kernel.org/trace/timerlat-tracer.html>`__ AUTHOR ------ diff --git a/Documentation/tools/rtla/rtla-timerlat.rst b/Documentation/tools/rtla/rtla-timerlat.rst index ce9f57e038c3..63718c52aa3f 100644 --- a/Documentation/tools/rtla/rtla-timerlat.rst +++ b/Documentation/tools/rtla/rtla-timerlat.rst @@ -45,7 +45,7 @@ SEE ALSO ======== **rtla-timerlat-top**\(1), **rtla-timerlat-hist**\(1) -*timerlat* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/timerlat-tracer.html> +`Timerlat tracer <https://docs.kernel.org/trace/timerlat-tracer.html>`__ AUTHOR ====== diff --git a/Documentation/tools/rtla/rtla.rst b/Documentation/tools/rtla/rtla.rst index 2a5fb7004ad4..6df1296b8cc1 100644 --- a/Documentation/tools/rtla/rtla.rst +++ b/Documentation/tools/rtla/rtla.rst @@ -21,6 +21,10 @@ results. COMMANDS ======== +**hwnoise** + + Detect and quantify hardware-related noise. + **osnoise** Gives information about the operating system noise (osnoise). @@ -39,7 +43,7 @@ For other options, see the man page for the corresponding command. SEE ALSO ======== -**rtla-osnoise**\(1), **rtla-timerlat**\(1) +**rtla-hwnoise**\(1), **rtla-osnoise**\(1), **rtla-timerlat**\(1) AUTHOR ====== diff --git a/Documentation/tools/rv/index.rst b/Documentation/tools/rv/index.rst index fd42b0017d07..2aaa01c9fe48 100644 --- a/Documentation/tools/rv/index.rst +++ b/Documentation/tools/rv/index.rst @@ -16,3 +16,4 @@ Runtime verification (rv) tool rv-mon-wip rv-mon-wwnr rv-mon-sched + rv-mon-stall diff --git a/Documentation/tools/rv/rv-mon-stall.rst b/Documentation/tools/rv/rv-mon-stall.rst new file mode 100644 index 000000000000..c79d7c2e4dd4 --- /dev/null +++ b/Documentation/tools/rv/rv-mon-stall.rst @@ -0,0 +1,44 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +rv-mon-stall +============ +-------------------- +Stalled task monitor +-------------------- + +:Manual section: 1 + +SYNOPSIS +======== + +**rv mon stall** [*OPTIONS*] + +DESCRIPTION +=========== + +The stalled task (**stall**) monitor is a sample per-task timed monitor that +checks if tasks are scheduled within a defined threshold after they are ready. + +See kernel documentation for further information about this monitor: +<https://docs.kernel.org/trace/rv/monitor_stall.html> + +OPTIONS +======= + +.. include:: common_ikm.rst + +SEE ALSO +======== + +**rv**\(1), **rv-mon**\(1) + +Linux kernel *RV* documentation: +<https://www.kernel.org/doc/html/latest/trace/rv/index.html> + +AUTHOR +====== + +Written by Gabriele Monaco <gmonaco@redhat.com> + +.. include:: common_appendix.rst diff --git a/Documentation/tools/unittest.rst b/Documentation/tools/unittest.rst new file mode 100644 index 000000000000..14a2b2a65236 --- /dev/null +++ b/Documentation/tools/unittest.rst @@ -0,0 +1,24 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +Python unittest +=============== + +Checking consistency of python modules can be complex. Sometimes, it is +useful to define a set of unit tests to help checking them. + +While the actual test implementation is usecase dependent, Python already +provides a standard way to add unit tests by using ``import unittest``. + +Using such class, requires setting up a test suite. Also, the default format +is a little bit ackward. To improve it and provide a more uniform way to +report errors, some unittest classes and functions are defined. + + +Unittest helper module +====================== + +.. automodule:: lib.python.unittest_helper + :members: + :show-inheritance: + :undoc-members: diff --git a/Documentation/trace/debugging.rst b/Documentation/trace/debugging.rst index 4d88c346fc38..bca1710d92bf 100644 --- a/Documentation/trace/debugging.rst +++ b/Documentation/trace/debugging.rst @@ -159,3 +159,22 @@ If setting it from the kernel command line, it is recommended to also disable tracing with the "traceoff" flag, and enable tracing after boot up. Otherwise the trace from the most recent boot will be mixed with the trace from the previous boot, and may make it confusing to read. + +Using a backup instance for keeping previous boot data +------------------------------------------------------ + +It is also possible to record trace data at system boot time by specifying +events with the persistent ring buffer, but in this case the data before the +reboot will be lost before it can be read. This problem can be solved by a +backup instance. From the kernel command line:: + + reserve_mem=12M:4096:trace trace_instance=boot_map@trace,sched,irq trace_instance=backup=boot_map + +On boot up, the previous data in the "boot_map" is copied to the "backup" +instance, and the "sched:*" and "irq:*" events for the current boot are traced +in the "boot_map". Thus the user can read the previous boot data from the "backup" +instance without stopping the trace. + +Note that this "backup" instance is readonly, and will be removed automatically +if you clear the trace data or read out all trace data from the "trace_pipe" +or the "trace_pipe_raw" files. diff --git a/Documentation/trace/events-pci-controller.rst b/Documentation/trace/events-pci-controller.rst new file mode 100644 index 000000000000..cb9f71592973 --- /dev/null +++ b/Documentation/trace/events-pci-controller.rst @@ -0,0 +1,42 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +Subsystem Trace Points: PCI Controller +====================================== + +Overview +======== +The PCI controller tracing system provides tracepoints to monitor controller +level information for debugging purpose. The events normally show up here: + + /sys/kernel/tracing/events/pci_controller + +Cf. include/trace/events/pci_controller.h for the events definitions. + +Available Tracepoints +===================== + +pcie_ltssm_state_transition +--------------------------- + +Monitors PCIe LTSSM state transition including state and rate information +:: + + pcie_ltssm_state_transition "dev: %s state: %s rate: %s\n" + +**Parameters**: + +* ``dev`` - PCIe controller instance +* ``state`` - PCIe LTSSM state +* ``rate`` - PCIe date rate + +**Example Usage**: + +.. code-block:: shell + + # Enable the tracepoint + echo 1 > /sys/kernel/debug/tracing/events/pci_controller/pcie_ltssm_state_transition/enable + + # Monitor events (the following output is generated when a device is linking) + cat /sys/kernel/debug/tracing/trace_pipe + kworker/0:0-9 [000] ..... 5.600221: pcie_ltssm_state_transition: dev: a40000000.pcie state: RCVRY_EQ2 rate: 8.0 GT/s diff --git a/Documentation/trace/histogram-design.rst b/Documentation/trace/histogram-design.rst index ae71b5bf97c6..e92f56ebd0b5 100644 --- a/Documentation/trace/histogram-design.rst +++ b/Documentation/trace/histogram-design.rst @@ -69,7 +69,8 @@ So in this histogram, there's a separate bucket for each pid, and each bucket contains a value for that bucket, counting the number of times sched_waking was called for that pid. -Each histogram is represented by a hist_data struct. +Each histogram is represented by a hist_data struct +(struct hist_trigger_data). To keep track of each key and value field in the histogram, hist_data keeps an array of these fields named fields[]. The fields[] array is @@ -82,7 +83,7 @@ value or not, which the above histogram does not. Each struct hist_field contains a pointer to the ftrace_event_field from the event's trace_event_file along with various bits related to -that such as the size, offset, type, and a hist_field_fn_t function, +that such as the size, offset, type, and a hist field function, which is used to grab the field's data from the ftrace event buffer (in most cases - some hist_fields such as hitcount don't directly map to an event field in the trace buffer - in these cases the function @@ -241,28 +242,33 @@ it, event_hist_trigger() is called. event_hist_trigger() first deals with the key: for each subkey in the key (in the above example, there is just one subkey corresponding to pid), the hist_field that represents that subkey is retrieved from hist_data.fields[] and the -hist_field_fn_t fn() associated with that field, along with the +hist field function associated with that field, along with the field's size and offset, is used to grab that subkey's data from the current trace record. +Note, the hist field function use to be a function pointer in the +hist_field stucture. Due to spectre mitigation, it was converted into +a fn_num and hist_fn_call() is used to call the associated hist field +function that corresponds to the fn_num of the hist_field structure. + Once the complete key has been retrieved, it's used to look that key up in the tracing_map. If there's no tracing_map_elt associated with that key, an empty one is claimed and inserted in the map for the new key. In either case, the tracing_map_elt associated with that key is returned. -Once a tracing_map_elt available, hist_trigger_elt_update() is called. +Once a tracing_map_elt is available, hist_trigger_elt_update() is called. As the name implies, this updates the element, which basically means updating the element's fields. There's a tracing_map_field associated with each key and value in the histogram, and each of these correspond to the key and value hist_fields created when the histogram was created. hist_trigger_elt_update() goes through each value hist_field -and, as for the keys, uses the hist_field's fn() and size and offset +and, as for the keys, uses the hist_field's function and size and offset to grab the field's value from the current trace record. Once it has that value, it simply adds that value to that field's continually-updated tracing_map_field.sum member. Some hist_field -fn()s, such as for the hitcount, don't actually grab anything from the -trace record (the hitcount fn() just increments the counter sum by 1), +functions, such as for the hitcount, don't actually grab anything from the +trace record (the hitcount function just increments the counter sum by 1), but the idea is the same. Once all the values have been updated, hist_trigger_elt_update() is diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index 338bc4d7cfab..5d9bf4694d5d 100644 --- a/Documentation/trace/index.rst +++ b/Documentation/trace/index.rst @@ -55,6 +55,7 @@ applications. events-nmi events-msr events-pci + events-pci-controller boottime-trace histogram histogram-design @@ -91,6 +92,17 @@ interactions. user_events uprobetracer +Remote Tracing +-------------- + +This section covers the framework to read compatible ring-buffers, written by +entities outside of the kernel (most likely firmware or hypervisor) + +.. toctree:: + :maxdepth: 1 + + remotes + Additional Resources -------------------- diff --git a/Documentation/trace/remotes.rst b/Documentation/trace/remotes.rst new file mode 100644 index 000000000000..1f9d764f69aa --- /dev/null +++ b/Documentation/trace/remotes.rst @@ -0,0 +1,66 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +Tracing Remotes +=============== + +:Author: Vincent Donnefort <vdonnefort@google.com> + +Overview +======== +Firmware and hypervisors are black boxes to the kernel. Having a way to see what +they are doing can be useful to debug both. This is where remote tracing buffers +come in. A remote tracing buffer is a ring buffer executed by the firmware or +hypervisor into memory that is memory mapped to the host kernel. This is similar +to how user space memory maps the kernel ring buffer but in this case the kernel +is acting like user space and the firmware or hypervisor is the "kernel" side. +With a trace remote ring buffer, the firmware and hypervisor can record events +for which the host kernel can see and expose to user space. + +Register a remote +================= +A remote must provide a set of callbacks `struct trace_remote_callbacks` whom +description can be found below. Those callbacks allows Tracefs to enable and +disable tracing and events, to load and unload a tracing buffer (a set of +ring-buffers) and to swap a reader page with the head page, which enables +consuming reading. + +.. kernel-doc:: include/linux/trace_remote.h + +Once registered, an instance will appear for this remote in the Tracefs +directory **remotes/**. Buffers can then be read using the usual Tracefs files +**trace_pipe** and **trace**. + +Declare a remote event +====================== +Macros are provided to ease the declaration of remote events, in a similar +fashion to in-kernel events. A declaration must provide an ID, a description of +the event arguments and how to print the event: + +.. code-block:: c + + REMOTE_EVENT(foo, EVENT_FOO_ID, + RE_STRUCT( + re_field(u64, bar) + ), + RE_PRINTK("bar=%lld", __entry->bar) + ); + +Then those events must be declared in a C file with the following: + +.. code-block:: c + + #define REMOTE_EVENT_INCLUDE_FILE foo_events.h + #include <trace/define_remote_events.h> + +This will provide a `struct remote_event remote_event_foo` that can be given to +`trace_remote_register`. + +Registered events appear in the remote directory under **events/**. + +Simple ring-buffer +================== +A simple implementation for a ring-buffer writer can be found in +kernel/trace/simple_ring_buffer.c. + +.. kernel-doc:: include/linux/simple_ring_buffer.h diff --git a/Documentation/trace/rv/deterministic_automata.rst b/Documentation/trace/rv/deterministic_automata.rst index d0638f95a455..7a1c2b20ec72 100644 --- a/Documentation/trace/rv/deterministic_automata.rst +++ b/Documentation/trace/rv/deterministic_automata.rst @@ -11,7 +11,7 @@ where: - *E* is the finite set of events; - x\ :subscript:`0` is the initial state; - X\ :subscript:`m` (subset of *X*) is the set of marked (or final) states. -- *f* : *X* x *E* -> *X* $ is the transition function. It defines the state +- *f* : *X* x *E* -> *X* is the transition function. It defines the state transition in the occurrence of an event from *E* in the state *X*. In the special case of deterministic automata, the occurrence of the event in *E* in a state in *X* has a deterministic next state from *X*. diff --git a/Documentation/trace/rv/hybrid_automata.rst b/Documentation/trace/rv/hybrid_automata.rst new file mode 100644 index 000000000000..f20d489f18c1 --- /dev/null +++ b/Documentation/trace/rv/hybrid_automata.rst @@ -0,0 +1,341 @@ +Hybrid Automata +=============== + +Hybrid automata are an extension of deterministic automata, there are several +definitions of hybrid automata in the literature. The adaptation implemented +here is formally denoted by G and defined as a 7-tuple: + + *G* = { *X*, *E*, *V*, *f*, x\ :subscript:`0`, X\ :subscript:`m`, *i* } + +- *X* is the set of states; +- *E* is the finite set of events; +- *V* is the finite set of environment variables; +- x\ :subscript:`0` is the initial state; +- X\ :subscript:`m` (subset of *X*) is the set of marked (or final) states. +- *f* : *X* x *E* x *C(V)* -> *X* is the transition function. + It defines the state transition in the occurrence of an event from *E* in the + state *X*. Unlike deterministic automata, the transition function also + includes guards from the set of all possible constraints (defined as *C(V)*). + Guards can be true or false with the valuation of *V* when the event occurs, + and the transition is possible only when constraints are true. Similarly to + deterministic automata, the occurrence of the event in *E* in a state in *X* + has a deterministic next state from *X*, if the guard is true. +- *i* : *X* -> *C'(V)* is the invariant assignment function, this is a + constraint assigned to each state in *X*, every state in *X* must be left + before the invariant turns to false. We can omit the representation of + invariants whose value is true regardless of the valuation of *V*. + +The set of all possible constraints *C(V)* is defined according to the +following grammar: + + g = v < c | v > c | v <= c | v >= c | v == c | v != c | g && g | true + +With v a variable in *V* and c a numerical value. + +We define the special case of hybrid automata whose variables grow with uniform +rates as timed automata. In this case, the variables are called clocks. +As the name implies, timed automata can be used to describe real time. +Additionally, clocks support another type of guard which always evaluates to true: + + reset(v) + +The reset constraint is used to set the value of a clock to 0. + +The set of invariant constraints *C'(V)* is a subset of *C(V)* including only +constraint of the form: + + g = v < c | true + +This simplifies the implementation as a clock expiration is a necessary and +sufficient condition for the violation of invariants while still allowing more +complex constraints to be specified as guards. + +It is important to note that any hybrid automaton is a valid deterministic +automaton with additional guards and invariants. Those can only further +constrain what transitions are valid but it is not possible to define +transition functions starting from the same state in *X* and the same event in +*E* but ending up in different states in *X* based on the valuation of *V*. + +Examples +-------- + +Wip as hybrid automaton +~~~~~~~~~~~~~~~~~~~~~~~ + +The 'wip' (wakeup in preemptive) example introduced as a deterministic automaton +can also be described as: + +- *X* = { ``any_thread_running`` } +- *E* = { ``sched_waking`` } +- *V* = { ``preemptive`` } +- x\ :subscript:`0` = ``any_thread_running`` +- X\ :subscript:`m` = {``any_thread_running``} +- *f* = + - *f*\ (``any_thread_running``, ``sched_waking``, ``preemptive==0``) = ``any_thread_running`` +- *i* = + - *i*\ (``any_thread_running``) = ``true`` + +Which can be represented graphically as:: + + | + | + v + #====================# sched_waking;preemptive==0 + H H ------------------------------+ + H any_thread_running H | + H H <-----------------------------+ + #====================# + +In this example, by using the preemptive state of the system as an environment +variable, we can assert this constraint on ``sched_waking`` without requiring +preemption events (as we would in a deterministic automaton), which can be +useful in case those events are not available or not reliable on the system. + +Since all the invariants in *i* are true, we can omit them from the representation. + +Stall model with guards (iteration 1) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As a sample timed automaton we can define 'stall' as: + +- *X* = { ``dequeued``, ``enqueued``, ``running``} +- *E* = { ``enqueue``, ``dequeue``, ``switch_in``} +- *V* = { ``clk`` } +- x\ :subscript:`0` = ``dequeue`` +- X\ :subscript:`m` = {``dequeue``} +- *f* = + - *f*\ (``enqueued``, ``switch_in``, ``clk < threshold``) = ``running`` + - *f*\ (``running``, ``dequeue``) = ``dequeued`` + - *f*\ (``dequeued``, ``enqueue``, ``reset(clk)``) = ``enqueued`` +- *i* = *omitted as all true* + +Graphically represented as:: + + | + | + v + #============================# + H dequeued H <+ + #============================# | + | | + | enqueue; reset(clk) | + v | + +----------------------------+ | + | enqueued | | dequeue + +----------------------------+ | + | | + | switch_in; clk < threshold | + v | + +----------------------------+ | + | running | -+ + +----------------------------+ + +This model imposes that the time between when a task is enqueued (it becomes +runnable) and when the task gets to run must be lower than a certain threshold. +A failure in this model means that the task is starving. +One problem in using guards on the edges in this case is that the model will +not report a failure until the ``switch_in`` event occurs. This means that, +according to the model, it is valid for the task never to run. + +Stall model with invariants (iteration 2) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The first iteration isn't exactly what was intended, we can change the model as: + +- *X* = { ``dequeued``, ``enqueued``, ``running``} +- *E* = { ``enqueue``, ``dequeue``, ``switch_in``} +- *V* = { ``clk`` } +- x\ :subscript:`0` = ``dequeue`` +- X\ :subscript:`m` = {``dequeue``} +- *f* = + - *f*\ (``enqueued``, ``switch_in``) = ``running`` + - *f*\ (``running``, ``dequeue``) = ``dequeued`` + - *f*\ (``dequeued``, ``enqueue``, ``reset(clk)``) = ``enqueued`` +- *i* = + - *i*\ (``enqueued``) = ``clk < threshold`` + +Graphically:: + + | + | + v + #=========================# + H dequeued H <+ + #=========================# | + | | + | enqueue; reset(clk) | + v | + +-------------------------+ | + | enqueued | | + | clk < threshold | | dequeue + +-------------------------+ | + | | + | switch_in | + v | + +-------------------------+ | + | running | -+ + +-------------------------+ + +In this case, we moved the guard as an invariant to the ``enqueued`` state, +this means we not only forbid the occurrence of ``switch_in`` when ``clk`` is +past the threshold but also mark as invalid in case we are *still* in +``enqueued`` after the threshold. This model is effectively in an invalid state +as soon as a task is starving, rather than when the starving task finally runs. + +Hybrid Automaton in C +--------------------- + +The definition of hybrid automata in C is heavily based on the deterministic +automata one. Specifically, we add the set of environment variables and the +constraints (both guards on transitions and invariants on states) as follows. +This is a combination of both iterations of the stall example:: + + /* enum representation of X (set of states) to be used as index */ + enum states { + dequeued, + enqueued, + running, + state_max, + }; + + #define INVALID_STATE state_max + + /* enum representation of E (set of events) to be used as index */ + enum events { + dequeue, + enqueue, + switch_in, + event_max, + }; + + /* enum representation of V (set of environment variables) to be used as index */ + enum envs { + clk, + env_max, + env_max_stored = env_max, + }; + + struct automaton { + char *state_names[state_max]; // X: the set of states + char *event_names[event_max]; // E: the finite set of events + char *env_names[env_max]; // V: the finite set of env vars + unsigned char function[state_max][event_max]; // f: transition function + unsigned char initial_state; // x_0: the initial state + bool final_states[state_max]; // X_m: the set of marked states + }; + + struct automaton aut = { + .state_names = { + "dequeued", + "enqueued", + "running", + }, + .event_names = { + "dequeue", + "enqueue", + "switch_in", + }, + .env_names = { + "clk", + }, + .function = { + { INVALID_STATE, enqueued, INVALID_STATE }, + { INVALID_STATE, INVALID_STATE, running }, + { dequeued, INVALID_STATE, INVALID_STATE }, + }, + .initial_state = dequeued, + .final_states = { 1, 0, 0 }, + }; + + static bool verify_constraint(enum states curr_state, enum events event, + enum states next_state) + { + bool res = true; + + /* Validate guards as part of f */ + if (curr_state == enqueued && event == switch_in) + res = get_env(clk) < threshold; + else if (curr_state == dequeued && event == enqueue) + reset_env(clk); + + /* Validate invariants in i */ + if (next_state == curr_state || !res) + return res; + if (next_state == enqueued) + ha_start_timer_jiffy(ha_mon, clk, threshold_jiffies); + else if (curr_state == enqueued) + res = !ha_cancel_timer(ha_mon); + return res; + } + +The function ``verify_constraint``, here reported as simplified, checks guards, +performs resets and starts timers to validate invariants according to +specification, those cannot easily be represented in the automaton struct. +Due to the complex nature of environment variables, the user needs to provide +functions to get and reset environment variables that are not common clocks +(e.g. clocks with ns or jiffy granularity). +Since invariants are only defined as clock expirations (e.g. *clk < +threshold*), reaching the expiration of a timer armed when entering the state +is in fact a failure in the model and triggers a reaction. Leaving the state +stops the timer. + +It is important to note that timers implemented with hrtimers introduce +overhead, if the monitor has several instances (e.g. all tasks) this can become +an issue. The impact can be decreased using the timer wheel (``HA_TIMER_TYPE`` +set to ``HA_TIMER_WHEEL``), this lowers the responsiveness of the timer without +damaging the accuracy of the model, since the invariant condition is checked +before disabling the timer in case the callback is late. +Alternatively, if the monitor is guaranteed to *eventually* leave the state and +the incurred delay to wait for the next event is acceptable, guards can be used +in place of invariants, as seen in the stall example. + +Graphviz .dot format +-------------------- + +Also the Graphviz representation of hybrid automata is an extension of the +deterministic automata one. Specifically, guards can be provided in the event +name separated by ``;``:: + + "state_start" -> "state_dest" [ label = "sched_waking;preemptible==0;reset(clk)" ]; + +Invariant can be specified in the state label (not the node name!) separated by ``\n``:: + + "enqueued" [label = "enqueued\nclk < threshold_jiffies"]; + +Constraints can be specified as valid C comparisons and allow spaces, the first +element of the comparison must be the clock while the second is a numerical or +parametrised value. Guards allow comparisons to be combined with boolean +operations (``&&`` and ``||``), resets must be separated from other constraints. + +This is the full example of the last version of the 'stall' model in DOT:: + + digraph state_automaton { + {node [shape = circle] "enqueued"}; + {node [shape = plaintext, style=invis, label=""] "__init_dequeued"}; + {node [shape = doublecircle] "dequeued"}; + {node [shape = circle] "running"}; + "__init_dequeued" -> "dequeued"; + "enqueued" [label = "enqueued\nclk < threshold_jiffies"]; + "running" [label = "running"]; + "dequeued" [label = "dequeued"]; + "enqueued" -> "running" [ label = "switch_in" ]; + "running" -> "dequeued" [ label = "dequeue" ]; + "dequeued" -> "enqueued" [ label = "enqueue;reset(clk)" ]; + { rank = min ; + "__init_dequeued"; + "dequeued"; + } + } + +References +---------- + +One book covering model checking and timed automata is:: + + Christel Baier and Joost-Pieter Katoen: Principles of Model Checking, + The MIT Press, 2008. + +Hybrid automata are described in detail in:: + + Thomas Henzinger: The theory of hybrid automata, + Proceedings 11th Annual IEEE Symposium on Logic in Computer Science, 1996. diff --git a/Documentation/trace/rv/index.rst b/Documentation/trace/rv/index.rst index a2812ac5cfeb..29769f06bb0f 100644 --- a/Documentation/trace/rv/index.rst +++ b/Documentation/trace/rv/index.rst @@ -9,9 +9,12 @@ Runtime Verification runtime-verification.rst deterministic_automata.rst linear_temporal_logic.rst + hybrid_automata.rst monitor_synthesis.rst da_monitor_instrumentation.rst monitor_wip.rst monitor_wwnr.rst monitor_sched.rst monitor_rtapp.rst + monitor_stall.rst + monitor_deadline.rst diff --git a/Documentation/trace/rv/monitor_deadline.rst b/Documentation/trace/rv/monitor_deadline.rst new file mode 100644 index 000000000000..84506ed1e293 --- /dev/null +++ b/Documentation/trace/rv/monitor_deadline.rst @@ -0,0 +1,84 @@ +Deadline monitors +================= + +- Name: deadline +- Type: container for multiple monitors +- Author: Gabriele Monaco <gmonaco@redhat.com> + +Description +----------- + +The deadline monitor is a set of specifications to describe the deadline +scheduler behaviour. It includes monitors per scheduling entity (deadline tasks +and servers) that work independently to verify different specifications the +deadline scheduler should follow. + +Specifications +-------------- + +Monitor nomiss +~~~~~~~~~~~~~~ + +The nomiss monitor ensures dl entities get to run *and* run to completion +before their deadline, although deferrable servers may not run. An entity is +considered done if ``throttled``, either because it yielded or used up its +runtime, or when it voluntarily starts ``sleeping``. +The monitor includes a user configurable deadline threshold. If the total +utilisation of deadline tasks is larger than 1, they are only guaranteed +bounded tardiness. See Documentation/scheduler/sched-deadline.rst for more +details. The threshold (module parameter ``nomiss.deadline_thresh``) can be +configured to avoid the monitor to fail based on the acceptable tardiness in +the system. Since ``dl_throttle`` is a valid outcome for the entity to be done, +the minimum tardiness needs be 1 tick to consider the throttle delay, unless +the ``HRTICK_DL`` scheduler feature is active. + +Servers have also an intermediate ``idle`` state, occurring as soon as no +runnable task is available from ready or running where no timing constraint +is applied. A server goes to sleep by stopping, there is no wakeup equivalent +as the order of a server starting and replenishing is not defined, hence a +server can run from sleeping without being ready:: + + | + sched_wakeup v + dl_replenish;reset(clk) -- #=========================# + | H H dl_replenish;reset(clk) + +-----------> H H <--------------------+ + H H | + +- dl_server_stop ---- H ready H | + | +-----------------> H clk < DEADLINE_NS() H dl_throttle; | + | | H H is_defer == 1 | + | | sched_switch_in - H H -----------------+ | + | | | #=========================# | | + | | | | ^ | | + | | | dl_server_idle dl_replenish;reset(clk) | | + | | | v | | | + | | | +--------------+ | | + | | | +------ | | | | + | | | dl_server_idle | | dl_throttle | | + | | | | | idle | -----------------+ | | + | | | +-----> | | | | | + | | | | | | | | + | | | | | | | | + +--+--+---+--- dl_server_stop -- +--------------+ | | | + | | | | | ^ | | | + | | | | sched_switch_in dl_server_idle | | | + | | | | v | | | | + | | | | +---------- +---------------------+ | | | + | | | | sched_switch_in | | | | | + | | | | sched_wakeup | | | | | + | | | | dl_replenish; | running | -------+ | | | + | | | | reset(clk) | clk < DEADLINE_NS() | | | | | + | | | | +---------> | | dl_throttle | | | + | | | +----------------> | | | | | | + | | | +---------------------+ | | | | + | | sched_wakeup ^ sched_switch_suspend | | | | + v v dl_replenish;reset(clk) | dl_server_stop | | | | + +--------------+ | | v v v | + | | - sched_switch_in + | +---------------+ + | | <---------------------+ dl_throttle +-- | | + | sleeping | sched_wakeup | | throttled | + | | -- dl_server_stop dl_server_idle +-> | | + | | dl_server_idle sched_switch_suspend +---------------+ + +--------------+ <---------+ ^ + | | + +------ dl_throttle;is_constr_dl == 1 || is_defer == 1 ------+ diff --git a/Documentation/trace/rv/monitor_sched.rst b/Documentation/trace/rv/monitor_sched.rst index 3f8381ad9ec7..0b96d6e147c6 100644 --- a/Documentation/trace/rv/monitor_sched.rst +++ b/Documentation/trace/rv/monitor_sched.rst @@ -346,55 +346,21 @@ Monitor opid The operations with preemption and irq disabled (opid) monitor ensures operations like ``wakeup`` and ``need_resched`` occur with interrupts and -preemption disabled or during interrupt context, in such case preemption may -not be disabled explicitly. +preemption disabled. ``need_resched`` can be set by some RCU internals functions, in which case it -doesn't match a task wakeup and might occur with only interrupts disabled:: - - | sched_need_resched - | sched_waking - | irq_entry - | +--------------------+ - v v | - +------------------------------------------------------+ - +----------- | disabled | <+ - | +------------------------------------------------------+ | - | | ^ | - | | preempt_disable sched_need_resched | - | preempt_enable | +--------------------+ | - | v | v | | - | +------------------------------------------------------+ | - | | irq_disabled | | - | +------------------------------------------------------+ | - | | | ^ | - | irq_entry irq_entry | | | - | sched_need_resched v | irq_disable | - | sched_waking +--------------+ | | | - | +----- | | irq_enable | | - | | | in_irq | | | | - | +----> | | | | | - | +--------------+ | | irq_disable - | | | | | - | irq_enable | irq_enable | | | - | v v | | - | #======================================================# | - | H enabled H | - | #======================================================# | - | | ^ ^ preempt_enable | | - | preempt_disable preempt_enable +--------------------+ | - | v | | - | +------------------+ | | - +----------> | preempt_disabled | -+ | - +------------------+ | - | | - +-------------------------------------------------------+ - -This monitor is designed to work on ``PREEMPT_RT`` kernels, the special case of -events occurring in interrupt context is a shortcut to identify valid scenarios -where the preemption tracepoints might not be visible, during interrupts -preemption is always disabled. On non- ``PREEMPT_RT`` kernels, the interrupts -might invoke a softirq to set ``need_resched`` and wake up a task. This is -another special case that is currently not supported by the monitor. +doesn't match a task wakeup and might occur with only interrupts disabled. +The interrupt and preemption status are validated by the hybrid automaton +constraints when processing the events:: + + | + | + v + #=========# sched_need_resched;irq_off == 1 + H H sched_waking;irq_off == 1 && preempt_off == 1 + H any H ------------------------------------------------+ + H H | + H H <-----------------------------------------------+ + #=========# References ---------- diff --git a/Documentation/trace/rv/monitor_stall.rst b/Documentation/trace/rv/monitor_stall.rst new file mode 100644 index 000000000000..d29e820b2433 --- /dev/null +++ b/Documentation/trace/rv/monitor_stall.rst @@ -0,0 +1,43 @@ +Monitor stall +============= + +- Name: stall - stalled task monitor +- Type: per-task hybrid automaton +- Author: Gabriele Monaco <gmonaco@redhat.com> + +Description +----------- + +The stalled task (stall) monitor is a sample per-task timed monitor that checks +if tasks are scheduled within a defined threshold after they are ready:: + + | + | + v + #==========================# + +-----------------> H dequeued H + | #==========================# + | | + sched_switch_wait | sched_wakeup;reset(clk) + | v + | +--------------------------+ <+ + | | enqueued | | sched_wakeup + | | clk < threshold_jiffies | -+ + | +--------------------------+ + | | ^ + | sched_switch_in sched_switch_preempt;reset(clk) + | v | + | +--------------------------+ + +------------------ | running | + +--------------------------+ + ^ sched_switch_in | + | sched_wakeup | + +----------------------+ + +The threshold can be configured as a parameter by either booting with the +``stall.threshold_jiffies=<new value>`` argument or writing a new value to +``/sys/module/stall/parameters/threshold_jiffies``. + +Specification +------------- +Graphviz Dot file in tools/verification/models/stall.dot diff --git a/Documentation/trace/rv/monitor_synthesis.rst b/Documentation/trace/rv/monitor_synthesis.rst index cc5f97977a29..2c1b5a0ae154 100644 --- a/Documentation/trace/rv/monitor_synthesis.rst +++ b/Documentation/trace/rv/monitor_synthesis.rst @@ -18,8 +18,8 @@ functions that glue the monitor to the system reference model, and the trace output as a reaction to event parsing and exceptions, as depicted below:: - Linux +----- RV Monitor ----------------------------------+ Formal - Realm | | Realm + Linux +---- RV Monitor ----------------------------------+ Formal + Realm | | Realm +-------------------+ +----------------+ +-----------------+ | Linux kernel | | Monitor | | Reference | | Tracing | -> | Instance(s) | <- | Model | @@ -45,6 +45,7 @@ creating monitors. The header files are: * rv/da_monitor.h for deterministic automaton monitor. * rv/ltl_monitor.h for linear temporal logic monitor. + * rv/ha_monitor.h for hybrid automaton monitor. rvgen ----- @@ -252,6 +253,118 @@ the task, the monitor may need some time to start validating tasks which have been running before the monitor is enabled. Therefore, it is recommended to start the tasks of interest after enabling the monitor. +rv/ha_monitor.h ++++++++++++++++ + +The implementation of hybrid automaton monitors derives directly from the +deterministic automaton one. Despite using a different header +(``ha_monitor.h``) the functions to handle events are the same (e.g. +``da_handle_event``). + +Additionally, the `rvgen` tool populates skeletons for the +``ha_verify_constraint``, ``ha_get_env`` and ``ha_reset_env`` based on the +monitor specification in the monitor source file. + +``ha_verify_constraint`` is typically ready as it is generated by `rvgen`: + +* standard constraints on edges are turned into the form:: + + res = ha_get_env(ha_mon, ENV) < VALUE; + +* reset constraints are turned into the form:: + + ha_reset_env(ha_mon, ENV); + +* constraints on the state are implemented using timers + + - armed before entering the state + + - cancelled while entering any other state + + - untouched if the state does not change as a result of the event + + - checked if the timer expired but the callback did not run + + - available implementation are `HA_TIMER_HRTIMER` and `HA_TIMER_WHEEL` + + - hrtimers are more precise but may have higher overhead + + - select by defining `HA_TIMER_TYPE` before including the header:: + + #define HA_TIMER_TYPE HA_TIMER_HRTIMER + +Constraint values can be specified in different forms: + +* literal value (with optional unit). E.g.:: + + preemptive == 0 + clk < 100ns + threshold <= 10j + +* constant value (uppercase string). E.g.:: + + clk < MAX_NS + +* parameter (lowercase string). E.g.:: + + clk <= threshold_jiffies + +* macro (uppercase string with parentheses). E.g.:: + + clk < MAX_NS() + +* function (lowercase string with parentheses). E.g.:: + + clk <= threshold_jiffies() + +In all cases, `rvgen` will try to understand the type of the environment +variable from the name or unit. For instance, constants or parameters +terminating with ``_NS`` or ``_jiffies`` are intended as clocks with ns and jiffy +granularity, respectively. Literals with measure unit `j` are jiffies and if a +time unit is specified (`ns` to `s`), `rvgen` will convert the value to `ns`. + +Constants need to be defined by the user (but unlike the name, they don't +necessarily need to be defined as constants). Parameters get converted to +module parameters and the user needs to provide a default value. +Also function and macros are defined by the user, by default they get as an +argument the ``ha_monitor``, a common usage would be to get the required value +from the target, e.g. the task in per-task monitors, using the helper +``ha_get_target(ha_mon)``. + +If `rvgen` determines that the variable is a clock, it provides the getter and +resetter based on the unit. Otherwise, the user needs to provide an appropriate +definition. +Typically non-clock environment variables are not reset. In such case only the +getter skeleton will be present in the file generated by `rvgen`. +For instance, the getter for preemptive can be filled as:: + + static u64 ha_get_env(struct ha_monitor *ha_mon, enum envs env) + { + if (env == preemptible) + return preempt_count() == 0; + return ENV_INVALID_VALUE; + } + +The function is supplied the ``ha_mon`` parameter in case some storage is +required (as it is for clocks), but environment variables without reset do not +require a storage and can ignore that argument. +The number of environment variables requiring a storage is limited by +``MAX_HA_ENV_LEN``, however such limitation doesn't stand for other variables. + +Finally, constraints on states are only valid for clocks and only if the +constraint is of the form `clk < N`. This is because such constraints are +implemented with the expiration of a timer. +Typically the clock variables are reset just before arming the timer, but this +doesn't have to be the case and the available functions take care of it. +It is a responsibility of per-task monitors to make sure no timer is left +running when the task exits. + +By default the generator implements timers with hrtimers (setting +``HA_TIMER_TYPE`` to ``HA_TIMER_HRTIMER``), this gives better responsiveness +but higher overhead. The timer wheel (``HA_TIMER_WHEEL``) is a good alternative +for monitors with several instances (e.g. per-task) that achieves lower +overhead with increased latency, yet without compromising precision. + Final remarks ------------- diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst index b826c34791c0..b6d24f6f17d1 100644 --- a/Documentation/translations/index.rst +++ b/Documentation/translations/index.rst @@ -10,11 +10,11 @@ Translations zh_CN/index zh_TW/index it_IT/index - ko_KR/index ja_JP/index + ko_KR/index + pt_BR/index sp_SP/index - .. _translations_disclaimer: Disclaimer diff --git a/Documentation/translations/it_IT/process/4.Coding.rst b/Documentation/translations/it_IT/process/4.Coding.rst index 3126342c4b4a..a2ec35e016b7 100644 --- a/Documentation/translations/it_IT/process/4.Coding.rst +++ b/Documentation/translations/it_IT/process/4.Coding.rst @@ -329,7 +329,8 @@ Sparse deve essere installato separatamente (se il vostra distribuzione non lo prevede, potete trovarlo su https://sparse.wiki.kernel.org/index.php/Main_Page); può essere attivato sul codice aggiungendo "C=1" al comando make. -Lo strumento "Coccinelle" (http://coccinelle.lip6.fr/) è in grado di trovare +Lo strumento "Coccinelle" (https://coccinelle.gitlabpages.inria.fr/website/) +è in grado di trovare una vasta varietà di potenziali problemi di codifica; e può inoltre proporre soluzioni per risolverli. Un buon numero di "patch semantiche" per il kernel sono state preparate nella cartella scripts/coccinelle; utilizzando diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst index d61583399ef4..9d63220abd15 100644 --- a/Documentation/translations/ja_JP/process/submitting-patches.rst +++ b/Documentation/translations/ja_JP/process/submitting-patches.rst @@ -35,7 +35,7 @@ Documentation/devicetree/bindings/submitting-patches.rst を読んでくださ いくつかのサブシステムやメンテナツリーには、各々のワークフローや 期待事項に関する追加情報があります。次を参照してください: -:ref:`Documentation/process/maintainer-handbooks.rst <maintainer_handbooks_main>`. +Documentation/process/maintainer-handbooks.rst. 現在のソースツリーを入手する ---------------------------- @@ -52,5 +52,130 @@ Documentation/devicetree/bindings/submitting-patches.rst を読んでくださ ツリーは MAINTAINERS ファイル内の **T:** エントリを参照して見つけてください。 そこに掲載されていない場合は、メンテナに問い合わせてください。 -変更内容を説明する +変更内容を記述する ------------------ + +まず問題点を記べてください。あなたのパッチが 1 行のバグ修正であっても、 +5000 行の新機能であっても、それを行う動機となった根本的な問題が +必ずあるはずです。レビューアが、修正すべき問題がたしかに存在し、冒頭の +段落の続きを読むべきだと納得できるように書いてください。 + +次にユーザーから見える影響を記述してください。クラッシュやロックアップは +分かりやすいですが、すべてのバグがそこまで露骨とは限りません。 +たとえコードレビュー中に見つかった問題であっても、ユーザーに +どのような影響があり得るかを記述してください。 +Linux の多くの環境は、上流から特定のパッチだけを取り込む二次的な +安定版ツリーや、ベンダー／製品固有のツリーのカーネルで動いています。 +したがって、変更を適切に下流へ流す助けになる情報（発生条件、dmesg +の抜粋、クラッシュ内容、性能劣化、レイテンシのスパイク、 +ロックアップ等）があれば記載してください。 + +次に最適化とトレードオフを定量的に示してください。パフォーマンス、 +メモリ消費量、スタックフットプリント、バイナリサイズの改善を主張する +場合は、それを裏付ける数値を記載してください。 +また、目に見えないコストについても記述してください。多くの場合、 +最適化は CPU・メモリ・可読性の間でのトレードオフとなります。 +ヒューリスティクスの場合は、異なるワークロード間でのトレードオフと +なります。レビューアがコストとメリットを比較検討できるよう、 +最適化に伴って想定されるデメリットも記述してください。 + +問題点の明確化が済んだら、実際にどのような対策を講じているかを技術的に +詳しく説明してください。コードが意図したとおりに動作していることを +レビューアが確認できるよう、変更内容を平易な言葉で書き下すことが重要です。 + +パッチの説明が Linux のソースコード管理システム ``git`` の「コミットログ」 +としてそのまま取り込める形で書かれていれば、メンテナは助かります。 +詳細は原文の該当節 ("The canonical patch format") を参照してください。 + +.. TODO: Convert to file-local cross-reference when the destination is + translated. + +1 つのパッチでは 1 つの問題だけを解決してください。記述が長くなり +始めたら、それはパッチを分割すべきサインです。 +詳細は原文の該当節 ("Separate your changes") を参照してください。 + +.. TODO: Convert to file-local cross-reference when the destination is + translated. + +パッチまたはパッチシリーズを投稿／再投稿する際は、その完全な +説明と、それを正当化する理由を含めてください。単に「これはパッチ +（シリーズ）のバージョン N です」とだけ書くのは避けてください。 +サブシステムメンテナが以前のパッチバージョンや参照先 URL をさかのぼって +パッチ記述を探し、それをパッチに補うことを期待してはいけません。 +つまり、パッチ（シリーズ）とその説明は、それだけで完結しているべき +です。これはメンテナとレビューアの双方に有益です。レビューアの +中には、以前のパッチバージョンを受け取っていない人もいるでしょう。 + +変更内容は、あたかもコードベースに対してその振る舞いを変えるように +命令するかの如く、（訳補: 英語の）命令形で記述してください。たとえば、 +"[This patch] makes xyzzy do frotz" や +"[I] changed xyzzy to do frotz" のような言い回しを避け、 +"make xyzzy do frotz" のように書いてください。 + +特定のコミットに言及したい場合に、コミットの SHA-1 ID だけを +書くのは避けてください。レビューアがそれが何についてのものかを +把握しやすいよう、コミットの 1 行要約も含めてください。例:: + + Commit e21d2170f36602ae2708 ("video: remove unnecessary + platform_set_drvdata()") removed the unnecessary + platform_set_drvdata(), but left the variable "dev" unused, + delete it. + +また、SHA-1 ID は少なくとも先頭 12 文字を使うようにしてください。 +カーネルのリポジトリには\ **非常に多くの**\ オブジェクトがあるため、 +それより短い ID では衝突が現実問題となります。6 文字の ID が今現在 +衝突しないからといって、5 年後もそうであるとは限らないことを念頭に +置いてください。 + +変更に関連する議論や、その背景情報が Web 上で参照できる場合は、 +それを指す 'Link:' タグを追加してください。過去のメーリングリスト +での議論や、Web に記録された何かに由来するパッチならば、 +それを示してください。 + +メーリングリストのアーカイブへリンクする場合は、できれば lore.kernel.org +のメッセージアーカイブサービスを使ってください。リンク URL を作るには、 +そのメッセージの ``Message-ID`` ヘッダの内容から、前後の山括弧を取り除いた +ものを使います。例:: + + Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI + +実際にリンクが機能し、該当するメッセージを指していることを +確認してください。 + +ただし、外部リソースを見なくても説明が理解できるようにするよう努めてください。 +メーリングリストのアーカイブやバグへの URL を示すだけでなく、 +投稿されたパッチに至った議論のポイントも要約してください。 + +パッチがバグを修正するものであれば、メーリングリストのアーカイブや +公開バグトラッカー上の報告を指す URL を付けて、``Closes:`` タグを +使ってください。例:: + + Closes: https://example.com/issues/1234 + +このようなタグ付きのコミットが適用されたとき、自動的に issue を +閉じるバグトラッカーもあります。メーリングリストを監視している +ボットの中には、そのようなタグを追跡して一定の動作を行うものも +あります。ただし、非公開バグトラッカーの（訳補: 部外者が）閲覧できない +URL は禁止です。 + +パッチが特定のコミットに含まれるバグを修正するもの、たとえば +``git bisect`` で問題を見つけたものの場合には、SHA-1 ID の +先頭少なくとも 12 文字と 1 行要約を含めて 'Fixes:' タグを +使ってください。タグを複数行に分割してはいけません。タグは +解析スクリプトを単純にするため、「75 桁で折り返す」規則の +例外です。例:: + + Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed") + +``git log`` や ``git show`` の出力を上の形式で整形させるには、 +次の ``git config`` 設定が使えます:: + + [core] + abbrev = 12 + [pretty] + fixes = Fixes: %h ("%s") + +呼び出し例:: + + $ git log -1 --pretty=fixes 54a4f0239f2e + Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed") diff --git a/Documentation/translations/pt_BR/disclaimer-pt_BR.rst b/Documentation/translations/pt_BR/disclaimer-pt_BR.rst new file mode 100644 index 000000000000..3cae22c13d3f --- /dev/null +++ b/Documentation/translations/pt_BR/disclaimer-pt_BR.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0 + + + +Aviso sobre traduções para português +==================================== + +Esta documentação foi traduzida para português brasileiro por voluntários. +Em caso de qualquer divergência entre esta tradução e o documento original +em inglês, a versão em inglês (encontrada no diretório Documentation/) +deve ser considerada a única fonte de verdade. diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst new file mode 100644 index 000000000000..4a094d8b794f --- /dev/null +++ b/Documentation/translations/pt_BR/index.rst @@ -0,0 +1,77 @@ +.. SPDX-License-Identifier: GPL-2.0 + + + +========================================= +Documentação do Kernel Linux em Português +========================================= + +.. raw:: latex + + \kerneldocCJKoff + +:mantenedor: Daniel Pereira <danielmaraboo@gmail.com> + +Este é o nível principal da documentação do kernel em língua portuguesa (Brasil). +A tradução ainda está em seu estágio inicial e incompleta; você notará avisos +sinalizando a falta de traduções para grupos específicos de documentos. + +De maneira geral, a documentação, assim como o próprio kernel, está em constante +desenvolvimento; isso é especialmente verdade agora, pois estamos trabalhando +na reorganização da documentação de forma mais coerente. Melhorias na +documentação são sempre bem-vindas; se você deseja ajudar, inscreva-se na lista +de discussão linux-doc em vger.kernel.org. + + + +Avisos +====== + +.. include:: disclaimer-pt_BR.rst + +O objetivo desta tradução é facilitar a leitura e compreensão para aqueles que +não dominam o inglês ou têm dúvidas sobre sua interpretação, ou simplesmente +para quem prefere ler em sua língua nativa. No entanto, tenha em mente que a +*única* documentação oficial é a em língua inglesa: :ref:`linux_doc` + +A propagação simultânea de uma alteração em :ref:`linux_doc` para todas as +traduções é altamente improvável. Os mantenedores das traduções — e seus +contribuidores — acompanham a evolução da documentação oficial e tentam manter +as respectivas traduções alinhadas na medida do possível. Por este motivo, não +há garantia de que uma tradução esteja atualizada com a última modificação. +Se o que você ler em uma tradução não corresponder ao que ler no código, +informe o mantenedor da tradução e — se puder — verifique também a +documentação em inglês. + +Uma tradução não é um *fork* da documentação oficial; portanto, os usuários não +encontrarão nela informações diferentes daquelas contidas na versão oficial. +Qualquer adição, remoção ou modificação de conteúdo deve ser feita primeiro nos +documentos em inglês. Posteriormente, quando possível, a mesma alteração deve +ser aplicada às traduções. Os mantenedores das traduções aceitam contribuições +que afetem puramente a atividade de tradução (por exemplo, novas traduções, +atualizações, correções). + +As traduções buscam ser o mais precisas possível, mas não é possível mapear +diretamente uma língua em outra. Cada língua possui sua própria gramática e +cultura, portanto, a tradução de uma frase em inglês pode ser modificada para +se adaptar ao português. Por esse motivo, ao ler esta tradução, você poderá +encontrar algumas diferenças de forma, mas que transmitem a mensagem original. + +Trabalhando com a comunidade de desenvolvimento +=============================================== + +As guias fundamentais para a interação com a comunidade de desenvolvimento do +kernel e sobre como ver seu trabalho integrado. + +.. toctree:: + :maxdepth: 1 + + Introdução <process/1.Intro> + Como começar <process/howto> + Requisitos mínimos <process/changes> + Conclave (Continuidade do projeto) <process/conclave> + Manuais dos mantenedores <process/maintainer-handbooks> + Processo do subsistema de rede (netdev) <process/maintainer-netdev> + Processo do subsistema SoC <process/maintainer-soc> + Conformidade de DTS para SoC <process/maintainer-soc-clean-dts> + Processo do subsistema KVM x86 <process/maintainer-kvm-x86> diff --git a/Documentation/translations/pt_BR/process/1.Intro.rst b/Documentation/translations/pt_BR/process/1.Intro.rst new file mode 100644 index 000000000000..2995fa49e4c4 --- /dev/null +++ b/Documentation/translations/pt_BR/process/1.Intro.rst @@ -0,0 +1,269 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Introdução +========== + +Sumário +------- + +O restante desta seção cobre o processo de desenvolvimento do kernel e os +tipos de frustração que os desenvolvedores e empresas podem encontrar pelo +caminho. Existem diversas razões que justificam a recomendação para que seja +feito o merge do código do kernel ao kernel principal ("mainline"), como +disponibilidade automática aos usuários, suporte da comunidade em diversas +formas, e a oportunidade de influenciar a direção do desenvolvimento do +kernel. Contribuições ao kernel Linux obrigatoriamente devem estar disponíveis +sob uma licença compatível com a GPL. + +:ref:`development_process` apresenta o processo de desenvolvimento, o ciclo de +lançamento, e a mecânica da janela de merge. As várias fases no desenvolvimento +de patch, revisão, e ciclo de merge são explicadas. Algumas ferramentas e +listas de e-mail são discutidas. Desenvolvedores que queiram começar a +desenvolver o kernel são encorajados a buscar e corrigir bugs como exercício +inicial. + +:ref:`development_early_stage` cobre os primeiros passos do processo de +desenvolvimento, com ênfase no envolvimento da comunidade de desenvolvedores o +mais cedo possível. + +:ref:`development_coding` é sobre o processo de codificação; muitas armadilhas +já encontradas por outros desenvolvedores são discutidas. Alguns requisitos +para patches são explicados, e é feita uma introdução para algumas ferramentas +que podem ajudar a garantir que os patches de kernel estão corretos. + +:ref:`development_posting` fala sobre o processo de envio de patches para +revisão. Para serem levados em consideração pela comunidade desenvolvedora, os +patches devem estar devidamente formatados e descritos, assim como devem estar +no lugar correto. Seguir os conselhos dessa seção pode ajudar na recepção +positiva do seu trabalho. + +:ref:`development_followthrough` cobre o que acontece após o envio dos patches; +o trabalho ainda está longe de estar concluído. Trabalhar com os revisores é +parte crucial do processo de desenvolvimento; essa seção oferece dicas de como +evitar problemas nesse estágio importante. Desenvolvedores são alertados a não +presumir que o trabalho acabou após o merge do patch no "mainline". + +:ref:`development_advancedtopics` introduz dois tópicos mais "avançados": +gerenciamento de patches com git e revisão de patches por outros. + +:ref:`development_conclusion` conclui o documento com indicações de fontes com +mais informações sobre o desenvolvimento do kernel. + +Sobre este documento +-------------------- + +O kernel Linux, com mais de 8 milhões de linhas de código e bem mais de 1000 +contribuintes a cada lançamento ("release"), é um dos maiores e mais ativos +projetos de software livre em existência. Desde seu modesto início em 1991, +este kernel evoluiu para se tornar um dos melhores componentes de sistemas +operacionais, rodando em pequenos players de música digital, PCs de mesa, os +maiores supercomputadores em existência, e todos os outros tipos de sistema +entre eles. É robusto, eficiente, e uma solução escalável para quase toda +situação. + +O crescimento do Linux trouxe o aumento no número de desenvolvedores (e +empresas) desejando participar no seu desenvolvimento. Fabricantes de hardware +querem garantir que o Linux suporte bem os seus produtos, tornando-os atrativos +para usuários Linux. Fabricantes de sistemas embarcados, que usam o Linux como +componente em um produto integrado, querem que o Linux seja tão capaz e +adequado quanto possível para a tarefa em questão. Distribuidores de software +que baseiam seus produtos em Linux têm claro interesse nas capacidades, +performance, e confiabilidade do kernel Linux. É também comum que usuários +finais queiram alterar o Linux para atender melhor suas necessidades. + +Uma das características mais atrativas do Linux é sua facilidade de acesso a +esses desenvolvedores; qualquer um com as habilidades necessárias pode melhorar +o Linux e influenciar a direção do seu desenvolvimento. Produtos proprietários +não conseguem oferecer esse tipo de abertura, que é característico do processo +de software livre. O kernel é ainda mais acessível que a maioria dos outros +projetos de software livre. Um ciclo típico de três meses de desenvolvimento +do kernel pode envolver mais de 1000 desenvolvedores trabalhando para mais de +100 empresas (ou absolutamente nenhuma empresa). + +Trabalhar com a comunidade de desenvolvimento do kernel não é uma tarefa árdua. +Contudo, muitos colaboradores potenciais passaram por dificuldades ao tentar +trabalhar no kernel. A comunidade evoluiu suas próprias formas de funcionamento +que permitem operar de forma fluida (e produzir um produto de alta qualidade) +em um ambiente em que milhares de linhas de código são alteradas todos os dias. +Não é surpresa que o processo de desenvolvimento do kernel Linux seja muito +diferente dos modelos de desenvolvimento proprietários. + +O processo de desenvolvimento do kernel pode parecer estranho e intimidador +para novos desenvolvedores, mas existem bons motivos e uma sólida experiência +por trás disso. Um desenvolvedor que não entenda os caminhos próprios da +comunidade kernel (ou pior, que tente menosprezá-los ou contorná-los) terá uma +experiência frustrante pela frente. A comunidade de desenvolvimento ajuda +aqueles que tentam aprender, mas gasta pouco tempo com aqueles que não escutam +ou não ligam para o processo de desenvolvimento. + +Espera-se que aqueles que leiam este documento sejam capazes de evitar essa +experiência frustrante. Há muito material aqui, mas o esforço envolvido na sua +leitura valerá a pena. A comunidade de desenvolvimento sempre necessita de +desenvolvedores que ajudem a melhorar o kernel; o texto a seguir deve ajudar +você - ou aqueles trabalhando para você - a se juntar à nossa comunidade. + +Créditos +-------- + +Esse documento foi escrito por Jonathan Corbet, corbet@lwn.net. Aprimorado +pelos comentários de Johannes Berg, James Berry, Alex Chiang, Roland Dreier, +Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda +McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, e Jochen Voß. + +Esse trabalho contou com o apoio da Linux Foundation; agradecimentos especiais +para Amanda McPherson, que viu o valor desse esforço e fez tudo acontecer. + +A importância de levar o código até o "mainline" +------------------------------------------------- + +Algumas empresas e desenvolvedores ocasionalmente se perguntam por que devem +se importar em aprender como trabalhar com a comunidade do kernel e ter seu +código no "mainline" (o kernel mantido por Linus Torvalds e usado como base +para os distribuidores Linux). No curto prazo, contribuir com o código pode +parecer um gasto evitável; parece mais fácil apenas manter o seu código à +parte e oferecer suporte direto aos usuários. A verdade é que manter código +fora da árvore principal ("out-of-tree") é uma falsa economia. + +Para ilustrar os custos do código "out-of-tree", aqui estão alguns aspectos +relevantes do processo de desenvolvimento do kernel; a maioria será discutida +com mais detalhes adiante neste documento. Considere: + +- Código integrado via merge ao "mainline" fica disponível para todos os + usuários Linux. Estará automaticamente presente em todas as distribuições + que o habilitarem. Não há necessidade de discos de armazenamento, downloads, + ou as complicações de dar suporte a múltiplas versões de variadas + distribuições; tudo simplesmente funciona, para o desenvolvedor e para o + usuário. Incorporação ao "mainline" resolve um grande número de problemas + de distribuição e suporte. + +- Enquanto desenvolvedores do kernel se esforçam para manter uma interface + estável para o espaço do usuário, a API interna está em constante mudança. + A ausência de uma interface interna estável é uma escolha deliberada de + design; permite que sejam feitas melhorias fundamentais a qualquer tempo e + resulta em código de qualidade superior. Uma consequência dessa política é + que código "out-of-tree" precisa ser constantemente atualizado para que + continue funcionando com novos kernels. Manter código "out-of-tree" requer + significativo trabalho apenas para mantê-lo funcionando. + + Por sua vez, código que está no "mainline" não precisa dessa manutenção, + resultado de uma regra simples que exige que qualquer desenvolvedor que + altere uma API, também conserte qualquer código que deixe de funcionar como + resultado da alteração. Código que teve o merge realizado no "mainline" tem + custo significativamente menor de manutenção. + +- Além disso, código que está no kernel será muitas vezes melhorado por outros + desenvolvedores. Resultados surpreendentes podem surgir ao permitir que sua + comunidade de usuários e clientes melhore seu produto. + +- Código do kernel está sujeito a revisão, tanto antes como depois do merge ao + "mainline". Independentemente das habilidades do desenvolvedor original, o + processo de revisão invariavelmente encontra maneiras de evoluí-lo. Bugs + severos e problemas de segurança são constantemente encontrados durante o + processo de revisão. Isso é especialmente válido para código desenvolvido em + ambiente isolado; tais códigos se beneficiam fortemente ao serem revistos por + outros desenvolvedores. Código "out-of-tree" é código de baixa qualidade. + +- Participação no processo de desenvolvimento é a forma pela qual você pode + influenciar a direção do desenvolvimento do kernel. Usuários que se queixam + externamente são ouvidos, porém desenvolvedores ativos têm maior poder de + articulação - e a habilidade de implementar mudanças que façam o kernel + funcionar melhor para suas necessidades. + +- Quando o código é mantido à parte, sempre existe a possibilidade de que + terceiros contribuam para uma implementação diferente de uma funcionalidade + parecida. Se isso acontecer, ter seu código integrado via merge se tornará + muito mais difícil - ao ponto de ser impossível. Você enfrentará duas + alternativas desagradáveis, (1) manter uma funcionalidade "out-of-tree" + indefinidamente ou (2) abandonar seu código e migrar seus usuários para a + versão na árvore principal ("in-tree"). + +- Contribuição de código é a ação fundamental que faz todo o processo + funcionar. Ao contribuir com seu código você pode adicionar nova + funcionalidade ao kernel e proporcionar capacidades e exemplos que podem ser + usados por outros desenvolvedores de kernel. Se você desenvolveu código para + o Linux (ou está pensando em desenvolver), você claramente tem interesse na + continuidade do sucesso dessa plataforma; contribuição de código é uma das + melhores maneiras de garantir esse sucesso. + +Todos os argumentos acima se aplicam a qualquer código "out-of-tree", incluindo +código distribuído de maneira proprietária, em formato exclusivamente binário. +Existem fatores adicionais que devem ser levados em consideração antes de +qualquer distribuição de código de kernel apenas em binário, incluindo: + +- As questões legais da distribuição de kernel proprietário são, no melhor dos + casos, confusas; muitos detentores de direitos autorais do kernel acreditam + que a maioria dos módulos binários são produtos derivados do kernel e que, + como resultado, sua distribuição é uma violação da Licença Pública Geral GNU + ("GNU General Public License"), que será tratada com mais profundidade abaixo. + Este autor não é um advogado, e nada neste documento pode ser considerado + aconselhamento jurídico. O verdadeiro status de módulos privados ("closed + source") só pode ser determinado judicialmente. Independentemente disso, a + incerteza que cerca esses módulos existe. + +- Os módulos binários aumentam consideravelmente a dificuldade de depuração de + problemas do kernel ("debugging"), a ponto de a maioria dos desenvolvedores + de kernel sequer tentar. Portanto, a distribuição de módulos exclusivamente + binários tornará mais difícil que os seus usuários recebam suporte. + +- O suporte também é mais difícil para distribuidores de módulos exclusivamente + binários, que precisam fornecer uma versão do módulo para cada distribuição e + cada versão do kernel que desejam suportar. Dezenas de versões de um único + módulo podem ser necessárias para fornecer uma cobertura razoavelmente + abrangente, e seus usuários terão que atualizar seu módulo separadamente + sempre que atualizarem seu kernel. + +- Tudo o que foi dito acima sobre revisão de código se aplica em dobro ao + código fechado. Como esse código não está disponível, ele não pode ter sido + revisado pela comunidade e, sem dúvida, terá sérios problemas. + +Os fabricantes de sistemas embarcados, em particular, podem ser tentados a +ignorar grande parte do que foi dito nesta seção, acreditando que estão +lançando um produto autossuficiente que usa uma versão congelada do kernel e +não requer mais desenvolvimento após o lançamento. Esse argumento ignora o +valor de uma revisão de código abrangente e o valor de permitir que seus +usuários adicionem recursos ao seu produto. Mas esses produtos também têm uma +vida comercial limitada, após a qual uma nova versão deve ser lançada. Nesse +ponto, os fornecedores cujo código está no "mainline" e bem mantido estarão em +uma posição muito melhor para preparar o novo produto para o mercado +rapidamente. + +Licenciamento +------------- + +Código é submetido ao kernel do Linux sob diversas licenças, mas todo ele deve +ser compatível com a versão 2 da Licença Pública Geral GNU (GPLv2), que é a +licença que cobre a distribuição do kernel como um todo. Na prática, isso +significa que todas as contribuições de código são cobertas pela GPLv2 (com, +opcionalmente, uma linguagem que permita a distribuição sob versões posteriores +da GPL) ou pela licença BSD de três cláusulas. Quaisquer contribuições que não +sejam cobertas por uma licença compatível não serão aceitas no kernel. + +A cessão de direitos autorais não é exigida (nem solicitada) para o código +contribuído para o kernel. Todo o código incorporado ao kernel principal mantém +sua titularidade original; como resultado, o kernel agora tem milhares de +proprietários. + +Uma implicação dessa estrutura de propriedade é que qualquer tentativa de +alterar o licenciamento do kernel está fadada ao fracasso quase certo. Existem +poucos cenários práticos em que o acordo de todos os detentores de direitos +autorais poderia ser obtido (ou seu código removido do kernel). Portanto, em +particular, não há perspectiva de migração para a versão 3 da GPL em um futuro +próximo. + +É imprescindível que todo o código contribuído para o kernel seja legitimamente +software livre. Por esse motivo, código de contribuidores sem identidade +conhecida ou contribuidores anônimos não será aceito. Todos os contribuidores +são obrigados a "assinar" seu código, declarando que ele pode ser distribuído +com o kernel sob a GPL. Código que não tenha sido licenciado como software +livre por seu proprietário, ou que apresente risco de criar problemas +relacionados a direitos autorais para o kernel (como código derivado de +esforços de engenharia reversa sem as devidas salvaguardas) não pode ser +contribuído. + +Questões sobre direitos autorais são comuns em listas de discussão de +desenvolvimento Linux. Normalmente, essas perguntas recebem muitas respostas, +mas é importante lembrar que as pessoas que respondem a essas perguntas não são +advogados e não podem fornecer aconselhamento jurídico. Se você tiver dúvidas +jurídicas relacionadas ao código-fonte do Linux, não há substituto para +conversar com um advogado especializado nessa área. Confiar em respostas +obtidas em listas de discussão técnicas é arriscado. diff --git a/Documentation/translations/pt_BR/process/changes.rst b/Documentation/translations/pt_BR/process/changes.rst new file mode 100644 index 000000000000..1964c1c93b34 --- /dev/null +++ b/Documentation/translations/pt_BR/process/changes.rst @@ -0,0 +1,576 @@ +.. SPDX-License-Identifier: GPL-2.0 + + + +Requisitos mínimos para compilar o Kernel +++++++++++++++++++++++++++++++++++++++++++ + +Introdução +=========== + +Este documento foi projetado para fornecer uma lista das versões mínimas +de software necessárias para executar a versão atual do kernel. + +Este documento é originalmente baseado no meu arquivo 'Changes' para os kernels +2.0.x e portanto, deve créditos às mesmas pessoas que aquele arquivo (Jared +Mauch, Axel Boldt, Alessandro Sigala e inúmeros outros usuários em toda a rede). + +Requisitos Mínimos Atuais +**************************** + +Atualize para pelo menos estas revisões de software antes de pensar que +encontrou um bug! Se não tiver certeza de qual versão está executando atualmente +, o comando sugerido deve lhe informar. + +Novamente, tenha em mente que esta lista pressupõe que você já possui um kernel +Linux em execução funcional. Além disso, nem todas as ferramentas são +necessárias em todos os sistemas; obviamente, se você não possui nenhum hardware +PC Card por exemplo, provavelmente não precisará se preocupar com o pcmciautils. + +====================== =============== ======================================== + Programa Versão mínima Comando para verificar a versão +====================== =============== ======================================== +GNU C 8.1 gcc --version +Clang/LLVM (optional) 15.0.0 clang --version +Rust (optional) 1.78.0 rustc --version +bindgen (optional) 0.65.1 bindgen --version +GNU make 4.0 make --version +bash 4.2 bash --version +binutils 2.30 ld -v +flex 2.5.35 flex --version +bison 2.0 bison --version +pahole 1.16 pahole --version +util-linux 2.10o mount --version +kmod 13 depmod -V +e2fsprogs 1.41.4 e2fsck -V +jfsutils 1.1.3 fsck.jfs -V +xfsprogs 2.6.0 xfs_db -V +squashfs-tools 4.0 mksquashfs -version +btrfs-progs 0.18 btrfs --version +pcmciautils 004 pccardctl -V +quota-tools 3.09 quota -V +PPP 2.4.0 pppd --version +nfs-utils 1.0.5 showmount --version +procps 3.2.0 ps --version +udev 081 udevd --version +grub 0.93 grub --version || grub-install --version +mcelog 0.6 mcelog --version +iptables 1.4.2 iptables -V +openssl & libcrypto 1.0.0 openssl version +bc 1.06.95 bc --version +Sphinx\ [#f1]_ 3.4.3 sphinx-build --version +GNU tar 1.28 tar --version +gtags (opcional) 6.6.5 gtags --version +mkimage (opcional) 2017.01 mkimage --version +Python 3.9.x python3 --version +GNU AWK (opcional) 5.1.0 gawk --version +====================== =============== ======================================== + +.. [#f1] O Sphinx é necessário apenas para gerar a documentação do Kernel. + +Compilação do Kernel +********************* + +GCC +--- + +Os requisitos da versão do gcc podem variar dependendo do tipo de CPU +do seu computador. + +Clang/LLVM (opcional) +--------------------- + +A versão formal mais recente do clang e dos utilitários LLVM (de acordo com +releases.llvm.org <https://releases.llvm.org>_) é suportada para a compilação +de kernels. Versões anteriores não têm funcionamento garantido, e poderemos +remover do kernel soluções de contorno (workarounds) que eram utilizadas para +suportar versões mais antigas. Por favor, veja a documentação adicional em: +ref:Building Linux with Clang/LLVM <kbuild_llvm>. + +Rust (opcional) +--------------- + +É necessária uma versão recente do compilador Rust. + +Por favor, consulte Documentation/rust/quick-start.rst para obter instruções +sobre como atender aos requisitos de compilação do suporte a Rust. Em +particular, o alvo (target) rustavailable do Makefile é útil para verificar por +que a cadeia de ferramentas (toolchain) Rust pode não estar sendo detectada. + +bindgen (opcional) +------------------ + +O ``bindgen`` é utilizado para gerar os vínculos (bindings) Rust para o lado C +do kernel. Ele depende da ``libclang``. + +Make +---- + +Você precisará do GNU make 4.0 ou superior para compilar o kernel. + +Bash +---- + +Alguns scripts bash são usados para a compilação do kernel. +É necessário o Bash 4.2 ou mais recente. + +Binutils +-------- + +O binutils 2.30 ou mais recente é necessário para compilar o kernel. + +pkg-config +---------- + +O sistema de compilação, a partir da versão 4.18, requer o pkg-config para +verificar as ferramentas kconfig instaladas e para determinar as configurações +de flags para uso em make {g,x}config. Anteriormente, o pkg-config já era +utilizado, mas não era verificado nem documentado. + +Flex +---- + +Desde o Linux 4.16, o sistema de compilação gera analisadores léxicos durante a +compilação. Isso requer o flex 2.5.35 ou superior. + + +Bison +----- + +Desde o Linux 4.16, o sistema de compilação gera analisadores sintáticos durante +a compilação. Isso requer o bison 2.0 ou superior + +pahole +------ + +Desde o Linux 5.2, se CONFIG_DEBUG_INFO_BTF estiver selecionado, o sistema de +compilação gera BTF (BPF Type Format) a partir do DWARF no vmlinux, e um pouco +depois para os módulos do kernel também. Isso requer o pahole v1.16 ou superior. + +Ele pode ser encontrado nos pacotes ``dwarves`` ou ``pahole`` das +distribuições, ou em https://fedorapeople.org/~acme/dwarves/. + +Perl +---- + +Você precisará do perl 5 e dos seguintes módulos: Getopt::Long, +Getopt::Std, File::Basename e File::Find para compilar o kernel. + +Python +------ + +Várias opções de configuração o exigem: ele é necessário para as configurações +padrão (defconfigs) de arm/arm64, CONFIG_LTO_CLANG, algumas configurações +opcionais de DRM, a ferramenta kernel-doc e a geração da documentação (Sphinx), +entre outros. + +BC +-- + +Você precisará do bc para compilar kernels 3.10 ou superior. + + +OpenSSL +------- + +A assinatura de módulos e a manipulação de certificados externos utilizam o +programa OpenSSL e a biblioteca de criptografia para realizar a criação de +chaves e a geração de assinaturas. + +Você precisará do openssl para compilar kernels 3.7 e superiores se a assinatura +de módulos estiver habilitada. Você também precisará dos pacotes de +desenvolvimento do openssl para compilar kernels 4.3 e superiores. + +Tar +--- + +O GNU tar é necessário caso você deseje habilitar o acesso aos cabeçalhos do +kernel via sysfs (CONFIG_IKHEADERS). + +gtags / GNU GLOBAL (optional) +----------------------------- + +A compilação do kernel requer o GNU GLOBAL versão 6.6.5 ou superior para gerar +arquivos de tags através de make gtags. Isso se deve ao uso da flag -C +(--directory) pelo gtags. + +mkimage +------- + +Esta ferramenta é utilizada ao gerar uma Flat Image Tree (FIT), comumente usada +em plataformas ARM. A ferramenta está disponível através do pacote u-boot-tools +ou pode ser compilada a partir do código-fonte do U-Boot. Veja as instruções em +https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux + +GNU AWK +------- + +O GNU AWK é necessário caso você deseje que a compilação do kernel gere dados de +intervalo de endereços para +módulos integrados (CONFIG_BUILTIN_MODULE_RANGES). + +Utilitários de sistema +*********************** + +Mudanças de arquitetura +------------------------ + +O DevFS tornou-se obsoleto em favor do udev +(https://www.kernel.org/pub/linux/utils/kernel/hotplug/) + +O suporte a UIDs de 32 bits já está implementado. Divirta-se! + +A documentação das funções do Linux está migrando para a documentação embutida +(inline), por meio de comentários com formatação especial próximos às suas +definições no código-fonte. Esses comentários podem ser combinados com arquivos +ReST no diretório Documentation/ para criar uma documentação enriquecida, que +pode então ser convertida para arquivos PostScript, HTML, LaTeX, ePUB e PDF. +Para converter do formato ReST para o formato de sua escolha,você precisará do +Sphinx. + +Util-linux +---------- + +Novas versões do util-linux oferecem suporte no fdisk para discos maiores, +suporte a novas opções para o mount, reconhecimento de mais tipos de partição e +outras funcionalidades interessantes. Você provavelmente vai querer atualizar. + +Ksymoops +-------- + +Se o impensável acontecer e o seu kernel sofrer um oops, você pode precisar da +ferramenta ksymoops para decodificá-lo, mas na maioria dos casos, não será +necessário. É geralmente preferível compilar o kernel com CONFIG_KALLSYMS para +que ele produza dumps legíveis que possam ser usados no estado em que se +encontram (isso também gera uma saída melhor do que a do ksymoops). +Se por algum motivo o seu kernel não for compilado com CONFIG_KALLSYMS e você +não tiver como recompilar e reproduzir o oops com essa opção, você ainda poderá +decodificá-lo com o ksymoops. + +Mkinitrd +-------- + +Estas mudanças no layout da árvore de arquivos /lib/modules também exigem que o +mkinitrd seja atualizado. + +E2fsprogs +--------- + +A versão mais recente do e2fsprogs corrige diversos bugs no fsck e no debugfs. +Obviamente, é uma boa ideia atualizar. + +JFSutils +-------- + +O pacote jfsutils contém os utilitários para o sistema de arquivos. Os seguintes +utilitários estão disponíveis: + +- ``fsck.jfs`` - inicia a reprodução (replay) do log de transações, além de + verificar e reparar uma partição formatada em JFS. + +- ``mkfs.jfs`` - cria uma partição formatada em JFS. + +- Para o seu arquivo changes.rst, a tradução técnica adequada é: + +Outros utilitários de sistema de arquivos também estão disponíveis neste pacote. + +Xfsprogs +-------- + +A versão mais recente do ``xfsprogs`` contém os utilitários ``mkfs.xfs``, +``xfs_db`` e ``xfs_repair``, entre outros, para o sistema de arquivos XFS. Ele é +independente de arquitetura e qualquer versão a partir da 2.0.0 deve funcionar +corretamente com esta versão do código do kernel XFS (recomenda-se a +versão 2.6.0 ou posterior, devido a algumas melhorias significativas). + +PCMCIAutils +----------- + +O PCMCIAutils substitui o pcmcia-cs. Ele configura corretamente os sockets +PCMCIA na inicialização do sistema e carrega os módulos apropriados para +dispositivos PCMCIA de 16 bits, caso o kernel esteja modularizado e o subsistema +de hotplug seja utilizado. + +Quota-tools +----------- + +O suporte a UIDs e GIDs de 32 bits é necessário caso você deseje utilizar o +formato de cota versão 2 mais recente. O quota-tools versão 3.07 e superiores +possuem esse suporte. Utilize a versão recomendada ou superior da tabela acima. + +Intel IA32 microcode +-------------------- + +Um driver foi adicionado para permitir a atualização do microcódigo Intel IA32, +acessível como um dispositivo de caracteres comum (misc). Se você não estiver +usando o udev, você poderá precisar de:: + + mkdir /dev/cpu + mknod /dev/cpu/microcode c 10 184 + chmod 0644 /dev/cpu/microcode + +Se você não estiver usando o udev, você poderá precisar executar os comandos +acima como root antes de poder usar isso. Você provavelmente também desejará +obter o utilitário de espaço de usuário ``microcode_ctl`` para utilizar em +conjunto com este driver. + +udev +---- + +O udev é uma aplicação de espaço de usuário para popular o diretório /dev +dinamicamente, apenas com entradas para dispositivos de fat presentes no +sistema. O udev substitui a funcionalidade básica do devfs, permitindo ao mesmo +tempo a nomeação persistente de dispositivos. + +FUSE +---- + +Necessita do libfuse 2.4.0 ou posterior. O mínimo absoluto é a versão 2.3.0, +mas as opções de montagem direct_io e kernel_cache não funcionarão. + +Redes +****** + +Mudanças gerais +---------------- + +Caso você tenha necessidades avançadas de configuração de rede, você deve +provavelmente considerar o uso das ferramentas de rede do iproute2. + +Filtro de Pacotes / NAT +------------------------ + +O código de filtragem de pacotes e NAT utiliza as mesmas ferramentas da série +anterior de kernels 2.4.x (iptables). Ele ainda inclui módulos de +retrocompatibilidade para o ipchains (estilo 2.2.x) e o ipfwadm (estilo 2.0.x). + +PPP +--- + +O driver PPP foi reestruturado para suportar multilink e permitir que opere +sobre diversas camadas de mídia. Se você utiliza PPP, atualize o pppd para, no +mínimo, a versão 2.4.0. + +Se você não estiver usando o udev, você deve possuir o arquivo de dispositivo +``/dev/ppp``, o qual pode ser criado por:: + + mknod /dev/ppp c 108 0 + +como root. + +NFS-utils +--------- + +Em kernels antigos (2.4 e anteriores), o servidor NFS precisava conhecer +qualquer cliente que pretendesse acessar arquivos via NFS. Essa informação era +fornecida ao kernel pelo mountd quando o cliente montava o sistema de arquivos, +ou pelo exportfs na inicialização do sistema. O exportfs obtinha informações +sobre clientes ativos a partir de /var/lib/nfs/rmtab. + +Esta abordagem é bastante frágil, pois depende da integridade do rmtab, o que +nem sempre é fácil, particularmente ao tentar implementar fail-over. Mesmo +quando o sistema está funcionando bem, o rmtab sofre com o acúmulo de muitas +entradas antigas que nunca são removidas. + +Com kernels modernos, temos a opção de fazer o kernel informar ao mountd quando +recebe uma requisição de um host desconhecido, permitindo que o mountd forneça +as informações de exportação apropriadas ao kernel. Isso remove a dependência do +rmtab e significa que o kernel só precisa conhecer os clientes ativos no +momento. + +Para habilitar esta nova funcionalidade, você precisa:: + + mount -t nfsd nfsd /proc/fs/nfsd + +antes de executar o exportfs ou o mountd. Recomenda-se que todos os serviços NFS +sejam protegidos da internet em geral por um firewall, sempre que possível. + +mcelog +------ + +Em kernels x86, o utilitário mcelog é necessário para processar e registrar +eventos de machine check quando opção CONFIG_X86_MCE está ativada. Eventos de +machine check são erros relatados pela CPU. O processamento desses eventos é +fortemente recomendado. + +Documentação do Kernel +*********************** + +Sphinx +------ + +Por favor, consulte Documentation/doc-guide/sphinx.rst para detalhes sobre os +requisitos do Sphinx. + +rustdoc +------- + +O rustdoc é utilizado para gerar a documentação para código Rust. Por favor, +consulte Documentation/rust/general-information.rst para mais informações. + +Obtendo software atualizado +============================ + +Compilação do kernel +********************** + +gcc +--- + +- <ftp://ftp.gnu.org/gnu/gcc/> + +Clang/LLVM +---------- + +- :ref:`Getting LLVM <getting_llvm>`. + +Rust +---- + +- Documentation/rust/quick-start.rst. + +bindgen +------- + +- Documentation/rust/quick-start.rst. + +Make +---- + +- <ftp://ftp.gnu.org/gnu/make/> + +Bash +---- + +- <ftp://ftp.gnu.org/gnu/bash/> + +Binutils +-------- + +- <https://www.kernel.org/pub/linux/devel/binutils/> + +Flex +---- + +- <https://github.com/westes/flex/releases> + +Bison +----- + +- <ftp://ftp.gnu.org/gnu/bison/> + +OpenSSL +------- + +- <https://www.openssl.org/> + +System utilities +**************** + +Util-linux +---------- + +- <https://www.kernel.org/pub/linux/utils/util-linux/> + +Kmod +---- + +- <https://www.kernel.org/pub/linux/utils/kernel/kmod/> +- <https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git> + +Ksymoops +-------- + +- <https://www.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/> + +Mkinitrd +-------- + +- <https://code.launchpad.net/initrd-tools/main> + +E2fsprogs +--------- + +- <https://www.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/> +- <https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/> + +JFSutils +-------- + +- <https://jfs.sourceforge.net/> + +Xfsprogs +-------- + +- <https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git> +- <https://www.kernel.org/pub/linux/utils/fs/xfs/xfsprogs/> + +Pcmciautils +----------- + +- <https://www.kernel.org/pub/linux/utils/kernel/pcmcia/> + +Quota-tools +----------- + +- <https://sourceforge.net/projects/linuxquota/> + + +Intel P6 microcode +------------------ + +- <https://downloadcenter.intel.com/> + +udev +---- + +- <https://www.freedesktop.org/software/systemd/man/udev.html> + +FUSE +---- + +- <https://github.com/libfuse/libfuse/releases> + +mcelog +------ + +- <https://www.mcelog.org/> + +Redes +****** + +PPP +--- + +- <https://download.samba.org/pub/ppp/> +- <https://git.ozlabs.org/?p=ppp.git> +- <https://github.com/paulusmack/ppp/> + +NFS-utils +--------- + +- <https://sourceforge.net/project/showfiles.php?group_id=14> +- <https://nfs.sourceforge.net/> + +Iptables +-------- + +- <https://netfilter.org/projects/iptables/index.html> + +Ip-route2 +--------- + +- <https://www.kernel.org/pub/linux/utils/net/iproute2/> + +OProfile +-------- + +- <https://oprofile.sf.net/download/> + +Kernel documentation +******************** + +Sphinx +------ + +- <https://www.sphinx-doc.org/> diff --git a/Documentation/translations/pt_BR/process/conclave.rst b/Documentation/translations/pt_BR/process/conclave.rst new file mode 100644 index 000000000000..9071b5a39303 --- /dev/null +++ b/Documentation/translations/pt_BR/process/conclave.rst @@ -0,0 +1,40 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Continuidade do projeto do kernel Linux +======================================= + +O projeto de desenvolvimento do kernel Linux é amplamente distribuído, com mais de +100 mantenedores, cada um trabalhando para manter as mudanças fluindo através de +seus próprios repositórios. A etapa final, no entanto, é centralizada, onde as +mudanças são puxadas para o repositório mainline. Isso é normalmente feito por +Linus Torvalds mas, como foi demonstrado pelo lançamento da versão 4.19 em 2018, +existem outros que podem realizar esse trabalho quando surge a necessidade. + +Caso os mantenedores desse repositório se tornem indispostos ou incapazes de +realizar esse trabalho daqui em diante (incluindo a facilitação de uma transição), +o projeto precisará encontrar um ou mais substitutos sem demora. O processo pelo +qual isso será feito está listado abaixo. O $ORGANIZER é o último organizador do +Maintainer Summit ou o atual presidente do Conselho Consultivo Técnico (TAB) da +Linux Foundation (LF) como reserva. + +- Em até 72 horas, o $ORGANIZER abrirá uma discussão com os convidados do + Maintainer Summit concluído mais recentemente. Uma reunião desses convidados e + do TAB, seja online ou presencial, será agendada o mais rápido possível de uma + forma que maximize o número de pessoas que possam participar. + +- Se não houver ocorrido um Maintainer Summit nos últimos 15 meses, o conjunto de + convidados para esta reunião será determinado pelo TAB. + +- Os convidados para esta reunião podem trazer outros mantenedores conforme + necessário. + +- Esta reunião, presidida pelo $ORGANIZER, considerará opções para a gestão + contínua do repositório de nível superior do kernel, de forma consistente com + a expectativa de maximizar a saúde a longo prazo do projeto e de sua comunidade. + +- Em até duas semanas, um representante deste grupo comunicará à comunidade em + geral, utilizando a lista de discussão ksummit@lists.linux.dev, quais serão os + próximos passos. + +A Linux Foundation, conforme orientada pelo TAB, tomará as medidas necessárias +para apoiar e implementar este plano. diff --git a/Documentation/translations/pt_BR/process/howto.rst b/Documentation/translations/pt_BR/process/howto.rst new file mode 100644 index 000000000000..bcedee7273fd --- /dev/null +++ b/Documentation/translations/pt_BR/process/howto.rst @@ -0,0 +1,637 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _pt_process_howto: + +COMO FAZER o desenvolvimento do kernel Linux +============================================ + +Este é o documento definitivo sobre este tópico. Ele contém instruções +sobre como se tornar um desenvolvedor do kernel Linux e como aprender a +trabalhar com a comunidade de desenvolvimento do kernel Linux. Ele tenta +não conter nada relacionado aos aspectos técnicos da programação do kernel, +mas ajudará a apontar a direção certa para isso. + +Se algo neste documento ficar desatualizado, por favor, envie patches para +o mantenedor deste arquivo, que está listado no final do documento. + + +Introdução +------------ + +Então, você quer aprender como se tornar um desenvolvedor do kernel Linux? +Ou o seu gerente lhe disse: "Vá escrever um driver Linux para este +dispositivo". O objetivo deste documento é ensinar tudo o que você precisa +saber para conseguir isso, descrevendo o processo pelo qual você deve passar +e oferecendo dicas sobre como trabalhar com a comunidade. Ele também tentará +explicar algumas das razões pelas quais a comunidade trabalha da forma que +trabalha. + +O kernel é escrito principalmente em C, com algumas partes dependentes de +arquitetura escritas em assembly. Um bom entendimento de C é necessário para +o desenvolvimento do kernel. O conhecimento de Assembly (de qualquer +arquitetura) não é obrigatório, a menos que você planeje fazer +desenvolvimento de baixo nível para essa arquitetura específica. Embora não +sejam um substituto para uma formação sólida em C e/ou anos de experiência, +os seguintes livros são bons para, no mínimo, referência: + + - "The C Programming Language" por Kernighan e Ritchie [Prentice Hall] + + - "Practical C Programming" por Steve Oualline [O'Reilly] + + - "C: A Reference Manual" por Harbison e Steele [Prentice Hall] + +O kernel é escrito usando o GNU C e a GNU toolchain. Embora ele siga o +padrão ISO C11, ele utiliza uma série de extensões que não estão presentes +no padrão. O kernel é um ambiente C independente (freestanding), sem +dependência da biblioteca C padrão (libc), portanto, algumas partes do +padrão C não são suportadas. Divisões arbitrárias de "long long" e ponto +flutuante não são permitidas. Às vezes, pode ser difícil entender as +suposições que o kernel faz sobre a toolchain e as extensões que ele utiliza +e, infelizmente, não existe uma referência definitiva para elas. Por favor, +verifique as páginas de informações do gcc (`info gcc`) para obter algumas +informações sobre elas. + +Por favor, lembre-se de que você está tentando aprender como trabalhar com a +comunidade de desenvolvimento existente. É um grupo diversificado de pessoas, +com altos padrões de codificação, estilo e procedimento. Esses padrões foram +criados ao longo do tempo com base no que se descobriu funcionar melhor para +uma equipe tão grande e geograficamente dispersa. Tente aprender o máximo +possível sobre esses padrões com antecedência, pois eles estão bem +documentados; não espere que as pessoas se adaptem a você ou à forma de fazer +as coisas da sua empresa. + + +Questões Legais +--------------- + +O código-fonte do kernel Linux é lançado sob a GPL. Por favor, veja o arquivo +COPYING no diretório principal da árvore de fontes. As regras de licenciamento +do kernel Linux e como usar os identificadores `SPDX <https://spdx.org/>`_ no +código-fonte estão descritas em :ref:`Documentation/process/license-rules.rst <kernel_licensing>`. +Se você tiver mais perguntas sobre a licença, por favor, entre em contato com +um advogado e não pergunte na lista de discussão do kernel Linux. As pessoas +nas listas de discussão não são advogados e você não deve confiar em suas +declarações sobre assuntos jurídicos. + +Para perguntas e respostas comuns sobre a GPL, por favor, veja: + + https://www.gnu.org/licenses/gpl-faq.html + + +Documentação +------------ + +A árvore de fontes do kernel Linux possui uma vasta gama de documentos que +são inestimáveis para aprender como interagir com a comunidade do kernel. +Quando novos recursos são adicionados ao kernel, recomenda-se que novos +arquivos de documentação também sejam adicionados explicando como usar o +recurso. Quando uma mudança no kernel faz com que a interface que o kernel +expõe para o espaço do usuário (userspace) mude, recomenda-se que você envie +a informação ou um patch para as páginas de manual explicando a mudança para +o mantenedor das páginas de manual em alx@kernel.org, e coloque em cópia (CC) +a lista linux-api@vger.kernel.org. + +Aqui está uma lista de arquivos que estão na árvore de fontes do kernel e +que são de leitura obrigatória: + + :ref:`Documentation/admin-guide/README.rst <readme>` + Este arquivo fornece um breve histórico sobre o kernel Linux e descreve + o que é necessário fazer para configurar e compilar o kernel. Pessoas + que são novas no kernel devem começar por aqui. + + :doc:`changes` + Este arquivo fornece uma lista das versões mínimas de vários pacotes de + software que são necessários para compilar e executar o kernel com + sucesso. + + :ref:`Documentation/process/coding-style.rst <codingstyle>` + Este documento descreve o estilo de codificação do kernel Linux e parte + da fundamentação por trás dele. Espera-se que todo código novo siga as + diretrizes deste documento. A maioria dos mantenedores apenas aceitará + patches se essas regras forem seguidas, e muitas pessoas apenas + revisarão o código se ele estiver no estilo adequado. + + :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` + Este arquivo descreve em detalhes explícitos como criar e enviar + um patch com sucesso, incluindo (mas não limitado a): + + - Conteúdo do e-mail + - Formato do e-mail + - Para quem enviá-lo + + Seguir estas regras não garantirá o sucesso (já que todos os patches + estão sujeitos a um escrutínio de conteúdo e estilo), mas não segui-las + quase sempre o impedirá. + +Outras excelentes descrições de como criar patches adequadamente são: + + "O Patch Perfeito" + https://www.ozlabs.org/~akpm/stuff/tpp.txt + + "Formato de Submissão de Patch do Kernel Linux" + https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html + + :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>` + Este arquivo descreve a justificativa por trás da decisão consciente de + não ter uma API estável dentro do kernel, incluindo pontos como: + + - Camadas de adaptação (shim-layers) de subsistemas (para compatibilidade?) + - Portabilidade de drivers entre sistemas operacionais. + - Mitigação de mudanças rápidas dentro da árvore de fontes do kernel + (ou impedimento de mudanças rápidas). + + Este documento é crucial para compreender a filosofia de desenvolvimento + do Linux e é muito importante para pessoas que estão migrando para o + Linux vindas do desenvolvimento em outros Sistemas Operacionais. + + :ref:`Documentation/process/security-bugs.rst <securitybugs>` + Se você acredita ter encontrado um problema de segurança no kernel Linux, + por favor, siga os passos descritos neste documento para ajudar a + notificar os desenvolvedores do kernel e auxiliar na resolução do problema. + + :ref:`Documentation/process/management-style.rst <managementstyle>` + Este documento descreve como os mantenedores do kernel Linux operam e o + ethos compartilhado por trás de suas metodologias. Esta é uma leitura + importante para qualquer pessoa nova no desenvolvimento do kernel (ou + para qualquer pessoa simplesmente curiosa sobre isso), pois resolve muitos + equívocos comuns e confusões sobre o comportamento único dos mantenedores + do kernel. + + :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` + Este arquivo descreve as regras sobre como ocorrem os lançamentos das + versões estáveis (stable) do kernel e o que fazer se você desejar que + uma alteração seja incluída em um desses lançamentos. + + :ref:`Documentation/process/kernel-docs.rst <kernel_docs>` + Uma lista de documentação externa que pertence ao desenvolvimento do + kernel. Por favor, consulte esta lista caso não encontre o que está + procurando dentro da documentação interna do kernel. + + :ref:`Documentation/process/applying-patches.rst <applying_patches>` + Uma boa introdução descrevendo exatamente o que é um patch e como + aplicá-lo aos diferentes ramos (branches) de desenvolvimento do kernel. + +O kernel também possui um grande número de documentos que podem ser +gerados automaticamente a partir do próprio código-fonte ou de +marcações ReStructuredText (ReST), como esta. Isso inclui uma +descrição completa da API interna do kernel e regras sobre como +manipular o bloqueio (locking) corretamente. + +Todos esses documentos podem ser gerados em formato PDF ou HTML ao +executar:: + + make pdfdocs + make htmldocs + +respectivamente, a partir do diretório principal do código-fonte do kernel. + +Os documentos que utilizam a marcação ReST serão gerados em +Documentation/output. Eles também podem ser gerados nos formatos +LaTeX e ePub com:: + + make latexdocs + make epubdocs + +Como se tornar um desenvolvedor do kernel +------------------------------------------ + +Se você não sabe nada sobre o desenvolvimento do kernel Linux, você deve +consultar o projeto Linux KernelNewbies: + + https://kernelnewbies.org + +Ele consiste em uma lista de discussão útil onde você pode fazer quase +qualquer tipo de pergunta básica sobre o desenvolvimento do kernel +(certifique-se de pesquisar nos arquivos primeiro, antes de perguntar +algo que já foi respondido no passado). Ele também possui um canal de +IRC que você pode usar para fazer perguntas em tempo real, e muita +documentação útil para aprender sobre o desenvolvimento do kernel Linux. + +O site possui informações básicas sobre a organização do código, +subsistemas e projetos atuais (tanto in-tree quanto out-of-tree). +Também descreve algumas informações logísticas básicas, como por exemplo, +como compilar um kernel e aplicar um patch. + +Se você não sabe por onde começar, mas deseja procurar alguma tarefa +para iniciar sua integração na comunidade de desenvolvimento do kernel, +acesse o projeto Linux Kernel Janitor: + + https://kernelnewbies.org/KernelJanitors + +É um ótimo lugar para começar. Ele descreve uma lista de problemas +relativamente simples que precisam ser limpos e corrigidos dentro da +árvore de códigos-fonte do kernel Linux. Ao trabalhar com os +desenvolvedores responsáveis por este projeto, você aprenderá o básico +sobre como incluir seu patch na árvore do kernel Linux e, +possivelmente, será orientado sobre o que trabalhar em seguida, caso +ainda não tenha uma ideia. + +Antes de fazer qualquer modificação real no código do kernel Linux, é +imperativo entender como o código em questão funciona. Para esse +propósito, nada é melhor do que lê-lo diretamente (a maioria das partes +complexas está bem comentada), talvez até com a ajuda de ferramentas +especializadas. Uma ferramenta particularmente recomendada é o projeto +Linux Cross-Reference, que é capaz de apresentar o código-fonte em um +formato de página web indexada e auto-referenciada. Um excelente +repositório atualizado do código do kernel pode ser encontrado em: + + https://elixir.bootlin.com/ + + +O processo de desenvolvimento +----------------------------- + +O processo de desenvolvimento do kernel Linux consiste atualmente em algumas +"branches" (ramos) principais diferentes e muitos ramos de subsistemas +específicos. Esses diferentes ramos são: + + - Árvore principal (mainline) do Linus + - Várias árvores estáveis com múltiplos números de versão principal + - Árvores específicas de subsistemas + - Árvore de testes de integração linux-next + +Árvore principal (Mainline tree) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A árvore principal é mantida por Linus Torvalds e pode ser encontrada em +https://kernel.org ou no repositório. Seu processo de desenvolvimento é +o seguinte: + + - Assim que um novo kernel é lançado, uma janela de duas semanas é aberta; + durante esse período, os mantenedores podem enviar grandes diffs para + Linus, geralmente patches que já foram incluídos na linux-next por algumas + semanas. A forma preferida de enviar grandes mudanças é usando o git + (a ferramenta de gerenciamento de código-fonte do kernel, mais informações + podem ser encontradas em https://git-scm.com/), mas patches simples + também são aceitos. + - Após duas semanas, um kernel -rc1 é lançado e o foco passa a ser tornar + o novo kernel o mais sólido possível. A maioria dos patches neste estágio + deve corrigir uma regressão. Bugs que sempre existiram não são regressões, + portanto, envie esses tipos de correções apenas se forem importantes. + Observe que um driver (ou sistema de arquivos) totalmente novo pode ser + aceito após o -rc1 porque não há risco de causar regressões com tal + mudança, desde que a alteração seja autocontida e não afete áreas fora do + código que está sendo adicionado. O git pode ser usado para enviar + patches para Linus após o lançamento do -rc1, mas os patches também + precisam ser enviados para uma lista de discussão pública para revisão. + - Um novo -rc é lançado sempre que Linus considerar que a árvore git atual + está em um estado razoavelmente estável e adequado para testes. O objetivo + é lançar um novo kernel -rc a cada semana. + - O processo continua até que o kernel seja considerado "pronto"; o + processo deve durar cerca de 6 semanas. + +Vale a pena mencionar o que Andrew Morton escreveu na lista de discussão +do kernel Linux sobre os lançamentos do kernel: + + *"Ninguém sabe quando um kernel será lançado, porque ele é + lançado de acordo com o status percebido dos bugs, não de acordo + com um cronograma pré-concebido."* + +Várias árvores estáveis com múltiplos números de versão principal +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Kernels com versões de 3 partes são kernels -stable (estáveis). Eles +contêm correções relativamente pequenas e críticas para problemas de +segurança ou regressões significativas descobertas em um determinado +lançamento principal da árvore mainline. Cada lançamento em uma série +estável principal incrementa a terceira parte do número da versão, +mantendo as duas primeiras partes iguais. + +Este é o ramo recomendado para usuários que desejam o kernel estável +mais recente e não estão interessados em ajudar a testar versões de +desenvolvimento ou experimentais. + +As árvores estáveis são mantidas pela equipe "stable" +<stable@vger.kernel.org> e são lançadas conforme a necessidade exigir. +O período normal de lançamento é de aproximadamente duas semanas, mas +pode ser mais longo se não houver problemas urgentes. Por outro lado, +um problema relacionado à segurança pode fazer com que um lançamento +ocorra quase instantaneamente. + +O arquivo :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` +na árvore do kernel documenta quais tipos de mudanças são aceitáveis para +a árvore -stable e como o processo de lançamento funciona. + +Árvores específicas de subsistemas +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Os mantenedores dos vários subsistemas do kernel — e também muitos +desenvolvedores de subsistemas do kernel — expõem seu estado atual de +desenvolvimento em repositórios de código-fonte. Dessa forma, outros +podem ver o que está acontecendo nas diferentes áreas do kernel. Em +áreas onde o desenvolvimento é rápido, um desenvolvedor pode ser +solicitado a basear suas submissões em tal árvore de subsistema do +kernel para que conflitos entre a submissão e outros trabalhos já em +andamento sejam evitados. + +A maioria desses repositórios são árvores git, mas também existem outros +SCMs em uso, ou filas de patches sendo publicadas como séries quilt. Os +endereços desses repositórios de subsistemas estão listados no arquivo +MAINTAINERS. Muitos deles podem ser navegados em https://git.kernel.org/. + +Antes que um patch proposto seja incluído em tal árvore de subsistema, +ele está sujeito a uma revisão que ocorre principalmente em listas de +discussão (veja a seção respectiva abaixo). Para vários subsistemas do +kernel, este processo de revisão é rastreado com a ferramenta patchwork. +O Patchwork oferece uma interface web que mostra as postagens de patches, +quaisquer comentários sobre um patch ou revisões feitas a ele, e os +mantenedores podem marcar os patches como "sob revisão", "aceitos" ou +"rejeitados". A maioria desses sites patchwork está listada em +https://patchwork.kernel.org/. + +Árvore de testes de integração linux-next +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Antes que as atualizações das árvores de subsistemas sejam mescladas na +árvore mainline, elas precisam ser testadas quanto à integração. Para +este propósito, existe um repositório de testes especial no qual +praticamente todas as árvores de subsistemas são integradas (pulled) +quase diariamente: + + https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git + +Dessa forma, a linux-next oferece uma visão resumida do que se espera +que entre no kernel mainline no próximo período de mesclagem (merge +window). Testadores aventureiros são muito bem-vindos para testar a +linux-next em tempo de execução. + + +Relato de Bugs +-------------- + +O arquivo 'Documentation/admin-guide/reporting-issues.rst' no diretório +principal de códigos-fonte do kernel descreve como relatar um possível +bug no kernel e detalha que tipo de informação é necessária para os +desenvolvedores do kernel ajudarem a rastrear o problema. + +Gerenciando relatos de bugs +--------------------------- + +Uma das melhores maneiras de colocar em prática suas habilidades de hacking +é corrigindo bugs relatados por outras pessoas. Você não apenas ajudará a +tornar o kernel mais estável, mas também aprenderá a resolver problemas do +mundo real, melhorará suas habilidades e outros desenvolvedores passarão a +notar sua presença. Corrigir bugs é uma das melhores formas de obter mérito +entre outros desenvolvedores, pois poucas pessoas gostam de gastar tempo +corrigindo bugs de terceiros. + +Para trabalhar em relatos de bugs já existentes, encontre um subsistema no +qual você esteja interessado. Verifique no arquivo MAINTAINERS para onde +os bugs daquele subsistema são relatados; geralmente será uma lista de +discussão, raramente um rastreador de bugs (bugtracker). Pesquise nos +arquivos de mensagens do local indicado por relatos recentes e ajude onde +achar apropriado. Você também pode verificar o site +https://bugzilla.kernel.org para relatos de bugs; apenas alguns +subsistemas do kernel o utilizam ativamente para relato ou rastreamento, +entretanto, bugs de todo o kernel acabam sendo registrados lá. + + +Listas de discussão +------------------- + +Como alguns dos documentos acima descrevem, a maioria dos desenvolvedores +do núcleo (core) do kernel participa da Linux Kernel Mailing List (LKML). +Detalhes sobre como se inscrever e cancelar a inscrição na lista podem +ser encontrados em: + + https://subspace.kernel.org/subscribing.html + +Existem arquivos de mensagens da lista na web em muitos lugares diferentes. +Use um mecanismo de busca para encontrar esses arquivos. Por exemplo: + + https://lore.kernel.org/linux-kernel/ + +É altamente recomendável que você pesquise nos arquivos sobre o tópico que +deseja abordar antes de postar na lista. Muitas coisas já discutidas em +detalhes estão registradas apenas nos arquivos das listas de discussão. + +A maioria dos subsistemas individuais do kernel também possui sua própria +lista de discussão separada, onde realizam seus esforços de desenvolvimento. +Consulte o arquivo MAINTAINERS para obter uma lista de quais são essas +listas para os diferentes grupos. + +Muitas das listas estão hospedadas no kernel.org. Informações sobre elas +podem ser encontradas em: + + https://subspace.kernel.org + +Por favor, lembre-se de seguir bons hábitos de comportamento ao usar as +listas. Embora um pouco clichê, a URL a seguir possui algumas diretrizes +simples para interagir com a lista (ou qualquer outra lista): + + https://subspace.kernel.org/etiquette.html + +Se várias pessoas responderem ao seu e-mail, a lista de destinatários em +CC: pode se tornar bem grande. Não remova ninguém da lista CC: sem um +bom motivo, e não responda apenas para o endereço da lista. Acostume-se +a receber o e-mail duas vezes (um do remetente e outro da lista) e não +tente ajustar isso adicionando cabeçalhos de e-mail complexos; as pessoas +não gostarão disso. + +Lembre-se de manter o contexto e a atribuição de suas respostas intactos; +mantenha as linhas do tipo "John Kernelhacker escreveu...:" no topo da +sua resposta e adicione seus comentários entre as seções citadas +individualmente, em vez de escrever tudo no topo do e-mail. + +Se você adicionar patches ao seu e-mail, certifique-se de que sejam texto +puro legível, conforme declarado em +:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`. +Os desenvolvedores do kernel não querem lidar com anexos ou patches +compactados; eles podem querer comentar linhas individuais do seu patch, +o que só funciona dessa forma. Certifique-se de usar um programa de +e-mail que não altere espaços e caracteres de tabulação (tabs). Um bom +primeiro teste é enviar o e-mail para si mesmo e tentar aplicar o seu +próprio patch. Se isso não funcionar, conserte seu programa de e-mail ou +troque-o até que funcione. + +Acima de tudo, por favor, lembre-se de mostrar respeito aos outros +inscritos. + + +Trabalhando com a comunidade +---------------------------- + +O objetivo da comunidade do kernel é fornecer o melhor kernel possível. +Quando você envia um patch para aceitação, ele será revisado por seus +méritos técnicos e apenas por eles. Então, o que você deve esperar? + + - críticas + - comentários + - solicitações de mudança + - solicitações de justificativa + - silêncio + +Lembre-se, isso faz parte do processo de incluir seu patch no kernel. +Você deve ser capaz de aceitar críticas e comentários sobre seus patches, +avaliá-los em nível técnico e retrabalhar seus patches ou fornecer +raciocínios claros e concisos sobre o porquê de certas mudanças não +deverem ser feitas. Se não houver respostas à sua postagem, aguarde +alguns dias e tente novamente; às vezes, as coisas se perdem no enorme +volume de mensagens. + +O que você não deve fazer? + + - esperar que seu patch seja aceito sem questionamentos + - tornar-se defensivo + - ignorar comentários + - reenviar o patch sem fazer nenhuma das alterações solicitadas + +Em uma comunidade que busca a melhor solução técnica possível, sempre +haverá opiniões divergentes sobre o quão benéfico é um patch. Você deve +ser cooperativo e estar disposto a adaptar sua ideia para que ela se +encaixe no kernel. Ou, pelo menos, estar disposto a provar que sua ideia +vale a pena. Lembre-se: estar errado é aceitável, desde que você esteja +disposto a trabalhar em direção a uma solução correta. + +É normal que as respostas ao seu primeiro patch sejam apenas uma lista +de uma dúzia de coisas que você deve corrigir. Isso **não** implica que +seu patch não será aceito e **não** é algo pessoal contra você. Simplesmente +corrija todos os problemas apontados em seu patch e envie-o novamente. + + +Diferenças entre a comunidade do kernel e estruturas corporativas +----------------------------------------------------------------- + +A comunidade do kernel trabalha de forma diferente da maioria dos ambientes +tradicionais de desenvolvimento corporativo. Aqui está uma lista de coisas +que você pode tentar fazer para evitar problemas: + + Boas coisas a dizer em relação às suas mudanças propostas: + + - "Isto resolve múltiplos problemas." + - "Isto remove 2000 linhas de código." + - "Aqui está um patch que explica o que estou tentando descrever." + - "Eu testei isso em 5 arquiteturas diferentes..." + - "Aqui está uma série de pequenos patches que..." + - "Isto aumenta a performance em máquinas comuns..." + + Coisas ruins que você deve evitar dizer: + + - "Nós fizemos desta forma no AIX/ptx/Solaris, portanto deve ser bom..." + - "Eu faço isso há 20 anos, então..." + - "Isto é necessário para minha empresa ganhar dinheiro." + - "Isto é para nossa linha de produtos Enterprise." + - "Aqui está meu documento de design de 1000 páginas que descreve minha ideia." + - "Estou trabalhando nisso há 6 meses..." + - "Aqui está um patch de 5000 linhas que..." + - "Eu reescrevi toda a bagunça atual, e aqui está..." + - "Eu tenho um prazo (deadline), e este patch precisa ser aplicado agora." + +Outra forma em que a comunidade do kernel difere da maioria dos ambientes +tradicionais de engenharia de software é a natureza anônima da interação. +Um benefício de usar e-mail e IRC como as principais formas de comunicação +é a ausência de discriminação baseada em gênero ou raça. O ambiente de +trabalho do kernel Linux aceita mulheres e minorias porque tudo o que você +é, é um endereço de e-mail. O aspecto internacional também ajuda a nivelar +o campo de jogo porque você não pode adivinhar o gênero com base no nome +de uma pessoa. Um homem pode se chamar Andrea e uma mulher pode se chamar +Pat. A maioria das mulheres que trabalharam no kernel Linux e expressaram +uma opinião tiveram experiências positivas. + +A barreira do idioma pode causar problemas para algumas pessoas que não +se sentem confortáveis com o inglês. Um bom domínio do idioma pode ser +necessário para transmitir ideias adequadamente nas listas de discussão, +por isso recomenda-se que você verifique seus e-mails para garantir que +façam sentido em inglês antes de enviá-los. + + +Divida suas alterações +---------------------- + +A comunidade do kernel Linux não aceita de bom grado grandes blocos de +código jogados de uma só vez. As mudanças precisam ser devidamente +introduzidas, discutidas e divididas em porções minúsculas e individuais. +Isso é quase o exato oposto do que as empresas costumam fazer. Sua proposta +também deve ser introduzida muito cedo no processo de desenvolvimento, para +que você possa receber feedback sobre o que está fazendo. Isso também permite +que a comunidade sinta que você está trabalhando com eles, e não simplesmente +usando-os como um depósito para sua funcionalidade. No entanto, não envie +50 e-mails de uma só vez para uma lista de discussão; sua série de patches +deve ser menor que isso quase sempre. + +As razões para dividir as coisas são as seguintes: + +1) Patches pequenos aumentam a probabilidade de serem aplicados, pois não + exigem muito tempo ou esforço para verificar sua correção. Um patch de + 5 linhas pode ser aplicado por um mantenedor com apenas um olhar rápido. + No entanto, um patch de 500 linhas pode levar horas para ser revisado + (o tempo que leva é exponencialmente proporcional ao tamanho do patch, + ou algo assim). + + Patches pequenos também tornam muito fácil a depuração (debug) quando + algo dá errado. É muito mais fácil reverter patches um por um do que + dissecar um patch muito grande após ele ter sido aplicado (e quebrado algo). + +2) É importante não apenas enviar patches pequenos, mas também reescrever + e simplificar (ou simplesmente reordenar) os patches antes de submetê-los. + +Aqui está uma analogia do desenvolvedor do kernel Al Viro: + + *"Pense em um professor corrigindo o dever de casa de um aluno de + matemática. O professor não quer ver as tentativas e erros do aluno + antes de chegar à solução. Ele quer ver a resposta mais limpa e + elegante. Um bom aluno sabe disso e nunca enviaria seu trabalho + intermediário antes da solução final.* + + *O mesmo vale para o desenvolvimento do kernel. Os mantenedores e + revisores não querem ver o processo de pensamento por trás da solução + do problema que se está resolvendo. Eles querem ver uma solução + simples e elegante."* + +Pode ser desafiador manter o equilíbrio entre apresentar uma solução +elegante e trabalhar em conjunto com a comunidade discutindo seu trabalho +inacabado. Portanto, é bom entrar no processo cedo para obter feedback e +melhorar seu trabalho, mas também manter suas alterações em pequenos blocos +que possam ser aceitos, mesmo quando sua tarefa completa ainda não esteja +pronta para inclusão. + +Também entenda que não é aceitável enviar patches para inclusão que estejam +inacabados e que serão "consertados mais tarde". + + +Justifique sua alteração +------------------------ + +Além de dividir seus patches, é muito importante que você deixe a comunidade +Linux saber por que eles deveriam adicionar essa mudança. Novas +funcionalidades devem ser justificadas como necessárias e úteis. + + +Documente sua alteração +----------------------- + +Ao enviar seus patches, preste atenção especial ao que você diz no texto +do seu e-mail. Essas informações se tornarão as informações do ChangeLog +para o patch e serão preservadas para que todos vejam para sempre. Elas +devem descrever o patch completamente, contendo: + + - por que a mudança é necessária + - a abordagem geral de design no patch + - detalhes de implementação + - resultados de testes + +Para mais detalhes sobre como tudo isso deve ser, por favor, veja a seção +ChangeLog do documento: + + "O Patch Perfeito" + https://www.ozlabs.org/~akpm/stuff/tpp.txt + +Todas essas coisas às vezes são muito difíceis de fazer. Pode levar anos +para aperfeiçoar essas práticas (se é que é possível). É um processo +contínuo de melhoria que exige muita paciência e determinação. Mas não +desista, é possível. Muitos fizeram isso antes, e cada um teve que começar +exatamente onde você está agora. + +---------- + +Agradecimentos a Paolo Ciarrocchi, que permitiu que a seção "Processo de +Desenvolvimento" (https://lwn.net/Articles/94386/) fosse baseada em um +texto que ele escreveu, e a Randy Dunlap e Gerrit Huizenga por parte da +lista de coisas que você deve ou não dizer. Também agradecemos a Pat Mochel, +Hanna Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, +Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, +Adrian Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, +Michael Kerrisk e Alex Shepard por suas revisões, comentários e contribuições. +Sem a ajuda deles, este documento não teria sido possível. + +Mantenedor: Greg Kroah-Hartman <greg@kroah.com> diff --git a/Documentation/translations/pt_BR/process/maintainer-handbooks.rst b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst new file mode 100644 index 000000000000..ba36df8eeaf1 --- /dev/null +++ b/Documentation/translations/pt_BR/process/maintainer-handbooks.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Notas sobre o processo de desenvolvimento de subsistemas e mantenedores +======================================================================= + +O propósito deste documento é fornecer informações específicas de +subsistemas que são suplementares ao manual geral do processo de +desenvolvimento. + +Conteúdos: + +.. toctree:: + :numbered: + :maxdepth: 2 + + maintainer-netdev + maintainer-soc + maintainer-soc-clean-dts diff --git a/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst b/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst new file mode 100644 index 000000000000..6480ff08b9d8 --- /dev/null +++ b/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst @@ -0,0 +1,435 @@ +.. SPDX-License-Identifier: GPL-2.0 + +KVM x86 +======= + +Prefácio +-------- + +O KVM se esforça para ser uma comunidade acolhedora; as contribuições de +recém-chegados são valorizadas e incentivadas. Por favor, não se sinta +desanimado ou intimidado pela extensão deste documento e pelas muitas +regras/diretrizes que ele contém. Todo mundo comete erros e todo mundo já foi um +novato em algum momento. Desde que você faça um esforço honesto para seguir as +diretrizes do KVM x86, seja receptivo ao feedback e aprenda com os erros que +cometer, você será recebido de braços abertos, não com tochas e forquilhas. + +(TL;DR) +-------- +Testes são obrigatórios. Seja consistente com os estilos e padrões estabelecidos. + +Árvores +------- +O KVM x86 está atualmente em um período de transição: deixando de fazer parte da +árvore principal do KVM para se tornar "apenas mais uma arquitetura KVM". Como tal, +o KVM x86 está dividido entre a árvore principal do KVM, +``git.kernel.org/pub/scm/virt/kvm/kvm.git``, e uma árvore específica para KVM x86, +``github.com/kvm-x86/linux.git``. + +De modo geral, as correções (fixes) para o ciclo atual são aplicadas diretamente +na árvore principal do KVM, enquanto todo o desenvolvimento para o próximo ciclo +é roteado através da árvore do KVM x86. No caso improvável de uma correção para o +ciclo atual ser roteada através da árvore do KVM x86, ela será aplicada à branch +``fixes`` antes de seguir para a árvore principal do KVM. + +Note que espera-se que este período de transição dure bastante tempo, ou seja, +será o status quo em um futuro próximo. + +Branches +~~~~~~~~ +A árvore do KVM x86 é organizada em múltiplas branches de tópicos (topic +branches). O objetivo de usar branches de tópicos mais granulares é facilitar o +acompanhamento de uma área específica de desenvolvimento e limitar os danos +colaterais de erros humanos e/ou commits com bugs; por exemplo, descartar o +commit HEAD de uma branch de tópico não tem impacto nos hashes SHA1 de outros +commits em andamento, e a necessidade de rejeitar um pull request devido a bugs +atrasa apenas aquela branch de tópico específica. + +Todas as branches de tópicos, exceto a ``next`` e a ``fixes``, são incorporadas +na ``next`` via um "Cthulhu merge" conforme a necessidade, ou seja, sempre que +uma branch de tópico é atualizada. Como resultado, force pushes para a branch +``next`` são comuns. + +Ciclo de Vida +~~~~~~~~~~~~~ +As correções (fixes) destinadas ao lançamento atual, também conhecido como +mainline, são normalmente aplicadas diretamente na árvore principal do KVM, ou +seja, não passam pela árvore do KVM x86. + +As mudanças destinadas ao próximo lançamento são roteadas através da árvore do +KVM x86. Pull requests (do KVM x86 para o KVM principal) são enviados para cada +branch de tópico do KVM x86, normalmente na semana anterior à abertura da janela +de merge por Linus, por exemplo, na semana seguinte ao rc7 para lançamentos +"normais". Se tudo correr bem, as branches de tópicos são incorporadas ao pull +request principal do KVM enviado durante a janela de merge de Linus. + +A árvore do KVM x86 não possui sua própria janela de merge oficial, mas há um +"soft close" (fechamento flexível) por volta do rc5 para novos recursos, e um +"soft close" por volta do rc6 para correções (para o próximo lançamento; veja +acima para correções destinadas ao lançamento atual). + +Cronograma +---------- +As submissões são normalmente revisadas e aplicadas em ordem FIFO (primeiro a +entrar, primeiro a sair), com alguma margem de manobra para o tamanho de uma +série, patches que estão "cache hot", etc. Correções (fixes), especialmente para +o lançamento atual e/ou árvores estáveis (stable trees), têm prioridade na fila. +Patches que serão aceitos através de uma árvore não-KVM (mais frequentemente +através da árvore "tip") e/ou que possuam outros "acks"/revisões também ganham +certa prioridade. + +Note que a grande maioria das revisões é feita entre o rc1 e o rc6, +aproximadamente. O período entre o rc6 e o próximo rc1 é usado para colocar +outras tarefas em dia, ou seja, o "silêncio de rádio" durante este período não é +incomum. + +Pings para obter uma atualização de status são bem-vindos, mas tenha em mente o +tempo do ciclo de lançamento atual e tenha expectativas realistas. Se você está +dando um ping para aceitação — ou seja, não apenas para feedback ou uma +atualização — por favor, faça tudo o que puder, dentro do razoável, para garantir +que seus patches estejam prontos para o merge! Pings em séries que quebram o +build ou falham em testes resultam em mantenedores infelizes! + +Desenvolvimento +--------------- + +Árvore/Branch Base +~~~~~~~~~~~~~~~~~~ +Correções destinadas ao lançamento atual, também conhecido como mainline, devem +ser baseadas em ``git://git.kernel.org/pub/scm/virt/kvm/kvm.git master``. Note +que as correções não garantem inclusão automática no lançamento atual. Não +existe uma regra única, mas tipicamente apenas correções para bugs que sejam +urgentes, críticos e/ou que tenham sido introduzidos no lançamento atual devem +ser destinadas ao lançamento atual. + +Todo o restante deve ser baseado em ``kvm-x86/next``, ou seja, não há +necessidade de selecionar uma branch de tópico específica como base. Se houver +conflitos e/ou dependências entre as branches de tópicos, é trabalho do +mantenedor resolvê-los. + +A única exceção ao uso da ``kvm-x86/next`` como base é se um patch/série for uma +série multi-arquitetura (multi-arch), ou seja, possuir modificações não triviais +no código comum do KVM e/ou possuir mudanças mais do que superficiais no código +de outras arquiteturas. Patches/séries multi-arquitetura devem, em vez disso, +ser baseados em um ponto comum e estável no histórico do KVM, por exemplo, o +release candidate no qual a ``kvm-x86 next`` se baseia. Se você não tiver +certeza se um patch/série é verdadeiramente multi-arquitetura, erre pelo lado da +cautela e trate-o como tal, ou seja, use uma base comum. + +Estilo de Codificação +~~~~~~~~~~~~~~~~~~~~~ +Quando se trata de estilo, nomenclatura, padrões, etc., a consistência é a +prioridade número um no KVM x86. Se tudo mais falhar, siga o que já existe. + +Com algumas ressalvas listadas abaixo, siga o estilo de codificação preferido +dos mantenedores da árvore "tip" (:ref:`maintainer-tip-coding-style`), já que +patches/séries frequentemente tocam tanto arquivos do KVM quanto arquivos x86 +não-KVM, ou seja, atraem a atenção de mantenedores do KVM *e* da árvore "tip". + +O uso de "reverse fir tree" (árvore de abeto invertida), também conhecido como +"árvore de Natal invertida", para declarações de variáveis não é estritamente +obrigatório, embora ainda seja preferido. + +Exceto por alguns casos excepcionais, não use comentários kernel-doc para +funções. A grande maioria das funções "públicas" do KVM não são verdadeiramente +públicas, pois se destinam apenas ao consumo interno do KVM (há planos para +privatizar os headers e exports do KVM para reforçar isso). + +Comentários +~~~~~~~~~~~ +Escreva comentários usando o modo imperativo e evite pronomes. Use comentários +para fornecer uma visão geral de alto nível do código e/ou para explicar por +que o código faz o que faz. Não reitere o que o código faz literalmente; deixe +o código falar por si mesmo. Se o código em si for inescrutável, comentários +não ajudarão. + +Referências ao SDM e ao APM +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Grande parte da base de código do KVM está diretamente ligada ao comportamento +arquitetural definido no Manual de Desenvolvimento de Software (SDM) da Intel e +no Manual do Programador de Arquitetura (APM) da AMD. O uso de "Intel SDM" e +"AMD APM", ou até mesmo apenas "SDM" ou "APM", sem contexto adicional, é +perfeitamente aceitável. + +Não faça referência a seções, tabelas, figuras, etc., por número, especialmente +em comentários. Em vez disso, se necessário (veja abaixo), copie e cole o trecho +relevante e referencie seções/tabelas/figuras pelo nome. Os layouts do SDM e do +APM mudam constantemente e, portanto, os números/rótulos não são estáveis. + +De modo geral, não faça referência explícita nem copie e cole do SDM ou do APM +em comentários. Com poucas exceções, o KVM *deve* respeitar o comportamento +arquitetural; portanto, subentende-se que o comportamento do KVM está emulando o +comportamento do SDM e/ou do APM. Note que fazer referência ao SDM/APM em +changelogs para justificar a mudança e fornecer contexto é perfeitamente +aceitável e incentivado. + +Shortlog +~~~~~~~~ +O formato de prefixo preferencial é ``KVM: <topic>:``, onde ``<topic>`` é um dos +seguintes:: + + - x86 + - x86/mmu + - x86/pmu + - x86/xen + - selftests + - SVM + - nSVM + - VMX + - nVMX + +**NÃO use x86/kvm!** ``x86/kvm`` é usado exclusivamente para mudanças no Linux +como convidado (guest) de um KVM, ou seja, para ``arch/x86/kernel/kvm.c``. Não +use nomes de arquivos ou caminhos completos de arquivos como prefixo do +assunto/shortlog. + +Note que estes não se alinham com as branches de tópicos (as branches de tópicos +se preocupam muito mais com conflitos de código). + +Todos os nomes são sensíveis a maiúsculas e minúsculas! ``KVM: x86:`` é bom, +``kvm: vmx:`` não é. + +Comece com letra maiúscula a primeira palavra da descrição condensada do patch, +mas omita a pontuação final. Ex.:: + + KVM: x86: Fix a null pointer dereference in function_xyz() + +e não:: + + kvm: x86: fix a null pointer dereference in function_xyz. + +Se um patch tocar em múltiplos tópicos, suba na árvore conceitual para encontrar +o primeiro pai comum (que geralmente é apenas ``x86``). Em caso de dúvida, +``git log caminho/do/arquivo`` deve fornecer uma dica razoável. + +Novos tópicos surgem ocasionalmente, mas, por favor, inicie uma discussão na +lista se desejar propor a introdução de um novo tópico; ou seja, não aja por +conta própria. + +Veja :ref:`the_canonical_patch_format` para mais informações, com uma ressalva: +não trate o limite de 70-75 caracteres como um limite absoluto e rígido. Em +vez disso, use 75 caracteres como um limite firme, mas não rígido, e use 80 +caracteres como um limite intransponível. Ou seja, permita que o shortlog +ultrapasse alguns caracteres do limite padrão se você tiver um bom motivo para +fazê-lo. + +Changelog +~~~~~~~~~ +O mais importante: escreva os changelogs usando o modo imperativo e evite o uso +de pronomes. + +Veja :ref:`describe_changes` para mais informações, com uma ressalva: comece com +uma breve descrição das mudanças reais e, em seguida, apresente o contexto e o +histórico. Note! Esta ordem entra em conflito direto com a abordagem preferida +da árvore "tip"! Por favor, siga o estilo preferido da árvore "tip" ao enviar +patches que visam primariamente o código de arch/x86 que _NÃO_ seja código KVM. + +Declarar o que um patch faz antes de mergulhar nos detalhes é preferido pelo KVM +x86 por vários motivos. Primeiro e mais importante, qual código está sendo +realmente alterado é, reconhecidamente, a informação mais importante e, +portanto, essa informação deve ser fácil de encontrar. Changelogs que escondem +"o que está mudando de fato" em uma única linha após 3 ou mais parágrafos de +histórico tornam muito difícil encontrar essa informação. + +Para uma revisão inicial, pode-se argumentar que "o que está quebrado" é mais +importante, mas para uma leitura rápida de logs e arqueologia do git, os +detalhes minuciosos importam cada vez menos. Por exemplo, ao fazer uma série de +"git blame", os detalhes de cada mudança ao longo do caminho são inúteis; os +detalhes só importam para o culpado. Fornecer "o que mudou" facilita determinar +rapidamente se um commit pode ou não ser de interesse. + +Outro benefício de declarar "o que está mudando" primeiro é que quase sempre é +possível declarar "o que está mudando" em uma única frase. Por outro lado, +exceto pelos bugs mais simples, todos exigem várias frases ou parágrafos para +descrever totalmente o problema. Se tanto "o que está mudando" quanto "qual é o +bug" forem super curtos, a ordem não importa. Mas se um for mais curto (quase +sempre o "o que está mudando"), então cobrir o mais curto primeiro é vantajoso +porque é menos inconveniente para leitores/revisores que têm uma preferência de +ordenação estrita. Ex: ter que pular uma frase para chegar ao contexto é menos +doloroso do que ter que pular três parágrafos para chegar ao "o que está +mudando". + +Correções (Fixes) +~~~~~~~~~~~~~~~~~ +Se uma mudança corrige um bug do KVM/kernel, adicione uma tag Fixes:, mesmo que +a mudança não precise ser portada (backported) para kernels estáveis, e mesmo +que a mudança corrija um bug em uma versão mais antiga. + +Por outro lado, se uma correção realmente precisar de backport, marque +explicitamente o patch com "Cc: stable@vger.kernel.org" (embora o e-mail em si +não precise enviar cópia para a lista stable); o KVM x86 opta por não realizar +o backport automático de tags Fixes: por padrão. Alguns patches selecionados +automaticamente são portados, mas exigem aprovação explícita do mantenedor +(pesquise por MANUALSEL). + +Referências a Funções +~~~~~~~~~~~~~~~~~~~~~ +Quando uma função for mencionada em um comentário, changelog ou shortlog (ou em +qualquer outro lugar, aliás), use o formato ``nome_da_funcao()``. Os parênteses +fornecem contexto e removem a ambiguidade da referência. + +Testes +------ +No mínimo, *todos* os patches de uma série devem compilar sem erros para +KVM_INTEL=m, KVM_AMD=m e KVM_WERROR=y. Compilar cada combinação possível de +Kconfigs não é viável, mas quanto mais, melhor. KVM_SMM, KVM_XEN, PROVE_LOCKING +e X86_64 são opções (knobs) particularmente interessantes para se testar. + +A execução de KVM selftests e KVM-unit-tests também é obrigatória (e, para +afirmar o óbvio, os testes precisam passar). A única exceção é para mudanças +que tenham probabilidade insignificante de afetar o comportamento em tempo de +execução, por exemplo, patches que apenas modificam comentários. Sempre que +possível e relevante, o teste tanto em Intel quanto em AMD é fortemente +preferido. A inicialização de uma VM real é incentivada, mas não obrigatória. + +Para mudanças que tocam o código de shadow paging do KVM, executar com o TDP +(EPT/NPT) desabilitado é obrigatório. Para mudanças que afetam o código comum da +MMU do KVM, a execução com o TDP desabilitado é fortemente incentivada. Para +todas as outras mudanças, se o código sendo modificado depender de e/ou +interagir com um parâmetro de módulo (module param), o teste com as +configurações relevantes é obrigatório. + +Note que o KVM selftests e o KVM-unit-tests possuem falhas conhecidas. Se você +suspeitar que uma falha não se deve às suas alterações, verifique se a *exata +mesma* falha ocorre com e sem as suas mudanças. + +Mudanças que tocam a documentação em reStructuredText, ou seja, arquivos .rst, +devem compilar o htmldocs de forma limpa, ou seja, sem novos avisos (warnings) +ou erros. + +Se você não puder testar totalmente uma mudança, por exemplo, devido à falta de +hardware, declare claramente qual nível de teste você foi capaz de realizar, +por exemplo, na cover letter (carta de apresentação). + +Novos Recursos +~~~~~~~~~~~~~~ +Com uma exceção, novos recursos *devem* vir acompanhados de cobertura de testes. +Testes específicos do KVM não são estritamente obrigatórios, por exemplo, se a +cobertura for fornecida ao executar uma VM convidada (guest) suficientemente +habilitada, ou ao executar um selftest de kernel relacionado em uma VM, mas +testes dedicados do KVM são preferidos em todos os casos. Casos de teste +negativos, em particular, são obrigatórios para a habilitação de novos recursos +de hardware, já que fluxos de erro e exceção raramente são exercitados +simplesmente ao executar uma VM. + +A única exceção a esta regra é se o KVM estiver simplesmente anunciando suporte +para um recurso via KVM_GET_SUPPORTED_CPUID, ou seja, para instruções/recursos +que o KVM não pode impedir um convidado de usar e para os quais não há uma +habilitação real. + +Note que "novos recursos" não significa apenas "novos recursos de hardware"! +Novos recursos que não podem ser bem validados usando os KVM selftests e/ou +KVM-unit-tests existentes devem vir acompanhados de testes. + +Enviar o desenvolvimento de novos recursos sem testes para obter feedback +antecipado é mais do que bem-vindo, mas tais submissões devem ser marcadas como +RFC, e a carta de apresentação (cover letter) deve declarar claramente que tipo +de feedback é solicitado/esperado. Não abuse do processo de RFC; as RFCs +normalmente não receberão uma revisão profunda. + +Correções de Bugs +~~~~~~~~~~~~~~~~~ +Exceto por bugs "óbvios" encontrados por inspeção, as correções devem vir +acompanhadas de um reprodutor (reproducer) para o bug que está sendo corrigido. +Em muitos casos, o reprodutor é implícito, por exemplo, para erros de build e +falhas de teste, mas ainda assim deve estar claro para os leitores o que está +quebrado e como verificar a correção. Alguma margem de manobra é dada para +bugs encontrados através de cargas de trabalho ou testes não públicos, mas a +disponibilização de testes de regressão para tais bugs é fortemente preferida. + +Em geral, testes de regressão são preferidos para qualquer bug que não seja +trivial de ser atingido. Por exemplo, mesmo que o bug tenha sido originalmente +encontrado por um fuzzer como o syzkaller, um teste de regressão direcionado +pode ser justificável se o bug exigir que se atinja uma condição de corrida do +tipo "uma em um milhão". + +Note que os bugs do KVM raramente são urgentes *e* não triviais de reproduzir. +Pergunte a si mesmo se um bug é realmente o fim do mundo antes de enviar uma +correção sem um reprodutor. + +Postagem +-------- + +Links +~~~~~ +Não faça referência explícita a relatórios de bugs, versões anteriores de um +patch/série, etc., através de cabeçalhos ``In-Reply-To:``. O uso de +``In-Reply-To:`` torna-se uma bagunça infernal para grandes séries e/ou quando +o número de versões aumenta, e o ``In-Reply-To:`` é inútil para qualquer +pessoa que não tenha a mensagem original, por exemplo, se alguém não estava +em cópia (Cc) no relatório do bug ou se a lista de destinatários mudar entre +as versões. + +Para vincular a um relatório de bug, versão anterior ou qualquer coisa de +interesse, use links do lore. Para referenciar versão(ões) anterior(es), de modo +geral, não inclua um Link: no changelog, pois não há necessidade de registrar o +histórico no git; ou seja, coloque o link na carta de apresentação (cover +letter) ou na seção que o git ignora. Forneça um Link: formal para relatórios +de bugs e/ou discussões que levaram ao patch. O contexto de por que uma mudança +foi feita é altamente valioso para futuros leitores. + +Base do Git (Git Base) +~~~~~~~~~~~~~~~~~~~~~~ +Se você estiver usando o git versão 2.9.0 ou posterior (Googlers, isso inclui +todos vocês!), use ``git format-patch`` com a flag ``--base`` para incluir +automaticamente as informações da árvore base nos patches gerados. + +Note que ``--base=auto`` funciona conforme o esperado se, e somente se, o +upstream de uma branch estiver definido para a branch de tópico base; por +exemplo, ele fará a coisa errada se o seu upstream estiver definido para o seu +repositório pessoal para fins de backup. Uma solução "auto" alternativa é +derivar os nomes das suas branches de desenvolvimento com base no seu tópico +KVM x86 e alimentar isso no ``--base``. Por exemplo, +``x86/pmu/minha_branch`` e, em seguida, escrever um pequeno wrapper para +extrair ``pmu`` do nome da branch atual para resultar em ``--base=x/pmu``, onde +``x`` é o nome que seu repositório usa para rastrear o remoto do KVM x86. + +Postagem Conjunta de Testes +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +KVM selftests que estão associados a mudanças no KVM, por exemplo, testes de +regressão para correções de bugs, devem ser postados junto com as mudanças do +KVM como uma única série. As regras padrão do kernel para bissecção (bisection) +se aplicam, ou seja, mudanças no KVM que resultem em falhas de teste devem ser +ordenadas após as atualizações dos selftests e, vice-versa, novos testes que +falhem devido a bugs do KVM devem ser ordenados após as correções do KVM. + +KVM-unit-tests devem *sempre* ser postados separadamente. Ferramentas, como o +b4 am, não sabem que o KVM-unit-tests é um repositório separado e ficam +confusas quando os patches de uma série se aplicam a árvores diferentes. Para +vincular os patches do KVM-unit-tests aos patches do KVM, poste primeiro as +mudanças do KVM e, em seguida, forneça um link do lore para o patch/série do +KVM no(s) patch(es) do KVM-unit-tests. + +Notificações +------------ +Quando um patch/série é oficialmente aceito, um e-mail de notificação será +enviado em resposta à postagem original (carta de apresentação para séries de +múltiplos patches). A notificação incluirá a árvore e a branch de tópico, +juntamente com os SHA1s dos commits dos patches aplicados. + +Se um subconjunto de patches for aplicado, isso será claramente declarado na +notificação. A menos que seja dito o contrário, subentende-se que quaisquer +patches na série que não foram aceitos precisam de mais trabalho e devem ser +enviados em uma nova versão. + +Se, por algum motivo, um patch for descartado após ter sido oficialmente +aceito, uma resposta será enviada ao e-mail de notificação explicando o porquê +do descarte, bem como os próximos passos. + +Estabilidade de SHA1 +~~~~~~~~~~~~~~~~~~~~ +Os SHA1s não têm garantia de serem 100% estáveis até que cheguem na árvore do +Linus! Um SHA1 é *geralmente* estável uma vez que a notificação tenha sido +enviada, mas imprevistos acontecem. Na maioria dos casos, uma atualização no +e-mail de notificação será fornecida se o SHA1 de um patch aplicado mudar. No +entanto, em alguns cenários, por exemplo, se todas as branches do KVM x86 +precisarem de rebase, as notificações individuais não serão enviadas. + +Vulnerabilidades +---------------- +Bugs que podem ser explorados pelo convidado (guest) para atacar o hospedeiro +(host) (kernel ou espaço do usuário), ou que podem ser explorados por uma VM +aninhada (nested) contra o *seu* próprio hospedeiro (L2 atacando L1), são de +interesse particular para o KVM. Por favor, siga o protocolo em +:ref:`securitybugs` se você suspeitar que um bug possa levar a um escape, +vazamento de dados, etc. diff --git a/Documentation/translations/pt_BR/process/maintainer-netdev.rst b/Documentation/translations/pt_BR/process/maintainer-netdev.rst new file mode 100644 index 000000000000..5de2828041b9 --- /dev/null +++ b/Documentation/translations/pt_BR/process/maintainer-netdev.rst @@ -0,0 +1,596 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== +Subsistema de Rede do Linux (netdev) +===================================== + +tl;dr +----- + +- **Direcione seu patch para uma árvore** – use ``[PATCH net]``para correções + ou ``[PATCH net-next]`` para novas funcionalidades. +- **Tag Fixes** – para correções, a tag ``Fixes:`` é obrigatória, + independentemente da árvore de destino. +- **Tamanho da série** – não envie séries grandes (> 15 patches);divida-as em + partes menores. +- **Intervalo de envio** – não reenvie seus patches dentro de um período de 24 + horas. +- **Reverse xmas tree** – organize as declarações de variáveis locais da mais + longa para a mais curta. + +netdev +------ +A **netdev** é a lista de discussão para todos os assuntos do Linux relacionados +a rede. Isso inclui qualquer item encontrado em ``net/`` (ex: código principal +como IPv6) e em ``drivers/net`` (ex: drivers específicos de hardware) na árvore +de diretórios do Linux. + +Note que alguns subsistemas (ex: drivers de rede sem fio/wireless), que possuem +um alto volume de tráfego, possuem suas próprias listas de discussão e árvores +específicas. + +Como muitas outras listas de discussão do Linux, a lista netdev é hospedada no +`kernel.org <https://www.kernel.org/>`_, com arquivos disponíveis em +https://lore.kernel.org/netdev/. + +À exceção dos subsistemas mencionados anteriormente, todo o desenvolvimento de +rede do Linux (ex: RFCs, revisões, comentários, etc.) ocorre na **netdev**. + +Ciclo de Desenvolvimento +------------------------ + +Aqui está um pouco de informação contextual sobre a cadência de desenvolvimento +do Linux. Cada nova versão (release) inicia-se com uma "janela de mesclagem" +(*merge window*) de duas semanas, onde os mantenedores principais enviam suas +novas implementações para o Linus para incorporação na árvore principal +(*mainline tree*). + +Após as duas semanas, a janela de mesclagem é fechada e a versão é +nomeada/etiquetada como ``-rc1``. Nenhuma funcionalidade nova é incorporada à +árvore principal após isso -- espera-se apenas correções (*fixes*) para o +conteúdo da rc1. + +Após cerca de uma semana coletando correções para a rc1, a rc2 é lançada. Isso +se repete semanalmente até a rc7 (tipicamente; às vezes rc6 se o ritmo estiver +calmo, ou rc8 se houver muita instabilidade); uma semana após a última vX.Y-rcN +ser concluída, a versão oficial vX.Y é lançada. + +Para descobrir em que ponto do ciclo estamos agora - carregue a página da +mainline (Linus) aqui: + + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + +e observe o topo da seção de "tags". Se for rc1, estamos no início do ciclo +de desenvolvimento. Se a rc7 foi marcada há uma semana, então um lançamento +é provavelmente iminente. Se a tag mais recente for uma tag de lançamento +final (sem o sufixo ``-rcN``) - muito provavelmente estamos em uma janela de +mesclagem (*merge window*) e o ``net-next`` está fechado. + +Árvores git e fluxo de patches +------------------------------ + +Existem duas árvores de rede (repositórios git) em jogo. Ambas são coordenadas +por David Miller, o mantenedor principal de rede. Há a árvore ``net``e a árvore +``net-next``. Como você provavelmente pode adivinhar pelos nomes, a árvore +``net`` é para correções de código existente já na árvore mainline de Linus, e a +``net-next`` é para onde o novo código vai para o lançamento futuro. +Você pode encontrar as árvores aqui: + +- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git +- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git + +Relacionando isso ao desenvolvimento do kernel: no início da janela de mesclagem +(*merge window*) de 2 semanas, a árvore ``net-next`` será fechada, sem novas +mudanças ou funcionalidades. O conteúdo novo acumulado nas últimas 10 semanas +será passado para a mainline/Linus via um *pull request* para a vX.Y ao mesmo +tempo, a árvore ``net`` começará a acumular correções para este conteúdo enviado +relacionado à vX.Y. + +Um anúncio indicando quando a ``net-next`` foi fechada é geralmente enviado para +a netdev, mas sabendo o que foi dito acima, você pode prever isso com +antecedência. + +.. warning:: + + Não envie novo conteúdo para a ``net-next`` para a netdev durante o período + em que a árvore ``net-next`` estiver fechada. + +Patches RFC enviados apenas para revisão são obviamente bem-vindos a qualquer +momento (use ``--subject-prefix='RFC net-next'`` com ``git format-patch``). + +Pouco depois das duas semanas terem passado (e a vX.Y-rc1 ser lançada), a árvore +para a ``net-next`` reabre para coletar conteúdo para o próximo lançamento +(vX.Y+1). + +Se você não estiver inscrito na netdev e/ou simplesmente não tiver certeza se a +``net-next`` já reabriu, basta verificar o link do repositório git da +``net-next`` acima para quaisquer novos *commits* relacionados à rede. Você +também pode verificar o seguinte site para o status atual: + + https://netdev.bots.linux.dev/net-next.html + +A árvore ``net`` continua a coletar correções para o conteúdo da vX.Y e é +enviada de volta para Linus em intervalos regulares (~semanais). Isso significa +que o foco da ``net`` é a estabilização e correções de bugs. + +Finalmente, a vX.Y é lançada e todo o ciclo recomeça. + +Revisão de patches da netdev +---------------------------- + +Status do patch +~~~~~~~~~~~~~~~ + +O status de um patch pode ser verificado olhando a fila principal do patchwork +para a netdev: + + https://patchwork.kernel.org/project/netdevbpf/list/ + +O campo "State" informará exatamente onde as coisas estão com o seu patch: + +================= ============================================================ +Estado do patch Descrição +================= ============================================================ +New, Under review revisão pendente, o patch está na fila do mantenedor + para revisão; os dois estados são usados alternadamente + (dependendo do co-mantenedor exato que estiver lidando + com o patchwork no momento) +Accepted o patch foi aplicado à árvore de rede apropriada, + isso é geralmente definido de forma automática pelo pw-bot +Needs ACK aguardando um "ack" de um especialista da área + ou testes +Changes requested o patch não passou na revisão, espera-se uma nova + revisão com mudanças apropriadas no código e na mensagem + de commit +Rejected o patch foi rejeitado e não se espera uma nova + revisão +Not applicable espera-se que o patch seja aplicado fora do + subsistema de rede +Awaiting upstream o patch deve ser revisado e tratado pelo sub-mantenedor + apropriado, que o enviará para as árvores de rede; + patches definidos como ``Awaiting upstream`` no patchwork + da netdev geralmente permanecerão neste estado, + independentemente de o sub-mantenedor ter solicitado + mudanças, aceito ou rejeitado o patch +Deferred o patch precisa ser reenviado mais tarde, geralmente + devido a alguma dependência ou porque foi enviado para + uma árvore fechada +Superseded uma nova versão do patch foi enviada, geralmente + definido pelo pw-bot +RFC não deve ser aplicado, geralmente não está na + fila de revisão do mantenedor; o pw-bot pode definir + patches para este estado automaticamente com base nas + tags do assunto +================= ============================================================ + +Os patches são indexados pelo cabeçalho ``Message-ID`` dos e-mails que os +transportaram; portanto, se você tiver problemas para encontrar seu patch, +anexe o valor do ``Message-ID`` à URL acima. + +Atualizando o status do patch +----------------------------- + +Colaboradores e revisores não têm permissões para atualizar o estado do patch +diretamente no patchwork. O Patchwork não expõe muitas informações sobre o +histórico do estado dos patches; portanto, ter várias pessoas atualizando o +estado leva a confusões. + +Em vez de delegar permissões do patchwork, a netdev usa um robô de e-mail +simples (bot) que procura por comandos/linhas especiais dentro dos e-mails +enviados para a lista de discussão. Por exemplo, para marcar uma série como +Mudanças Solicitadas (*Changes Requested*), é necessário enviar a seguinte +linha em qualquer lugar na thread do e-mail:: + + pw-bot: changes-requested + +Como resultado, o bot definirá toda a série como Mudanças Solicitadas. Isso +pode ser útil quando o autor descobre um bug em sua própria série e deseja +evitar que ela seja aplicada. + +O uso do bot é totalmente opcional; em caso de dúvida, ignore completamente a +existência dele. Os mantenedores classificarão e atualizarão o estado dos +patches por conta própria. Nenhum e-mail deve ser enviado à lista com o +propósito principal de se comunicar com o bot; os comandos do bot devem ser +vistos como metadados. + +O uso do bot é restrito aos autores dos patches (o cabeçalho ``From:`` no envio +do patch e no comando deve coincidir!), mantenedores do código modificado de +acordo com o arquivo MAINTAINERS (novamente, o ``From:`` deve coincidir +com a entrada no MAINTAINERS) e alguns revisores seniores. + +O bot registra sua atividade aqui: + + https://netdev.bots.linux.dev/pw-bot.html + +Prazos de revisão +~~~~~~~~~~~~~~~~~ + +De modo geral, os patches são triados rapidamente (em menos de 48h). Mas +seja paciente; se o seu patch estiver ativo no patchwork (ou seja, listado +na lista de patches do projeto), as chances de ele ter sido esquecido são +próximas de zero. + +O alto volume de desenvolvimento na netdev faz com que os revisores encerrem +discussões de forma relativamente rápida. É muito improvável que novos +comentários e respostas cheguem após uma semana de silêncio. Se um +patch não estiver mais ativo no patchwork e a thread ficar inativa por mais de +uma semana - esclareça os próximos passos e/ou envie a próxima versão. + +Especificamente para envios de RFC, se ninguém responder em uma semana ou os +revisores perderam o envio ou não têm opiniões fortes a respeito. Se o código +estiver pronto, reenvie como um PATCH. + +E-mails dizendo apenas "ping" ou "bump" são considerados rudes. Se você não +conseguir identificar o status do patch pelo patchwork ou onde a discussão +parou - descreva sua melhor suposição e pergunte se ela está correta. Por +exemplo:: + + Não entendo quais são os próximos passos. A Pessoa X parece estar descontente + com A; devo fazer B e enviar novamente os patches? + +.. _Solicitações de mudanças: + +Mudanças solicitadas +~~~~~~~~~~~~~~~~~~~~ + +Patches marcados como ``Changes Requested`` precisam ser revisados. A nova +versão deve vir com um registro de alterações (changelog), +preferencialmente incluindo links para as postagens anteriores, por exemplo:: + + [PATCH net-next v3] net: faz as vacas dizerem "muuu" + + Mesmo os usuários que não bebem leite apreciam ouvir as vacas dizendo + "muuu". + + A quantidade de mugidos dependerá da taxa de pacotes, portanto, deve + corresponder muito bem ao ciclo diurno. + + Signed-off-by: Joe Defarmer <joe@barn.org> + --- + v3: + - adicionada uma nota sobre a flutuação do mugido conforme a hora + do dia na + mensagem de commit + v2: https://lore.kernel.org/netdev/123themessageid@barn.org/ + - corrigido argumento ausente na kernel doc para netif_is_bovine() + - corrigido vazamento de memória (memory leak) em + netdev_register_cow() + v1: https://lore.kernel.org/netdev/456getstheclicks@barn.org/ + +A mensagem de commit deve ser revisada para responder a quaisquer perguntas que +os revisores tenham feito em discussões anteriores. Ocasionalmente, a +atualização da mensagem de commit será a única mudança na nova versão. + +Reenvios parciais +~~~~~~~~~~~~~~~~~ + +Por favor, sempre reenvie a série completa de patches e certifique-se de +numerar seus patches de forma que fique claro que este é o conjunto mais +recente e completo de patches que pode ser aplicado. Não tente reenviar apenas +os patches que foram alterados. + +Lidando com patches aplicados incorretamente +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Ocasionalmente, uma série de patches é aplicada antes de receber feedback +crítico, ou a versão errada de uma série é aplicada. + +Não é possível fazer o patch desaparecer uma vez que ele foi enviado (pushed); +o histórico de commits nas árvores netdev é imutável. Por favor, envie versões +incrementais sobre o que foi mesclado para corrigir os patches da maneira que +eles ficariam se a sua série de patches mais recente fosse mesclada. + +Em casos onde uma reversão completa (revert) é necessária, a reversão deve ser +enviada como um patch para a lista com uma mensagem de commit explicando os +problemas técnicos com o commit revertido. Reversões devem ser usadas como +último recurso, quando a mudança original está completamente errada; correções +incrementais são preferidas. + +Árvore estável +~~~~~~~~~~~~~~ + +Embora antigamente as submissões para a netdev não devessem carregar tags +explícitas ``CC: stable@vger.kernel.org``, esse não é mais o caso hoje em dia. +Por favor, siga as regras padrão de estabilidade em +``Documentation/process/stable-kernel-rules.rst``, e certifique-se de incluir as +tags Fixes apropriadas! + +Correções de segurança +~~~~~~~~~~~~~~~~~~~~~~ + +Não envie e-mails diretamente para os mantenedores da netdev se você acha que +descobriu um bug que possa ter possíveis implicações de segurança. O atual +mantenedor da netdev tem solicitado consistentemente que as pessoas usem as +listas de discussão e não entrem em contato diretamente. Se você não estiver +de acordo com isso, considere enviar um e-mail para security@kernel.org ou +ler sobre http://oss-security.openwall.org/wiki/mailing-lists/distros como +possíveis mecanismos alternativos. + +Envio conjunto de mudanças em componentes de espaço do usuário +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +O código de espaço do usuário (*user space*) que exercita funcionalidades do +kernel deve ser enviado juntamente com os patches do kernel. Isso dá aos +revisores a chance de ver como qualquer nova interface é usada e quão +bem ela funciona. + +Quando as ferramentas de espaço do usuário residem no próprio repositório do +kernel, todas as alterações devem geralmente vir em uma única série. Se a série +se tornar muito grande ou se o projeto de espaço do usuário não for revisado na +netdev, inclua um link para um repositório público onde os patches de espaço do +usuário possam ser vistos. + +No caso de ferramentas de espaço do usuário residirem em um repositório +separado, mas serem revisadas na netdev (por exemplo, patches para ferramentas +``iproute2``), os patches do kernel e do espaço do usuário devem formar séries +(threads) separadas quando postados na lista de discussão, por exemplo:: + + [PATCH net-next 0/3] net: carta de apresentação de alguma funcionalidade + └─ [PATCH net-next 1/3] net: preparação para alguma funcionalidade + └─ [PATCH net-next 2/3] net: implementação de alguma funcionalidade + └─ [PATCH net-next 3/3] selftest: net: alguma funcionalidade + + [PATCH iproute2-next] ip: adiciona suporte para alguma funcionalidade + +A postagem em uma única thread é desencorajada porque confunde o patchwork +(a partir da versão 2.2.2 do patchwork). + +Envio conjunto de selftests +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Os selftests devem fazer parte da mesma série que as mudanças de código. +Especificamente para correções, tanto a mudança de código quanto o teste +relacionado devem ir para a mesma árvore (os testes podem não ter uma tag +Fixes, o que é esperado). Misturar mudanças de código e mudanças de teste em +um único commit é desencorajado. + +Preparando as mudanças +---------------------- + +Atenção aos detalhes é importante. Releia seu próprio trabalho como se você +fosse o revisor. Você pode começar usando o ``checkpatch.pl``, talvez até com +a flag ``--strict``. Mas não seja robótico e irracional ao fazer isso. Se sua +mudança for uma correção de bug, certifique-se de que seu log de commit indique +o sintoma visível para o usuário final, a razão subjacente de por que isso +acontece e, se necessário, explique por que a correção proposta é a melhor +maneira de resolver as coisas. Não corrompa espaços em branco e, como é comum, +não use recuos incorretos em argumentos de função que abrangem várias linhas. +Se for o seu primeiro patch, envie-o para si mesmo por e-mail para que você +possa testar a aplicação em uma árvore sem patches para confirmar que a +infraestrutura não o danificou. + +Finalmente, volte e leia ``Documentation/process/submitting-patches.rst`` +para ter certeza de que não está repetindo algum erro comum documentado lá. + +Indicando a árvore de destino +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Para ajudar os mantenedores e os bots de CI, você deve marcar explicitamente +qual árvore seu patch tem como alvo. Supondo que você use git, utilize a flag +de prefixo:: + + git format-patch --subject-prefix='PATCH net-next' inicio..fim + +Use ``net`` em vez de ``net-next`` (sempre em letras minúsculas) no comando +acima para conteúdos de correção de bugs da árvore ``net``. + +Dividindo o trabalho em patches +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Coloque-se no lugar do revisor. Cada patch é lido separadamente e, portanto, +deve constituir um passo compreensível em direção ao seu objetivo declarado. + +Evite enviar séries com mais de 15 patches. Séries maiores levam mais tempo +para serem revisadas, pois os revisores adiarão a análise até encontrarem um +grande bloco de tempo disponível. Uma série pequena pode ser revisada em pouco +tempo, então os mantenedores simplesmente a revisam de imediato. Como resultado, +uma sequência de séries menores é mesclada mais rapidamente e com melhor +cobertura de revisão. Reenviar séries grandes também aumenta o tráfego na lista +de discussão. + +Limitar patches pendentes na lista de discussão +----------------------------------------------- + +Evite ter mais de 15 patches, em todas as séries, pendentes de revisão na lista +de discussão para uma única árvore. Em outras palavras, um máximo de 15 patches +sob revisão na ``net`` e um máximo de 15 patches sob revisão na ``net-next``. + +Este limite tem o objetivo de focar o esforço do desenvolvedor nos testes dos +patches antes da revisão upstream, auxiliando a qualidade das submissões +upstream e aliviando a carga sobre os revisores. + +Ordenação de variáveis locais ("árvore invertida", "RCS") +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A netdev tem uma convenção para ordenar variáveis locais em funções. Ordene as +linhas de declaração de variáveis da mais longa para a mais curta, por exemplo:: + + struct scatterlist *sg; + struct sk_buff *skb; + int err, i; + +Se houver dependências entre as variáveis que impeçam a ordenação, mova a +inicialização para fora da linha de declaração. + +Precedência de formatação +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Ao trabalhar em código existente que utiliza formatação não padrão, faça com +que seu código siga as diretrizes mais recentes, para que, eventualmente, +todo o código no domínio da netdev esteja no formato preferido. + +Uso de construções gerenciadas por dispositivo e cleanup.h +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Historicamente, a netdev permanece cética em relação às promessas de todas as +APIs de "auto-limpeza" (auto-cleanup), incluindo até mesmo os auxiliares +``devm_``. Eles não são o estilo preferido de implementação, apenas um estilo +aceitável. + +O uso de ``guard()`` é desencorajado em qualquer função com mais de 20 linhas; +``scoped_guard()`` é considerado mais legível. O uso de lock/unlock normal +ainda é (levemente) preferido. + +Construções de limpeza de baixo nível (como ``__free()``) podem ser usadas ao +construir APIs e auxiliares, especialmente iteradores com escopo. No entanto, o +uso direto de ``__free()`` dentro do núcleo de rede (networking core) e drivers +é desencorajado. Orientações semelhantes se aplicam à declaração de variáveis +no meio da função. + +Patches de limpeza (Clean-up patches) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A netdev desencoraja patches que realizam limpezas simples que não estejam no +contexto de outro trabalho. Por exemplo: + +* Tratar avisos do ``checkpatch.pl`` e outros avisos triviais de estilo de + codificação +* Tratar problemas de Ordenação de variáveis locais +* Conversões para APIs gerenciadas por dispositivo (auxiliares ``devm_``) + +Isso ocorre porque se considera que a agitação (*churn*) que tais mudanças +produzem tem um custo maior do que o valor de tais limpezas. + +Por outro lado, correções de ortografia e gramática não são desencorajadas. + +Reenviando após a revisão +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Aguarde pelo menos 24 horas entre as postagens. Isso garantirá que revisores de +todas as localizações geográficas tenham a chance de se manifestar. Não espere +muito tempo (semanas) entre as postagens, pois isso tornará mais difícil para +os revisores lembrarem de todo o contexto. + +Certifique-se de tratar todo o feedback em sua nova postagem. Não envie uma +nova versão do código se a discussão sobre a versão anterior ainda estiver em +andamento, a menos que seja instruído diretamente por um revisor. + +A nova versão dos patches deve ser postada como uma thread separada, não como +uma resposta à postagem anterior. O registro de alterações (changelog) deve +incluir um link para a postagem anterior (veja :ref:`Solicitações +de mudanças`). + +Testes +------ + +Nível de teste esperado +~~~~~~~~~~~~~~~~~~~~~~~ + +No mínimo, suas alterações devem passar por uma compilação ``allyesconfig`` e +uma ``allmodconfig`` com ``W=1`` definido, sem novos avisos ou falhas. + +O ideal é que você tenha feito testes em tempo de execução específicos para sua +alteração, e que a série de patches contenha um conjunto de selftests do kernel +para ``tools/testing/selftests/net`` ou usando o framework KUnit. + +Espera-se que você teste suas alterações no topo da árvore de rede relevante +(``net`` ou ``net-next``) e não, por exemplo, em uma árvore estável ou na +``linux-next``. + +Verificações do patchwork +~~~~~~~~~~~~~~~~~~~~~~~~~ + +As verificações (*checks*) no patchwork são, em sua maioria, wrappers simples +em torno de scripts existentes do kernel; as fontes estão disponíveis em: + +https://github.com/linux-netdev/nipa/tree/master/tests + +**Não** envie seus patches apenas para executá-los nas verificações. Você deve +garantir que seus patches estejam prontos, testando-os localmente antes de +postar na lista de discussão. A instância do bot de build do patchwork fica +sobrecarregada com muita facilidade e a netdev@vger realmente não precisa de +mais tráfego se pudermos evitar. + +netdevsim +~~~~~~~~~ + +O ``netdevsim`` é um driver de teste que pode ser usado para exercitar APIs de +configuração de driver sem a necessidade de hardware compatível. Mock-ups e +testes baseados no ``netdevsim`` são fortemente encorajados ao adicionar novas +APIs, mas o ``netdevsim`` em si **não** é considerado um caso de uso/usuário. +Você também deve implementar as novas APIs em um driver real. + +Não damos garantias de que o ``netdevsim`` mudará no futuro de uma forma que +quebraria o que normalmente seria considerado uAPI. O ``netdevsim`` é reservado +apenas para uso por testes upstream, portanto, quaisquer novos recursos do +``netdevsim`` devem ser acompanhados de selftests em ``tools/testing/selftests/``. + +Status de suporte para drivers +------------------------------ + +.. note: + +Os requisitos a seguir aplicam-se apenas a drivers de NIC Ethernet. + +A netdev define requisitos adicionais para drivers que desejam adquirir o status +``Supported`` (Suportado) no arquivo MAINTAINERS. Drivers ``Supported`` devem +executar todos os testes de driver upstream e relatar os resultados duas vezes +por dia. Drivers que não cumprirem este requisito devem usar o status +``Maintained`` (Mantido). Atualmente, não há diferença na forma como os drivers +``Supported`` e ``Maintained`` são tratados no upstream. + +As regras exatas que um driver deve seguir para adquirir o status ``Supported``: + +1. Deve executar todos os testes sob os alvos ``drivers/net`` e + ``drivers/net/hw`` dos selftests do Linux. A execução e o relato + de testes privados / internos também são bem-vindos, mas os testes + upstream são obrigatórios. + +2. A frequência mínima de execução é uma vez a cada 12 horas. Deve + testar o branch designado a partir do feed de branches selecionado. + Observe que os branches são construídos automaticamente e estão + expostos à postagem intencional de patches maliciosos; portanto, + os sistemas de teste devem ser isolados. + +3. Drivers que suportam múltiplas gerações de dispositivos devem + testar pelo menos um dispositivo de cada geração. Um manifesto do + ambiente de teste (*testbed manifest* - formato exato a definir) + deve descrever os modelos de dispositivos testados. + +4. Os testes devem ser executados de forma confiável; se múltiplos + branches forem ignorados ou se os testes falharem devido a problemas + no ambiente de execução, o status ``Supported`` será retirado. + +5. Falhas nos testes devido a bugs no driver ou no próprio teste, + ou falta de suporte para a funcionalidade que o teste visa, *não* + são motivo para a perda do status ``Supported``. + +O CI da netdev manterá uma página oficial de dispositivos suportados, listando +seus resultados de testes recentes. + +O mantenedor do driver pode providenciar para que outra pessoa execute o teste; +não há exigência de que a pessoa listada como mantenedora (ou seu empregador) +seja responsável pela execução dos testes. Colaborações entre +fornecedores, hospedagem de CI no GitHub (GH CI), outros repositórios sob o +linux-netdev, etc., são muito bem-vindas. + +Veja https://github.com/linux-netdev/nipa/wiki para mais informações sobre o CI +da netdev. Sinta-se à vontade para entrar em contato com os mantenedores ou com +a lista para quaisquer dúvidas. + +Orientações para revisores +-------------------------- + +Revisar patches de outras pessoas na lista é altamente incentivado, +independentemente do nível de experiência. Para orientações gerais e dicas +úteis, consulte `revisão de tópicos avançados de desenvolvimento`. + +É seguro assumir que os mantenedores da netdev conhecem a comunidade e o nível +de experiência dos revisores. Os revisores não devem se preocupar com o fato de +seus comentários impedirem ou desviarem o fluxo de patches. Revisores menos +experientes são fortemente incentivados a fazer uma revisão mais aprofundada das +submissões e não focar exclusivamente em questões triviais ou subjetivas, como +formatação de código, tags, etc. + +Depoimentos / feedback +---------------------- + +Algumas empresas utilizam o feedback de colegas em revisões de desempenho de +funcionários. Sinta-se à vontade para solicitar feedback dos mantenedores da +netdev, especialmente se você dedica uma quantidade significativa de tempo +revisando código e se esforça além do esperado para melhorar a infraestrutura +compartilhada. + +O feedback deve ser solicitado por você, o colaborador, e será sempre +compartilhado com você (mesmo que você solicite que ele seja enviado ao seu +gerente).
\ No newline at end of file diff --git a/Documentation/translations/pt_BR/process/maintainer-soc-clean-dts.rst b/Documentation/translations/pt_BR/process/maintainer-soc-clean-dts.rst new file mode 100644 index 000000000000..a7e7bf0f106f --- /dev/null +++ b/Documentation/translations/pt_BR/process/maintainer-soc-clean-dts.rst @@ -0,0 +1,28 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================================== +Plataformas SoC com Requisitos de Conformidade de DTS +===================================================== + +Visão Geral +----------- + +As plataformas SoC ou subarquiteturas devem seguir todas as regras de +Documentation/process/maintainer-soc.rst. Este documento, referenciado em +MAINTAINERS, impõe requisitos adicionais listados abaixo. + +Conformidade Estrita com DT Schema de DTS e dtc +----------------------------------------------- + +Nenhuma alteração nos arquivos de origem do Devicetree da plataforma SoC +(arquivos DTS) deve introduzir novos avisos de ``make dtbs_check W=1``. +Avisos em um novo DTS de placa, que sejam resultado de problemas em um +arquivo DTSI incluído, são considerados avisos existentes, não novos. +Para séries divididas entre árvores diferentes (vínculos de DT seguem pela +árvore do subsistema de drivers), os avisos no linux-next são decisivos. +Os mantenedores da plataforma possuem automação implementada que deve +apontar quaisquer novos avisos. + +Se um commit que introduz novos avisos for aceito de alguma forma, os +problemas resultantes deverão ser corrigidos em um tempo razoável +(por exemplo, dentro de um ciclo de lançamento) ou o commit será revertido. diff --git a/Documentation/translations/pt_BR/process/maintainer-soc.rst b/Documentation/translations/pt_BR/process/maintainer-soc.rst new file mode 100644 index 000000000000..5a3ae213ef67 --- /dev/null +++ b/Documentation/translations/pt_BR/process/maintainer-soc.rst @@ -0,0 +1,222 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +Subsistema SoC +============== + +Visão Geral +----------- + +O subsistema SoC é um local de agregação para códigos específicos de SoC +System on Chip). Os principais componentes do subsistema são: + +* Devicetrees (DTS) para ARM de 32 e 64 bits e RISC-V. +* Arquivos de placa (board files) ARM de 32 bits (arch/arm/mach*). +* Defconfigs ARM de 32 e 64 bits. +* Drivers específicos de SoC em diversas arquiteturas, em particular para ARM de +* 32 e 64 bits, RISC-V e Loongarch. + +Estes "drivers específicos de SoC" não incluem drivers de clock, GPIO, etc., que +possuem outros mantenedores de alto nível. O diretório ``drivers/soc/`` é +geralmente destinado a drivers internos do kernel que são usados por outros +drivers para fornecer funcionalidades específicas do SoC, como identificar uma +revisão do chip ou fazer a interface com domínios de energia. + +O subsistema SoC também serve como um local intermediário para alterações em +``drivers/bus``, ``drivers/firmware``, ``drivers/reset`` e ``drivers/memory``. +A adição de novas plataformas, ou a remoção de existentes, geralmente passa pela +árvore SoC como um branch dedicado cobrindo múltiplos subsistemas. + +A árvore principal do SoC está hospedada no git.kernel.org: + https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/ + +Mantenedores +------------ + +Claramente, esta é uma gama bastante ampla de tópicos, que nenhuma pessoa, ou +mesmo um pequeno grupo de pessoas, é capaz de manter. Em vez disso, o +subsistema SoC é composto por muitos submantenedores (mantenedores de +plataforma), cada um cuidando de plataformas individuais e subdiretórios de +drivers. + +Nesse sentido, "plataforma" geralmente se refere a uma série de SoCs de um +determinado fornecedor, por exemplo, a série de SoCs Tegra da Nvidia. Muitos +submantenedores operam em nível de fornecedor, sendo responsáveis por várias +linhas de produtos. Por diversos motivos, incluindo aquisições ou diferentes +unidades de negócios em uma empresa, as coisas variam significativamente aqui. +Os diversos submantenedores estão documentados no arquivo ``MAINTAINERS``. + +A maioria desses submantenedores possui suas próprias árvores onde preparam os +patches, enviando pull requests para a árvore SoC principal. Essas árvores são +geralmente, mas nem sempre, listadas em ``MAINTAINERS``. + +O que a árvore SoC não é, contudo, é um local para alterações de código +específicas da arquitetura. Cada arquitetura possui seus próprios mantenedores +que são responsáveis pelos detalhes arquiteturais, erratas de CPU e afins. + +Submetendo Patches para um Determinado SoC +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Todos os patches típicos relacionados à plataforma devem ser enviados por meio +dos submantenedores de SoC (mantenedores específicos da plataforma). Isso inclui +também alterações em defconfigs por plataforma ou compartilhadas. Note que +``scripts/get_maintainer.pl`` pode não fornecer os endereços corretos para a +defconfig compartilhada; portanto, ignore sua saída e crie manualmente a lista +de CC baseada no arquivo ``MAINTAINERS`` ou use algo como +``scripts/get_maintainer.pl -f drivers/soc/FOO/``. + +Submetendo Patches para os Mantenedores Principais de SoC +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Os mantenedores principais de SoC podem ser contatados via o alias +soc@kernel.org apenas nos seguintes casos: + +1. Não existem mantenedores específicos para a plataforma. + +2. Os mantenedores específicos da plataforma não respondem. + +3. Introdução de uma plataforma SoC completamente nova. Tal trabalho de novo SoC + deve ser enviado primeiro para as listas de discussão comuns, indicadas por + ``scripts/get_maintainer.pl``, para revisão da comunidade. Após uma revisão + positiva da comunidade, o trabalho deve ser enviado para soc@kernel.org em + um único conjunto de patches (*patchset*) contendo a nova entrada em + ``arch/foo/Kconfig``, arquivos DTS, entrada no arquivo ``MAINTAINERS`` e, + opcionalmente, drivers iniciais com seus respectivos bindings de Devicetree. + A entrada no arquivo ``MAINTAINERS`` deve listar os novos mantenedores + específicos da plataforma, que serão responsáveis por lidar com os patches + da plataforma de agora em diante. + +Note que o endereço soc@kernel.org geralmente não é o local para discutir os +patches; portanto, o trabalho enviado para este endereço já deve ser +considerado aceitável pela comunidade. + +Informações para (novos) Submantenedores +---------------------------------------- + +À medida que novas plataformas surgem, elas frequentemente trazem consigo novos +submantenedores, muitos dos quais trabalham para o fornecedor do silício e podem +não estar familiarizados com o processo. + +Estabilidade da ABI do Devicetree +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Talvez um dos pontos mais importantes a destacar é que os *dt-bindings* +documentam a ABI entre o devicetree e o kernel. Por favor, leia +``Documentation/devicetree/bindings/ABI.rst``. + +Se estiverem sendo feitas alterações em um DTS que sejam incompatíveis com +kernels antigos, o patch do DTS não deve ser aplicado até que o driver seja, ou +em um momento apropriado posterior. Mais importante ainda, quaisquer alterações +incompatíveis devem ser claramente apontadas na descrição do patch e no pull +request, juntamente com o impacto esperado nos usuários existentes, como +bootloaders ou outros sistemas operacionais. + +Dependências de Branch de Driver +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Um problema comum é a sincronização de alterações entre drivers de dispositivos +e arquivos de devicetree. Mesmo que uma alteração seja compatível em ambas as +direções, isso pode exigir a coordenação de como as mudanças são mescladas +através de diferentes árvores de mantenedores. + +Geralmente, o branch que inclui uma alteração de driver também incluirá a +mudança correspondente na descrição do binding do devicetree, para garantir que +sejam, de fato, compatíveis. Isso significa que o branch do devicetree pode +acabar causando avisos na etapa ``make dtbs_check``. Se uma alteração de +devicetree depender de adições ausentes em um arquivo de cabeçalho em +``include/dt-bindings/``, ela falhará na etapa ``make dtbs`` e não será mesclada. + +Existem várias maneiras de lidar com isso: + +* Evite definir macros personalizadas em ``include/dt-bindings/`` para constantes + de hardware que podem ser derivadas de um datasheet -- macros de binding em + arquivos de cabeçalho devem ser usadas apenas como último recurso, se não + houver uma maneira natural de definir um binding. + +* Use valores literais no arquivo devicetree em vez de macros, mesmo quando um + cabeçalho for necessário, e altere-os para a representação nomeada em um + lançamento posterior. + +* Adie as alterações do devicetree para um lançamento após o binding e o driver + já terem sido mesclados. + +* Altere os bindings em um branch imutável compartilhado que seja usado como + base tanto para a alteração do driver quanto para as alterações do devicetree. + +* Adicione definições duplicadas no arquivo devicetree protegidas por uma seção + ``#ifndef``, removendo-as em um lançamento posterior. + +Convenção de Nomenclatura de Devicetree +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +O esquema geral de nomenclatura para arquivos de devicetree é o seguinte. Os +aspectos de uma plataforma que são definidos no nível do SoC, como núcleos de +CPU, são contidos em um arquivo nomeado ``$soc.dtsi``, por exemplo, +``jh7100.dtsi``. Detalhes de integração, que variam de placa para placa, são +descritos em ``$soc-$board.dts``. Um exemplo disso é +``jh7100-beaglev-starlight.dts``. Frequentemente, muitas placas são variações +de um mesmo tema, e é comum haver arquivos intermediários, como +``jh7100-common.dtsi``, que ficam entre os arquivos ``$soc.dtsi`` e +``$soc-$board.dts``, contendo as descrições de hardware comum. + +Algumas plataformas também possuem *System on Modules* (SoM), contendo um SoC, +que são então integrados em diversas placas diferentes. Para essas plataformas, +``$soc-$som.dtsi`` e ``$soc-$som-$board.dts`` são típicos. + +Os diretórios geralmente são nomeados após o fornecedor do SoC no momento de sua +inclusão, o que leva a alguns nomes de diretórios históricos na árvore. + +Validando Arquivos de Devicetree +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +``make dtbs_check`` pode ser usado para validar se os arquivos de devicetree +estão em conformidade com os *dt-bindings* que descrevem a ABI. Por favor, leia +a seção "Running checks" de ``Documentation/devicetree/bindings/writing-schema.rst`` +para mais informações sobre a validação de devicetrees. + +Para novas plataformas, ou adições a plataformas existentes, ``make dtbs_check`` +não deve adicionar nenhum aviso (*warning*) novo. Para SoCs RISC-V e Samsung, é +exigido que ``make dtbs_check W=1`` não adicione nenhum novo aviso. +Se houver qualquer dúvida sobre uma alteração de devicetree, entre em contato +com os mantenedores de devicetree. + +Branches e Pull Requests +~~~~~~~~~~~~~~~~~~~~~~~~ + +Assim como a árvore SoC principal possui vários branches, espera-se que os +submantenedores façam o mesmo. Alterações de drivers, defconfig e devicetree +devem ser todas divididas em branches separados e aparecer em pull requests +distintos para os mantenedores de SoC. Cada branch deve ser utilizável por si só +e evitar regressões originadas de dependências em outros branches. + +Pequenos conjuntos de patches também podem ser enviados como e-mails separados +para soc@kernel.org, agrupados nas mesmas categorias. + +Se as alterações não se encaixarem nos padrões normais, pode haver branches de +nível superior adicionais, por exemplo, para uma reformulação em toda a árvore +(*treewide rework*) ou a adição de novas plataformas SoC, incluindo arquivos dts +e drivers. + +Branches com muitas alterações podem se beneficiar ao serem divididos em +branches de tópicos separados, mesmo que acabem sendo mesclados no mesmo branch +da árvore SoC. Um exemplo aqui seria um branch para correções de avisos de +devicetree, um para uma reformulação e um para placas recém-adicionadas. + +Outra forma comum de dividir as alterações é enviar um pull request antecipado +com a maioria das mudanças em algum momento entre rc1 e rc4, seguido por um ou +mais pull requests menores no final do ciclo, que podem adicionar alterações +tardias ou resolver problemas identificados durante os testes do primeiro +conjunto. + +Embora não haja um prazo limite para pull requests tardios, ajuda enviar apenas +branches pequenos à medida que o tempo se aproxima da janela de mesclagem +(*merge window*). + +Pull requests para correções de bugs (*bugfixes*) da versão atual podem ser +enviados a qualquer momento, mas, novamente, ter múltiplos branches menores é +melhor do que tentar combinar muitos patches em um único pull request. + +A linha de assunto de um pull request deve começar com "[GIT PULL]" e ser feita +usando uma tag assinada, em vez de um branch. Esta tag deve conter uma breve +descrição resumindo as alterações no pull request. Para mais detalhes sobre o +envio de pull requests, consulte ``Documentation/maintainer/pull-requests.rst``. diff --git a/Documentation/translations/sp_SP/process/4.Coding.rst b/Documentation/translations/sp_SP/process/4.Coding.rst index 7cc347c34354..6c3750ccdea2 100644 --- a/Documentation/translations/sp_SP/process/4.Coding.rst +++ b/Documentation/translations/sp_SP/process/4.Coding.rst @@ -336,7 +336,8 @@ https://sparse.wiki.kernel.org/index.php/Main_Page si su distribución no lo empaqueta); luego, puede ejecutarse en el código agregando "C=1" a su comando make. -La herramienta "Coccinelle" (http://coccinelle.lip6.fr/) puede encontrar +La herramienta "Coccinelle" (https://coccinelle.gitlabpages.inria.fr/website/) +puede encontrar una amplia variedad de posibles problemas de codificación; también puede proponer correcciones para esos problemas. Bastantes "parches semánticos" para el kernel se han empaquetado en el directorio scripts/coccinelle; diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rst b/Documentation/translations/sp_SP/process/submitting-patches.rst index ecb08b14c2c0..fc90c942f0e4 100644 --- a/Documentation/translations/sp_SP/process/submitting-patches.rst +++ b/Documentation/translations/sp_SP/process/submitting-patches.rst @@ -30,7 +30,7 @@ más sencilla. Algunos subsistemas y árboles de mantenimiento cuentan con información adicional sobre su flujo de trabajo y expectativas, consulte -:ref:`Documentation/process/maintainer-handbooks.rst <maintainer_handbooks_main>`. +Documentation/process/maintainer-handbooks.rst. Obtenga el código fuente actual -------------------------------- diff --git a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst index b35d24464be9..ff0ccbc59183 100644 --- a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst +++ b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst @@ -198,9 +198,9 @@ Esta es la lista parcial de llamadas: - yield_task(...) - Esta función es básicamente desencolar, seguido por encolar, a menos que - sysctl compat_yield esté activado; en ese caso, sitúa la entidad a gestionar - en la parte más hacia la derecha del árbol rojo-negro. + Esta función cede la CPU desplazando la posición de la tarea actualmente + en ejecución hacia atrás en la cola de ejecución, para que otras tareas + ejecutables sean planificadas primero. - check_preempt_curr(...) diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst index 286ed6b01f65..8bdc51b47b5e 100644 --- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst @@ -154,7 +154,7 @@ Smatch和Coccinelle的强项 Coccinelle可能是最容易写检查的。它在预处理器之前工作，所以用Coccinelle 检查宏中的错误更容易。Coccinelle还能为你创建补丁，这是其他工具无法做到的。 -例如，用Coccinelle你可以从 ``kmalloc_array(x, size, GFP_KERNEL)`` +例如，用Coccinelle你可以从 ``kmalloc(x * size, GFP_KERNEL)`` 到 ``kmalloc_array(x, size, GFP_KERNEL)`` 进行大规模转换，这真的很 有用。如果你只是创建一个Smatch警告，并试图把转换的工作推给维护者，他们会很 恼火。你将不得不为每个警告争论是否真的可以溢出。 diff --git a/Documentation/translations/zh_CN/devicetree/of_unittest.rst b/Documentation/translations/zh_CN/devicetree/of_unittest.rst index 5c1a8e0cfd16..cfd0b751ef27 100644 --- a/Documentation/translations/zh_CN/devicetree/of_unittest.rst +++ b/Documentation/translations/zh_CN/devicetree/of_unittest.rst @@ -32,27 +32,30 @@ OF Selftest被设计用来测试提供给设备驱动开发者的接口（includ 2. 测试数据 =========== -设备树源文件（drivers/of/unittest-data/testcases.dts）包含执行drivers/of/unittest.c -中自动化单元测试所需的测试数据。目前，以下设备树源包含文件（.dtsi）被包含在testcases.dt中:: +设备树源文件（drivers/of/unittest-data/testcases.dtso）包含执行drivers/of/unittest.c +中自动化单元测试所需的测试数据。目前，以下设备树源包含文件（.dtsi）被包含在testcases.dtso中:: drivers/of/unittest-data/tests-interrupts.dtsi drivers/of/unittest-data/tests-platform.dtsi drivers/of/unittest-data/tests-phandle.dtsi drivers/of/unittest-data/tests-match.dtsi + drivers/of/unittest-data/tests-address.dtsi + drivers/of/unittest-data/tests-overlay.dtsi + drivers/of/unittest-data/tests-lifecycle.dtsi 当内核在启用CONFIG_OF_UNITTEST的情况下被构建时，那么下面的make规则:: - $(obj)/%.dtb: $(src)/%.dts FORCE - $(call if_changed_dep, dtc) + $(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE + $(call if_changed_dep,dtc) -用于将DT源文件（testcases.dts）编译成二进制blob（testcases.dtb），也被称为扁平化的DT。 +用于将DT源文件（testcases.dtso）编译成二进制blob（testcases.dtbo），也被称为扁平化的DT。 -之后，使用以下规则将上述二进制blob包装成一个汇编文件（testcases.dtb.S）:: +之后，使用以下规则将上述二进制blob包装成一个汇编文件（testcases.dtbo.S）:: - $(obj)/%.dtb.S: $(obj)/%.dtb - $(call cmd, dt_S_dtb) + $(obj)/%.dtbo.S: $(obj)/%.dtbo FORCE + $(call if_changed,wrap_S_dtb) -汇编文件被编译成一个对象文件（testcases.dtb.o），并被链接到内核镜像中。 +汇编文件被编译成一个对象文件（testcases.dtbo.o），并被链接到内核镜像中。 2.1. 添加测试数据 diff --git a/Documentation/translations/zh_CN/infiniband/index.rst b/Documentation/translations/zh_CN/infiniband/index.rst index 5634cc48379f..aeeea0b49939 100644 --- a/Documentation/translations/zh_CN/infiniband/index.rst +++ b/Documentation/translations/zh_CN/infiniband/index.rst @@ -24,7 +24,6 @@ infiniband core_locking ipoib - opa_vnic sysfs tag_matching user_mad diff --git a/Documentation/translations/zh_CN/infiniband/opa_vnic.rst b/Documentation/translations/zh_CN/infiniband/opa_vnic.rst deleted file mode 100644 index 12b147fbf792..000000000000 --- a/Documentation/translations/zh_CN/infiniband/opa_vnic.rst +++ /dev/null @@ -1,156 +0,0 @@ -.. include:: ../disclaimer-zh_CN.rst - -:Original: Documentation/infiniband/opa_vnic.rst - -:翻译: - - 司延腾 Yanteng Si <siyanteng@loongson.cn> - -:校译: - - 王普宇 Puyu Wang <realpuyuwang@gmail.com> - 时奎亮 Alex Shi <alexs@kernel.org> - -.. _cn_infiniband_opa_vnic: - -============================================= -英特尔全路径（OPA）虚拟网络接口控制器（VNIC） -============================================= - -英特尔全路径（OPA）虚拟网络接口控制器（VNIC）功能通过封装HFI节点之间的以 -太网数据包，支持Omni-Path结构上的以太网功能。 - -体系结构 -======== - -Omni-Path封装的以太网数据包的交换模式涉及Omni-Path结构拓扑上覆盖的一个或 -多个虚拟以太网交换机。Omni-Path结构上的HFI节点的一个子集被允许在特定的虚 -拟以太网交换机上交换封装的以太网数据包。虚拟以太网交换机是通过配置结构上的 -HFI节点实现的逻辑抽象，用于生成和处理报头。在最简单的配置中，整个结构的所有 -HFI节点通过一个虚拟以太网交换机交换封装的以太网数据包。一个虚拟以太网交换机， -实际上是一个独立的以太网网络。该配置由以太网管理器（EM）执行，它是可信的结 -构管理器（FM）应用程序的一部分。HFI节点可以有多个VNIC，每个连接到不同的虚 -拟以太网交换机。下图介绍了两个虚拟以太网交换机与两个HFI节点的情况:: - - +-------------------+ - | 子网/ | - | 以太网 | - | 管理 | - +-------------------+ - / / - / / - / / - / / - +-----------------------------+ +------------------------------+ - | 虚拟以太网切换 | | 虚拟以太网切换 | - | +---------+ +---------+ | | +---------+ +---------+ | - | | VPORT | | VPORT | | | | VPORT | | VPORT | | - +--+---------+----+---------+-+ +-+---------+----+---------+---+ - | \ / | - | \ / | - | \/ | - | / \ | - | / \ | - +-----------+------------+ +-----------+------------+ - | VNIC | VNIC | | VNIC | VNIC | - +-----------+------------+ +-----------+------------+ - | HFI | | HFI | - +------------------------+ +------------------------+ - - -Omni-Path封装的以太网数据包格式如下所述。 - -==================== ================================ -位 域 -==================== ================================ -Quad Word 0: -0-19 SLID (低20位) -20-30 长度 (以四字为单位) -31 BECN 位 -32-51 DLID (低20位) -52-56 SC (服务级别) -57-59 RC (路由控制) -60 FECN 位 -61-62 L2 (=10, 16B 格式) -63 LT (=1, 链路传输头 Flit) - -Quad Word 1: -0-7 L4 type (=0x78 ETHERNET) -8-11 SLID[23:20] -12-15 DLID[23:20] -16-31 PKEY -32-47 熵 -48-63 保留 - -Quad Word 2: -0-15 保留 -16-31 L4 头 -32-63 以太网数据包 - -Quad Words 3 to N-1: -0-63 以太网数据包 (pad拓展) - -Quad Word N (last): -0-23 以太网数据包 (pad拓展) -24-55 ICRC -56-61 尾 -62-63 LT (=01, 链路传输尾 Flit) -==================== ================================ - -以太网数据包在传输端被填充，以确保VNIC OPA数据包是四字对齐的。“尾”字段 -包含填充的字节数。在接收端，“尾”字段被读取，在将数据包向上传递到网络堆 -栈之前，填充物被移除（与ICRC、尾和OPA头一起）。 - -L4头字段包含VNIC端口所属的虚拟以太网交换机ID。在接收端，该字段用于将收 -到的VNIC数据包去多路复用到不同的VNIC端口。 - -驱动设计 -======== - -英特尔OPA VNIC的软件设计如下图所示。OPA VNIC功能有一个依赖于硬件的部分 -和一个独立于硬件的部分。 - -对IB设备分配和释放RDMA netdev设备的支持已经被加入。RDMA netdev支持与 -网络堆栈的对接，从而创建标准的网络接口。OPA_VNIC是一个RDMA netdev设备 -类型。 - -依赖于HW的VNIC功能是HFI1驱动的一部分。它实现了分配和释放OPA_VNIC RDMA -netdev的动作。它涉及VNIC功能的HW资源分配/管理。它与网络堆栈接口并实现所 -需的net_device_ops功能。它在传输路径中期待Omni-Path封装的以太网数据包， -并提供对它们的HW访问。在将数据包向上传递到网络堆栈之前，它把Omni-Path头 -从接收的数据包中剥离。它还实现了RDMA netdev控制操作。 - -OPA VNIC模块实现了独立于硬件的VNIC功能。它由两部分组成。VNIC以太网管理 -代理（VEMA）作为一个IB客户端向IB核心注册，并与IB MAD栈接口。它与以太网 -管理器（EM）和VNIC netdev交换管理信息。VNIC netdev部分分配和释放OPA_VNIC -RDMA netdev设备。它在需要时覆盖由依赖HW的VNIC驱动设置的net_device_ops函数， -以适应任何控制操作。它还处理以太网数据包的封装，在传输路径中使用Omni-Path头。 -对于每个VNIC接口，封装所需的信息是由EM通过VEMA MAD接口配置的。它还通过调用 -RDMA netdev控制操作将任何控制信息传递给依赖于HW的驱动程序:: - - +-------------------+ +----------------------+ - | | | Linux | - | IB MAD | | 网络 | - | | | 栈 | - +-------------------+ +----------------------+ - | | | - | | | - +----------------------------+ | - | | | - | OPA VNIC 模块 | | - | (OPA VNIC RDMA Netdev | | - | & EMA 函数) | | - | | | - +----------------------------+ | - | | - | | - +------------------+ | - | IB 核心 | | - +------------------+ | - | | - | | - +--------------------------------------------+ - | | - | HFI1 驱动和 VNIC 支持 | - | | - +--------------------------------------------+ diff --git a/Documentation/translations/zh_CN/process/2.Process.rst b/Documentation/translations/zh_CN/process/2.Process.rst index 31b0e2c994f6..ca00672c313e 100644 --- a/Documentation/translations/zh_CN/process/2.Process.rst +++ b/Documentation/translations/zh_CN/process/2.Process.rst @@ -23,21 +23,18 @@ 总览 ---- -内核开发人员使用一个松散的基于时间的发布过程，每两到三个月发布一次新的主要 -内核版本。最近的发布历史记录如下： - - ====== ================= - 5.0 2019年3月3日 - 5.1 2019年5月5日 - 5.2 2019年7月7日 - 5.3 2019年9月15日 - 5.4 2019年11月24日 - 5.5 2020年1月6日 - ====== ================= - -每个5.x版本都是一个主要的内核版本，具有新特性、内部API更改等等。一个典型的5.x -版本包含大约13000个变更集，变更了几十万行代码。因此，5.x是Linux内核开发的前 -沿；内核使用滚动开发模型，不断集成重大变化。 +内核开发使用一个松散的、基于时间的滚动发布（rolling release）开发模型。 +一个新的主内核发行版本（作为示例，我们将其称为 9.x） [1]_ 大约每两到三个月 +发布一次，它带来了新特性、内部 API 的更改等。一个典型的版本包含大约 13,000 +个变更集（changesets），涉及几十万行代码的修改。最近的发行版本及其日期可以 +在这里找到 +`维基百科 <https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_ + + +.. [1] 严格来说，Linux 内核并不采用语义化版本号方案，而是将 9.x 这一组数字 + 作为一个整体来标识主发行版本号。对于每一个版本，x 都会递增，但只有 + 当 x 被认为足够大时，9 才会递增（例如：Linux 5.0 是紧随 Linux 4.20 + 之后发布的）。 对于每个版本的补丁合并，遵循一个相对简单的规则。在每个开发周期的开头，“合并 窗口”被打开。这时，被认为足够稳定（并且被开发社区接受）的代码被合并到主线内 @@ -48,8 +45,8 @@ 提前收集、测试和分级的。稍后将详细描述该过程的工作方式。） 合并窗口持续大约两周。在这段时间结束时，Linus Torvalds将声明窗口已关闭，并 -释放第一个“rc”内核。例如，对于目标为5.6的内核，在合并窗口结束时发生的释放 -将被称为5.6-rc1。-rc1 版本是一个信号，表示合并新特性的时间已经过去，稳定下一 +释放第一个“rc”内核。例如，对于目标为9.x的内核，在合并窗口结束时发生的释放 +将被称为9.x-rc1。-rc1 版本是一个信号，表示合并新特性的时间已经过去，稳定下一 个内核的时间已经到来。 在接下来的6到10周内，只有修复问题的补丁才应该提交给主线。有时会允许更大的 @@ -84,11 +81,14 @@ 开发人员的目标是在稳定发布之前修复所有已知的回归。在现实世界中，这种完美是 很难实现的；在这种规模的项目中，变数太多了。需要说明的是，延迟最终版本只会 使问题变得更糟；等待下一个合并窗口的更改将变多，导致下次出现更多的回归错误。 -因此，大多数5.x内核都有一些已知的回归错误，不过，希望没有一个是严重的。 +因此，大多数内核发布时都会带有一部分已知的回归问题，不过希望它们都不是严重 +的问题。 一旦一个稳定的版本发布，它的持续维护工作就被移交给“稳定团队”，目前由 -Greg Kroah-Hartman领导。稳定团队将使用5.x.y编号方案不定期地发布稳定版本的 -更新。要合入更新版本，补丁必须（1）修复一个重要的缺陷，且（2）已经合并到 +Greg Kroah-Hartman领导。稳定团队将使用9.x.y编号方案不定期地发布稳定版本的 +更新。 + +要合入更新版本，补丁必须（1）修复一个重要的缺陷，且（2）已经合并到 下一个开发版本主线中。内核通常会在其初始版本后的一个以上的开发周期内收到 稳定版更新。例如，5.2内核的历史如下（2019年）： @@ -105,17 +105,10 @@ Greg Kroah-Hartman领导。稳定团队将使用5.x.y编号方案不定期地发 5.2.21是5.2版本的最终稳定更新。 -有些内核被指定为“长期”内核；它们将得到更长时间的支持。在本文中，当前的长期 -内核及其维护者是： +有些内核被指定为“长期”内核；它们将得到更长时间的支持。请参考以下链接 +获取当前长期支持内核版本及其维护者的列表： - ====== ================================ ================ - 3.16 Ben Hutchings （长期稳定内核） - 4.4 Greg Kroah-Hartman & Sasha Levin （长期稳定内核） - 4.9 Greg Kroah-Hartman & Sasha Levin - 4.14 Greg Kroah-Hartman & Sasha Levin - 4.19 Greg Kroah-Hartman & Sasha Levin - 5.4 Greg Kroah-Hartman & Sasha Levin - ====== ================================ ================ + https://www.kernel.org/category/releases.html 长期支持内核的选择纯粹是维护人员是否有需求和时间来维护该版本的问题。 目前还没有为即将发布的任何特定版本提供长期支持的已知计划。 @@ -320,7 +313,8 @@ Quilt 是一个补丁管理系统，而不是源代码管理系统。它不会 没有完成家庭作业的人感到不耐烦。 - 避免顶部回复（把你的答案放在你要回复的引文上面的做法）。这会让你的回答更难 - 理解，印象也很差。 + 理解，印象也很差，详细请查看 + :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>` - 在正确的邮件列表发问。linux-kernel 可能是通用的讨论场所，但它不是寻找所有 子系统开发人员的最佳场所。 diff --git a/Documentation/translations/zh_CN/process/4.Coding.rst b/Documentation/translations/zh_CN/process/4.Coding.rst index 4cc35d410dbc..a00ad5d6b81e 100644 --- a/Documentation/translations/zh_CN/process/4.Coding.rst +++ b/Documentation/translations/zh_CN/process/4.Coding.rst @@ -216,7 +216,7 @@ Documentation/fault-injection/fault-injection.rst。 可以在 https://sparse.wiki.kernel.org/index.php/Main_page 找到）, 然后可以通过在make命令中添加“C=1”在代码上运行它。 -“Coccinelle”工具 :ref:`http://coccinelle.lip6.fr/ <devtools_coccinelle>` +“Coccinelle”工具 :ref:`https://coccinelle.gitlabpages.inria.fr/website/ <devtools_coccinelle>` 能够发现各种潜在的编码问题；它还可以为这些问题提出修复方案。在 scripts/coccinelle目录下已经打包了相当多的内核“语义补丁”；运行 “make coccicheck”将运行这些语义补丁并报告发现的任何问题。有关详细信息，请参阅 diff --git a/Documentation/translations/zh_CN/rust/arch-support.rst b/Documentation/translations/zh_CN/rust/arch-support.rst index abd708d48f82..f5ae44588a57 100644 --- a/Documentation/translations/zh_CN/rust/arch-support.rst +++ b/Documentation/translations/zh_CN/rust/arch-support.rst @@ -19,9 +19,10 @@ ============= ================ ============================================== 架构 支持水平 限制因素 ============= ================ ============================================== -``arm64`` Maintained 只有小端序 +``arm`` Maintained 仅 ARMv7 小端序。 +``arm64`` Maintained 仅小端序。 ``loongarch`` Maintained \- -``riscv`` Maintained 只有 ``riscv64`` -``um`` Maintained 只有 ``x86_64`` -``x86`` Maintained 只有 ``x86_64`` +``riscv`` Maintained 仅 ``riscv64``，且仅限 LLVM/Clang。 +``um`` Maintained \- +``x86`` Maintained 仅 ``x86_64``。 ============= ================ ============================================== diff --git a/Documentation/translations/zh_CN/rust/coding-guidelines.rst b/Documentation/translations/zh_CN/rust/coding-guidelines.rst index 419143b938ed..54b902322dbc 100644 --- a/Documentation/translations/zh_CN/rust/coding-guidelines.rst +++ b/Documentation/translations/zh_CN/rust/coding-guidelines.rst @@ -37,6 +37,73 @@ 像内核其他部分的 ``clang-format`` 一样， ``rustfmt`` 在单个文件上工作，并且不需要 内核配置。有时，它甚至可以与破碎的代码一起工作。 +导入 +~~~~ + +``rustfmt`` 默认会以一种在合并和变基时容易产生冲突的方式格式化导入，因为在某些情况下 +它会将多个条目合并到同一行。例如： + +.. code-block:: rust + + // Do not use this style. + use crate::{ + example1, + example2::{example3, example4, example5}, + example6, example7, + example8::example9, + }; + +相反，内核使用如下所示的垂直布局： + +.. code-block:: rust + + use crate::{ + example1, + example2::{ + example3, + example4, + example5, // + }, + example6, + example7, + example8::example9, // + }; + +也就是说，每个条目占一行，只要列表中有多个条目就使用花括号。 + +末尾的空注释可以保留这种格式。不仅如此， ``rustfmt`` 在添加空注释后实际上会将导入重 +新格式化为垂直布局。也就是说，可以通过对如下输入运行 ``rustfmt`` 来轻松地将原始示例 +重新格式化为预期的风格： + +.. code-block:: rust + + // Do not use this style. + use crate::{ + example1, + example2::{example3, example4, example5, // + }, + example6, example7, + example8::example9, // + }; + +末尾的空注释适用于嵌套导入（如上所示）以及单条目导入——这有助于最小化补丁系列中的差 +异： + +.. code-block:: rust + + use crate::{ + example1, // + }; + +末尾的空注释可以放在花括号内的任何一行中，但建议放在最后一个条目上，因为这让人联想到其 +他格式化工具中的末尾逗号。有时在补丁系列中由于列表的变更，避免多次移动注释可能更简单。 + +在某些情况下可能需要例外处理，即以上都不是硬性规则。也有一些代码尚未迁移到这种风格，但 +请不要引入其他风格的代码。 + +最终目标是让 ``rustfmt`` 在稳定版本中自动支持这种格式化风格（或类似的风格），而无需 +末尾的空注释。因此，在某个时候，目标是移除这些注释。 + 注释 ---- @@ -77,6 +144,16 @@ // ... } +这适用于公共和私有项目。这增加了与公共项目的一致性，允许在更改可见性时减少涉及的更改， +并允许我们将来也为私有项目生成文档。换句话说，如果为私有项目编写了文档，那么仍然应该使 +用 ``///`` 。例如： + +.. code-block:: rust + + /// My private function. + // TODO: ... + fn f() {} + 一种特殊的注释是 ``// SAFETY:`` 注释。这些注释必须出现在每个 ``unsafe`` 块之前，它们 解释了为什么该块内的代码是正确/健全的，即为什么它在任何情况下都不会触发未定义行为，例如: @@ -131,27 +208,27 @@ https://commonmark.org/help/ 这个例子展示了一些 ``rustdoc`` 的特性和内核中遵循的一些惯例: - - 第一段必须是一个简单的句子，简要地描述被记录的项目的作用。进一步的解释必须放在额 - 外的段落中。 +- 第一段必须是一个简单的句子，简要地描述被记录的项目的作用。进一步的解释必须放在额 + 外的段落中。 - - 不安全的函数必须在 ``# Safety`` 部分记录其安全前提条件。 +- 不安全的函数必须在 ``# Safety`` 部分记录其安全前提条件。 - - 虽然这里没有显示，但如果一个函数可能会恐慌，那么必须在 ``# Panics`` 部分描述发 - 生这种情况的条件。 +- 虽然这里没有显示，但如果一个函数可能会恐慌，那么必须在 ``# Panics`` 部分描述发 + 生这种情况的条件。 - 请注意，恐慌应该是非常少见的，只有在有充分理由的情况下才会使用。几乎在所有的情况下， - 都应该使用一个可失败的方法，通常是返回一个 ``Result``。 + 请注意，恐慌应该是非常少见的，只有在有充分理由的情况下才会使用。几乎在所有的情况下， + 都应该使用一个可失败的方法，通常是返回一个 ``Result``。 - - 如果提供使用实例对读者有帮助的话，必须写在一个叫做``# Examples``的部分。 +- 如果提供使用实例对读者有帮助的话，必须写在一个叫做``# Examples``的部分。 - - Rust项目（函数、类型、常量……）必须有适当的链接(``rustdoc`` 会自动创建一个 - 链接)。 +- Rust项目（函数、类型、常量……）必须有适当的链接(``rustdoc`` 会自动创建一个 + 链接)。 - - 任何 ``unsafe`` 的代码块都必须在前面加上一个 ``// SAFETY:`` 的注释，描述里面 - 的代码为什么是正确的。 +- 任何 ``unsafe`` 的代码块都必须在前面加上一个 ``// SAFETY:`` 的注释，描述里面 + 的代码为什么是正确的。 - 虽然有时原因可能看起来微不足道，但写这些注释不仅是记录已经考虑到的问题的好方法， - 最重要的是，它提供了一种知道没有额外隐含约束的方法。 + 虽然有时原因可能看起来微不足道，但写这些注释不仅是记录已经考虑到的问题的好方法， + 最重要的是，它提供了一种知道没有额外隐含约束的方法。 要了解更多关于如何编写Rust和拓展功能的文档，请看看 ``rustdoc`` 这本书，网址是: @@ -170,6 +247,22 @@ https://commonmark.org/help/ /// [`struct mutex`]: srctree/include/linux/mutex.h +C FFI 类型 +---------- + +Rust 内核代码使用类型别名（如 ``c_int``）来引用 C 类型（如 ``int``），这些别名可 +以直接从 ``kernel`` 预导入（prelude）中获取。请不要使用 ``core::ffi`` 中的别 +名——它们可能无法映射到正确的类型。 + +这些别名通常应该直接通过其标识符引用，即作为单段路径。例如： + +.. code-block:: rust + + fn f(p: *const c_char) -> c_int { + // ... + } + + 命名 ---- @@ -202,3 +295,144 @@ Rust内核代码遵循通常的Rust命名空间: 也就是说， ``GPIO_LINE_DIRECTION_IN`` 的等价物将被称为 ``gpio::LineDirection::In`` 。 特别是，它不应该被命名为 ``gpio::gpio_line_direction::GPIO_LINE_DIRECTION_IN`` 。 + + +代码检查提示（Lints） +--------------------- + +在 Rust 中，可以在局部 ``allow`` 特定的警告（诊断信息、代码检查提示（lint））， +使编译器忽略给定函数、模块、代码块等中给定警告的实例。 + +这类似于 C 中的 ``#pragma GCC diagnostic push`` + ``ignored`` + ``pop`` +[#]_： + +.. code-block:: c + + #pragma GCC diagnostic push + #pragma GCC diagnostic ignored "-Wunused-function" + static void f(void) {} + #pragma GCC diagnostic pop + +.. [#] 在这个特定情况下，可以使用内核的 ``__{always,maybe}_unused`` 属性 + （C23 的 ``[[maybe_unused]]``）；然而，此示例旨在反映下文讨论的 Rust 中 + 的等效代码检查提示。 + +但要简洁得多： + +.. code-block:: rust + + #[allow(dead_code)] + fn f() {} + +凭借这一点，可以更方便地默认启用更多诊断（即在 ``W=`` 级别之外）。特别是那些可能有 +一些误报但在其他方面非常有用的诊断，保持启用可以捕获潜在的错误。 + +在此基础上，Rust 提供了 ``expect`` 属性，更进一步。如果警告没有产生，它会让编译器 +发出警告。例如，以下代码将确保当 ``f()`` 在某处被调用时，我们必须移除该属性： + +.. code-block:: rust + + #[expect(dead_code)] + fn f() {} + +如果我们不这样做，编译器会发出警告:: + + warning: this lint expectation is unfulfilled + --> x.rs:3:10 + | + 3 | #[expect(dead_code)] + | ^^^^^^^^^ + | + = note: `#[warn(unfulfilled_lint_expectations)]` on by default + +这意味着 ``expect`` 不会在不需要时被遗忘，这可能发生在以下几种情况中： + +- 开发过程中添加的临时属性。 + +- 编译器、Clippy 或自定义工具中代码检查提示的改进可能消除误报。 + +- 当代码检查提示不再需要时，因为预期它会在某个时候被移除，例如上面的 + ``dead_code`` 示例。 + +这也增加了剩余 ``allow`` 的可见性，并减少了误用的可能性。 + +因此，优先使用 ``expect`` 而不是 ``allow``，除非： + +- 条件编译在某些情况下触发警告，在其他情况下不触发。 + + 如果与总的相比，只有少数情况触发（或不触发）警告，那么可以考虑使用条件 + ``expect``（即 ``cfg_attr(..., expect(...))``）。否则，使用 ``allow`` 可 + 能更简单。 + +- 在宏内部，不同的调用可能会创建在某些情况下触发警告而在其他情况下不触发的展开代码。 + +- 当代码可能在某些架构上触发警告但在其他架构上不触发时，例如到 C FFI 类型的 ``as`` + 转换。 + +作为一个更详细的示例，考虑以下程序： + +.. code-block:: rust + + fn g() {} + + fn main() { + #[cfg(CONFIG_X)] + g(); + } + +这里，如果 ``CONFIG_X`` 未设置，函数 ``g()`` 是死代码。我们可以在这里使用 +``expect`` 吗？ + +.. code-block:: rust + + #[expect(dead_code)] + fn g() {} + + fn main() { + #[cfg(CONFIG_X)] + g(); + } + +如果 ``CONFIG_X`` 被设置，这将产生代码检查提示，因为在该配置中它不是死代码。因 +此，在这种情况下，我们不能直接使用 ``expect``。 + +一个简单的可能性是使用 ``allow``： + +.. code-block:: rust + + #[allow(dead_code)] + fn g() {} + + fn main() { + #[cfg(CONFIG_X)] + g(); + } + +另一种方法是使用条件 ``expect``： + +.. code-block:: rust + + #[cfg_attr(not(CONFIG_X), expect(dead_code))] + fn g() {} + + fn main() { + #[cfg(CONFIG_X)] + g(); + } + +这将确保如果有人在某处引入了对 ``g()`` 的另一个调用（例如无条件的），那么将会被发现 +它不再是死代码。然而， ``cfg_attr`` 比简单的 ``allow`` 更复杂。 + +因此，当涉及多个配置或者代码检查提示可能由于非局部更改（如 ``dead_code``）而触发 +时，使用条件 ``expect`` 可能不值得。 + +有关 Rust 中诊断的更多信息，请参阅： + + https://doc.rust-lang.org/stable/reference/attributes/diagnostics.html + +错误处理 +-------- + +有关 Rust for Linux 特定错误处理的背景和指南，请参阅： + + https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust diff --git a/Documentation/translations/zh_CN/rust/index.rst b/Documentation/translations/zh_CN/rust/index.rst index 5347d4729588..138e057bee44 100644 --- a/Documentation/translations/zh_CN/rust/index.rst +++ b/Documentation/translations/zh_CN/rust/index.rst @@ -12,16 +12,6 @@ Rust 与内核中的Rust有关的文档。若要开始在内核中使用Rust，请阅读 quick-start.rst 指南。 -Rust 实验 ---------- -Rust 支持在 v6.1 版本中合并到主线，以帮助确定 Rust 作为一种语言是否适合内核， -即是否值得进行权衡。 - -目前，Rust 支持主要面向对 Rust 支持感兴趣的内核开发人员和维护者， -以便他们可以开始处理抽象和驱动程序，并帮助开发基础设施和工具。 - -如果您是终端用户，请注意，目前没有适合或旨在生产使用的内置驱动程序或模块， -并且 Rust 支持仍处于开发/实验阶段，尤其是对于特定内核配置。 代码文档 -------- @@ -50,10 +40,3 @@ Rust 支持在 v6.1 版本中合并到主线，以帮助确定 Rust 作为一种 testing 你还可以在 :doc:`../../../process/kernel-docs` 中找到 Rust 的学习材料。 - -.. only:: subproject and html - - Indices - ======= - - * :ref:`genindex` diff --git a/Documentation/translations/zh_CN/rust/quick-start.rst b/Documentation/translations/zh_CN/rust/quick-start.rst index 8616556ae4d7..5f0ece6411f5 100644 --- a/Documentation/translations/zh_CN/rust/quick-start.rst +++ b/Documentation/translations/zh_CN/rust/quick-start.rst @@ -13,16 +13,138 @@ 本文介绍了如何开始使用Rust进行内核开发。 +安装内核开发所需的 Rust 工具链有几种方式。一种简单的方式是使用 Linux 发行版的软件包 +（如果它们合适的话）——下面的第一节解释了这种方法。这种方法的一个优势是，通常发行版会 +匹配 Rust 和 Clang 所使用的 LLVM。 + +另一种方式是使用 `kernel.org <https://kernel.org/pub/tools/llvm/rust/>`_ 上提 +供的预构建稳定版本的 LLVM+Rust。这些与 :ref:`获取 LLVM <zh_cn_getting_llvm>` 中的精 +简快速 LLVM 工具链相同，并添加了 Rust for Linux 支持的 Rust 版本。提供了两套工具 +链："最新 LLVM" 和 "匹配 LLVM"（请参阅链接了解更多信息）。 + +或者，接下来的两个 "依赖" 章节将解释每个组件以及如何通过 ``rustup``、Rust 的独立 +安装程序或从源码构建来安装它们。 + +本文档的其余部分解释了有关如何入门的其他方面。 + + +发行版 +------ + +Arch Linux +********** + +Arch Linux 提供较新的 Rust 版本，因此通常开箱即用，例如:: + + pacman -S rust rust-src rust-bindgen + + +Debian +****** + +Debian 13（Trixie）以及 Testing 和 Debian Unstable（Sid）提供较新的 Rust 版 +本，因此通常开箱即用，例如:: + + apt install rustc rust-src bindgen rustfmt rust-clippy + + +Fedora Linux +************ + +Fedora Linux 提供较新的 Rust 版本，因此通常开箱即用，例如:: + + dnf install rust rust-src bindgen-cli rustfmt clippy + + +Gentoo Linux +************ + +Gentoo Linux（尤其是 testing 分支）提供较新的 Rust 版本，因此通常开箱即用， +例如:: + + USE='rust-src rustfmt clippy' emerge dev-lang/rust dev-util/bindgen + +可能需要设置 ``LIBCLANG_PATH``。 + + +Nix +*** + +Nix（unstable 频道）提供较新的 Rust 版本，因此通常开箱即用，例如:: + + { pkgs ? import <nixpkgs> {} }: + pkgs.mkShell { + nativeBuildInputs = with pkgs; [ rustc rust-bindgen rustfmt clippy ]; + RUST_LIB_SRC = "${pkgs.rust.packages.stable.rustPlatform.rustLibSrc}"; + } + + +openSUSE +******** + +openSUSE Slowroll 和 openSUSE Tumbleweed 提供较新的 Rust 版本，因此通常开箱 +即用，例如:: + + zypper install rust rust1.79-src rust-bindgen clang + + +Ubuntu +****** + +25.04 +~~~~~ + +最新的 Ubuntu 版本提供较新的 Rust 版本，因此通常开箱即用，例如:: + + apt install rustc rust-src bindgen rustfmt rust-clippy + +此外，需要设置 ``RUST_LIB_SRC``，例如:: + + RUST_LIB_SRC=/usr/src/rustc-$(rustc --version | cut -d' ' -f2)/library + +为方便起见，可以将 ``RUST_LIB_SRC`` 导出到全局环境中。 + + +24.04 LTS 及更早版本 +~~~~~~~~~~~~~~~~~~~~ + +虽然 Ubuntu 24.04 LTS 及更早版本仍然提供较新的 Rust 版本，但它们需要一些额外的配 +置，使用带版本号的软件包，例如:: + + apt install rustc-1.80 rust-1.80-src bindgen-0.65 rustfmt-1.80 \ + rust-1.80-clippy + ln -s /usr/lib/rust-1.80/bin/rustfmt /usr/bin/rustfmt-1.80 + ln -s /usr/lib/rust-1.80/bin/clippy-driver /usr/bin/clippy-driver-1.80 + +这些软件包都不会将其工具设置为默认值；因此应该显式指定它们，例如:: + + make LLVM=1 RUSTC=rustc-1.80 RUSTDOC=rustdoc-1.80 RUSTFMT=rustfmt-1.80 \ + CLIPPY_DRIVER=clippy-driver-1.80 BINDGEN=bindgen-0.65 + +或者，修改 ``PATH`` 变量将 Rust 1.80 的二进制文件放在前面，并将 ``bindgen`` 设 +置为默认值，例如:: + + PATH=/usr/lib/rust-1.80/bin:$PATH + update-alternatives --install /usr/bin/bindgen bindgen \ + /usr/bin/bindgen-0.65 100 + update-alternatives --set bindgen /usr/bin/bindgen-0.65 + +使用带版本号的软件包时需要设置 ``RUST_LIB_SRC``，例如:: + + RUST_LIB_SRC=/usr/src/rustc-$(rustc-1.80 --version | cut -d' ' -f2)/library + +为方便起见，可以将 ``RUST_LIB_SRC`` 导出到全局环境中。 + +此外， ``bindgen-0.65`` 在较新的版本（24.04 LTS 和 24.10）中可用，但在更早的版 +本（20.04 LTS 和 22.04 LTS）中可能不可用，因此可能需要手动构建 ``bindgen`` +（请参见下文）。 + 构建依赖 -------- 本节描述了如何获取构建所需的工具。 -其中一些依赖也许可以从Linux发行版中获得，包名可能是 ``rustc`` , ``rust-src`` , -``rust-bindgen`` 等。然而，在写这篇文章的时候，它们很可能还不够新，除非发行版跟踪最 -新的版本。 - 为了方便检查是否满足要求，可以使用以下目标:: make LLVM=1 rustavailable @@ -34,15 +156,14 @@ rustc ***** -需要一个特定版本的Rust编译器。较新的版本可能会也可能不会工作，因为就目前而言，内核依赖 -于一些不稳定的Rust特性。 +需要一个较新版本的Rust编译器。 如果使用的是 ``rustup`` ，请进入内核编译目录（或者用 ``--path=<build-dir>`` 参数 -来 ``设置`` sub-command)并运行:: +来 ``设置`` sub-command)，例如运行:: - rustup override set $(scripts/min-tool-version.sh rustc) + rustup override set stable -+这将配置你的工作目录使用正确版本的 ``rustc``，而不影响你的默认工具链。 +这将配置你的工作目录使用给定版本的 ``rustc``，而不影响你的默认工具链。 请注意覆盖应用当前的工作目录（和它的子目录）。 @@ -54,7 +175,7 @@ rustc Rust标准库源代码 **************** -Rust标准库的源代码是必需的，因为构建系统会交叉编译 ``core`` 和 ``alloc`` 。 +Rust标准库的源代码是必需的，因为构建系统会交叉编译 ``core`` 。 如果正在使用 ``rustup`` ，请运行:: @@ -64,10 +185,10 @@ Rust标准库的源代码是必需的，因为构建系统会交叉编译 ``core 否则，如果使用独立的安装程序，可以将Rust源码树下载到安装工具链的文件夹中:: - curl -L "https://static.rust-lang.org/dist/rust-src-$(scripts/min-tool-version.sh rustc).tar.gz" | - tar -xzf - -C "$(rustc --print sysroot)/lib" \ - "rust-src-$(scripts/min-tool-version.sh rustc)/rust-src/lib/" \ - --strip-components=3 + curl -L "https://static.rust-lang.org/dist/rust-src-$(rustc --version | cut -d' ' -f2).tar.gz" | + tar -xzf - -C "$(rustc --print sysroot)/lib" \ + "rust-src-$(rustc --version | cut -d' ' -f2)/rust-src/lib/" \ + --strip-components=3 在这种情况下，以后升级Rust编译器版本需要手动更新这个源代码树（这可以通过移除 ``$(rustc --print sysroot)/lib/rustlib/src/rust`` ，然后重新执行上 @@ -97,24 +218,21 @@ Linux发行版中可能会有合适的包，所以最好先检查一下。 bindgen ******* -内核的C端绑定是在构建时使用 ``bindgen`` 工具生成的。这需要特定的版本。 - -通过以下方式安装它（注意，这将从源码下载并构建该工具）:: - - cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen-cli +内核的C端绑定是在构建时使用 ``bindgen`` 工具生成的。 -``bindgen`` 需要找到合适的 ``libclang`` 才能工作。如果没有找到（或者找到的 -``libclang`` 与应该使用的 ``libclang`` 不同），则可以使用 ``clang-sys`` -理解的环境变量（Rust绑定创建的 ``bindgen`` 用来访问 ``libclang``）: +例如，通过以下方式安装它（注意，这将从源码下载并构建该工具）:: + cargo install --locked bindgen-cli -* ``LLVM_CONFIG_PATH`` 可以指向一个 ``llvm-config`` 可执行文件。 +``bindgen`` 使用 ``clang-sys`` crate 来查找合适的 ``libclang`` （可以静态链 +接、动态链接或在运行时加载）。默认情况下，上面的 ``cargo`` 命令会生成一个在运行时 +加载 ``libclang`` 的 ``bindgen`` 二进制文件。如果没有找到（或者应该使用与找到的 +不同的 ``libclang``），可以调整该过程，例如使用 ``LIBCLANG_PATH`` 环境变量。详 +情请参阅 ``clang-sys`` 的文档： -* 或者 ``LIBCLANG_PATH`` 可以指向 ``libclang`` 共享库或包含它的目录。 + https://github.com/KyleMayes/clang-sys#linking -* 或者 ``CLANG_PATH`` 可以指向 ``clang`` 可执行文件。 - -详情请参阅 ``clang-sys`` 的文档: + https://github.com/KyleMayes/clang-sys#environment-variables 开发依赖 @@ -151,18 +269,6 @@ clippy 独立的安装程序也带有 ``clippy`` 。 -cargo -***** - -``cargo`` 是Rust的本地构建系统。目前需要它来运行测试，因为它被用来构建一个自定义的标准 -库，其中包含了内核中自定义 ``alloc`` 所提供的设施。测试可以使用 ``rusttest`` Make 目标 -来运行。 - -如果使用的是 ``rustup`` ，所有的配置文件都已经安装了该工具，因此不需要再做什么。 - -独立的安装程序也带有 ``cargo`` 。 - - rustdoc ******* @@ -223,7 +329,7 @@ Rust支持（CONFIG_RUST）需要在 ``General setup`` 菜单中启用。在其 如果使用的是GDB/Binutils，而Rust符号没有被demangled，原因是工具链还不支持Rust的新v0 mangling方案。有几个办法可以解决： - - 安装一个较新的版本（GDB >= 10.2, Binutils >= 2.36）。 +- 安装一个较新的版本（GDB >= 10.2, Binutils >= 2.36）。 - - 一些版本的GDB（例如vanilla GDB 10.1）能够使用嵌入在调试信息(``CONFIG_DEBUG_INFO``) - 中的pre-demangled的名字。 +- 一些版本的GDB（例如vanilla GDB 10.1）能够使用嵌入在调试信息(``CONFIG_DEBUG_INFO``) + 中的pre-demangled的名字。 diff --git a/Documentation/translations/zh_CN/scheduler/sched-design-CFS.rst b/Documentation/translations/zh_CN/scheduler/sched-design-CFS.rst index abc6709ec3b2..03691e0309af 100644 --- a/Documentation/translations/zh_CN/scheduler/sched-design-CFS.rst +++ b/Documentation/translations/zh_CN/scheduler/sched-design-CFS.rst @@ -144,8 +144,8 @@ array）。 - yield_task(...) - 这个函数的行为基本上是出队，紧接着入队，除非compat_yield sysctl被开启。在那种情况下， - 它将调度实体放在红黑树的最右端。 + 此函数通过将当前任务在运行队列中的位置后移来让出 CPU， + 使得其他可运行的任务优先被调度。 - wakeup_preempt(...) diff --git a/Documentation/translations/zh_TW/admin-guide/README.rst b/Documentation/translations/zh_TW/admin-guide/README.rst index c8b7ccfaa656..9be4915ae420 100644 --- a/Documentation/translations/zh_TW/admin-guide/README.rst +++ b/Documentation/translations/zh_TW/admin-guide/README.rst @@ -33,7 +33,7 @@ Linux內核6.x版本 <http://kernel.org/> 雖然Linux最初是爲32位的x86 PC機（386或更高版本）開發的，但今天它也能運行在 （至少）Compaq Alpha AXP、Sun SPARC與UltraSPARC、Motorola 68000、PowerPC、 - PowerPC64、ARM、Hitachi SuperH、Cell、IBM S/390、MIPS、HP PA-RISC、Intel + PowerPC64、ARM、Hitachi SuperH、Cell、IBM S/390、MIPS、HP PA-RISC、Intel IA-64、DEC VAX、AMD x86-64 Xtensa和ARC架構上。 Linux很容易移植到大多數通用的32位或64位體系架構，只要它們有一個分頁內存管理 diff --git a/Documentation/translations/zh_TW/process/4.Coding.rst b/Documentation/translations/zh_TW/process/4.Coding.rst index e90a6b51fb98..233e8718ed41 100644 --- a/Documentation/translations/zh_TW/process/4.Coding.rst +++ b/Documentation/translations/zh_TW/process/4.Coding.rst @@ -219,7 +219,7 @@ Documentation/fault-injection/fault-injection.rst。 可以在 https://sparse.wiki.kernel.org/index.php/Main_page 找到）, 然後可以通過在make命令中添加“C=1”在代碼上運行它。 -“Coccinelle”工具 :ref:`http://coccinelle.lip6.fr/ <devtools_coccinelle>` +“Coccinelle”工具 :ref:`https://coccinelle.gitlabpages.inria.fr/website/ <devtools_coccinelle>` 能夠發現各種潛在的編碼問題；它還可以爲這些問題提出修復方案。在 scripts/coccinelle目錄下已經打包了相當多的內核“語義補丁”；運行 “make coccicheck”將運行這些語義補丁並報告發現的任何問題。有關詳細信息，請參閱 diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst index 05445c83b79a..f56b743cdb36 100644 --- a/Documentation/userspace-api/dma-buf-heaps.rst +++ b/Documentation/userspace-api/dma-buf-heaps.rst @@ -16,6 +16,13 @@ following heaps: - The ``system`` heap allocates virtually contiguous, cacheable, buffers. + - The ``system_cc_shared`` heap allocates virtually contiguous, cacheable, + buffers using shared (decrypted) memory. It is only present on + confidential computing (CoCo) VMs where memory encryption is active + (e.g., AMD SEV, Intel TDX). The allocated pages have the encryption + bit cleared, making them accessible for device DMA without TDISP + support. On non-CoCo VM configurations, this heap is not registered. + - The ``default_cma_region`` heap allocates physically contiguous, cacheable, buffers. Only present if a CMA region is present. Such a region is usually created either through the kernel commandline diff --git a/Documentation/userspace-api/fwctl/bnxt_fwctl.rst b/Documentation/userspace-api/fwctl/bnxt_fwctl.rst new file mode 100644 index 000000000000..97c9b095cf21 --- /dev/null +++ b/Documentation/userspace-api/fwctl/bnxt_fwctl.rst @@ -0,0 +1,74 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +fwctl bnxt driver +================= + +:Author: Pavan Chebbi + +Overview +======== + +BNXT driver makes a fwctl service available through an auxiliary_device. +The bnxt_fwctl driver binds to this device and registers itself with the +fwctl subsystem. + +The bnxt_fwctl driver is agnostic to the device firmware internals. It +uses the Upper Layer Protocol (ULP) conduit provided by bnxt to send +HardWare Resource Manager (HWRM) commands to firmware. + +These commands can query or change firmware driven device configurations +and read/write registers that are useful for debugging. + +bnxt_fwctl User API +=================== + +Each RPC request contains the HWRM input structure in the fwctl_rpc +'in' buffer while 'out' will contain the response. + +A typical user application can send a FWCTL_INFO command using ioctl() +to discover bnxt_fwctl's RPC capabilities as shown below: + + ioctl(fd, FWCTL_INFO, &fwctl_info_msg); + +where fwctl_info_msg (of type struct fwctl_info) describes bnxt_info_msg +(of type struct fwctl_info_bnxt). fwctl_info_msg is set up as follows: + + size = sizeof(struct fwctl_info); + flags = 0; + device_data_len = sizeof(bnxt_info_msg); + out_device_data = (__aligned_u64)&bnxt_info_msg; + +The uctx_caps of bnxt_info_msg represents the capabilities as described +in fwctl_bnxt_commands of include/uapi/fwctl/bnxt.h + +The FW RPC itself, FWCTL_RPC can be sent using ioctl() as: + + ioctl(fd, FWCTL_RPC, &fwctl_rpc_msg); + +where fwctl_rpc_msg (of type struct fwctl_rpc) carries the HWRM command +in its 'in' buffer. The HWRM input structures are described in +include/linux/bnxt/hsi.h. An example for HWRM_VER_GET is shown below: + + struct hwrm_ver_get_output resp; + struct fwctl_rpc fwctl_rpc_msg; + struct hwrm_ver_get_input req; + + req.req_type = HWRM_VER_GET; + req.hwrm_intf_maj = HWRM_VERSION_MAJOR; + req.hwrm_intf_min = HWRM_VERSION_MINOR; + req.hwrm_intf_upd = HWRM_VERSION_UPDATE; + req.cmpl_ring = -1; + req.target_id = -1; + + fwctl_rpc_msg.size = sizeof(struct fwctl_rpc); + fwctl_rpc_msg.scope = FWCTL_RPC_DEBUG_READ_ONLY; + fwctl_rpc_msg.in_len = sizeof(req); + fwctl_rpc_msg.out_len = sizeof(resp); + fwctl_rpc_msg.in = (__aligned_u64)&req; + fwctl_rpc_msg.out = (__aligned_u64)&resp; + +An example python3 program that can exercise this interface can be found in +the following git repository: + +https://github.com/Broadcom/fwctl-tools diff --git a/Documentation/userspace-api/fwctl/fwctl.rst b/Documentation/userspace-api/fwctl/fwctl.rst index a74eab8d14c6..826817bfd54d 100644 --- a/Documentation/userspace-api/fwctl/fwctl.rst +++ b/Documentation/userspace-api/fwctl/fwctl.rst @@ -148,6 +148,7 @@ area resulting in clashes will be resolved in favour of a kernel implementation. fwctl User API ============== +.. kernel-doc:: include/uapi/fwctl/bnxt.h .. kernel-doc:: include/uapi/fwctl/fwctl.h .. kernel-doc:: include/uapi/fwctl/mlx5.h .. kernel-doc:: include/uapi/fwctl/pds.h diff --git a/Documentation/userspace-api/fwctl/index.rst b/Documentation/userspace-api/fwctl/index.rst index 316ac456ad3b..8062f7629654 100644 --- a/Documentation/userspace-api/fwctl/index.rst +++ b/Documentation/userspace-api/fwctl/index.rst @@ -10,5 +10,6 @@ to securely construct and execute RPCs inside device firmware. :maxdepth: 1 fwctl + bnxt_fwctl fwctl-cxl pds_fwctl diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst index 7f86d7a37dc2..fd8b78c31f2f 100644 --- a/Documentation/userspace-api/landlock.rst +++ b/Documentation/userspace-api/landlock.rst @@ -77,7 +77,8 @@ to be explicit about the denied-by-default access rights. LANDLOCK_ACCESS_FS_MAKE_SYM | LANDLOCK_ACCESS_FS_REFER | LANDLOCK_ACCESS_FS_TRUNCATE | - LANDLOCK_ACCESS_FS_IOCTL_DEV, + LANDLOCK_ACCESS_FS_IOCTL_DEV | + LANDLOCK_ACCESS_FS_RESOLVE_UNIX, .handled_access_net = LANDLOCK_ACCESS_NET_BIND_TCP | LANDLOCK_ACCESS_NET_CONNECT_TCP, @@ -127,6 +128,10 @@ version, and only use the available subset of access rights: /* Removes LANDLOCK_SCOPE_* for ABI < 6 */ ruleset_attr.scoped &= ~(LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET | LANDLOCK_SCOPE_SIGNAL); + __attribute__((fallthrough)); + case 6 ... 8: + /* Removes LANDLOCK_ACCESS_FS_RESOLVE_UNIX for ABI < 9 */ + ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_RESOLVE_UNIX; } This enables the creation of an inclusive ruleset that will contain our rules. @@ -378,8 +383,8 @@ Truncating files The operations covered by ``LANDLOCK_ACCESS_FS_WRITE_FILE`` and ``LANDLOCK_ACCESS_FS_TRUNCATE`` both change the contents of a file and sometimes -overlap in non-intuitive ways. It is recommended to always specify both of -these together. +overlap in non-intuitive ways. It is strongly recommended to always specify +both of these together (either granting both, or granting none). A particularly surprising example is :manpage:`creat(2)`. The name suggests that this system call requires the rights to create and write files. However, @@ -391,6 +396,10 @@ It should also be noted that truncating files does not require the system call, this can also be done through :manpage:`open(2)` with the flags ``O_RDONLY | O_TRUNC``. +At the same time, on some filesystems, :manpage:`fallocate(2)` offers a way to +shorten file contents with ``FALLOC_FL_COLLAPSE_RANGE`` when the file is opened +for writing, sidestepping the ``LANDLOCK_ACCESS_FS_TRUNCATE`` right. + The truncate right is associated with the opened file (see below). Rights associated with file descriptors @@ -700,6 +709,13 @@ enforce Landlock rulesets across all threads of the calling process using the ``LANDLOCK_RESTRICT_SELF_TSYNC`` flag passed to sys_landlock_restrict_self(). +Pathname UNIX sockets (ABI < 9) +------------------------------- + +Starting with the Landlock ABI version 9, it is possible to restrict +connections to pathname UNIX domain sockets (:manpage:`unix(7)`) using +the new ``LANDLOCK_ACCESS_FS_RESOLVE_UNIX`` right. + .. _kernel_support: Kernel support diff --git a/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst b/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst index 81b762ef17c4..99ffda355204 100644 --- a/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst +++ b/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst @@ -444,7 +444,7 @@ Description ~~~~~~~~~~~ A call to `AUDIO_GET_CAPABILITIES`_ returns an unsigned integer with the -following bits set according to the hardwares capabilities. +following bits set according to the hardware's capabilities. ----- diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst index 896177c5334f..c9999b929773 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -159,14 +159,18 @@ formats in memory (a raw Bayer image won't be magically converted to JPEG just by storing it to memory), there is no one-to-one correspondence between them. -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. For -instance, both MEDIA_BUS_FMT_BGR888_1X24 and MEDIA_BUS_FMT_BGR888_3X8 are used -on parallel busses for transferring an 8 bits per sample BGR data, whereas on -serial busses the data in this format is only referred to using -MEDIA_BUS_FMT_BGR888_1X24. This is because there is effectively only a single -way to transport that format on the serial busses. +While the media bus pixel codes are named based on how pixels are +transmitted on parallel buses, serial buses do not define separate +codes. By convention, they use the codes that transfer a sample on a +single clock cycle, and whose bit orders from LSB to MSB correspond to +the order in which colour components are transmitted on the serial bus. +For instance, the MIPI CSI-2 24-bit RGB (RGB888) format uses the +MEDIA_BUS_FMT_RGB888_1X24 media bus code because CSI-2 transmits the +blue colour component first, followed by green and red, and +MEDIA_BUS_FMT_RGB888_1X24 defines the first bit of blue at bit 0. +While used for 24-bit RGB data on parallel buses, the +MEDIA_BUS_FMT_RGB888_3X8 or MEDIA_BUS_FMT_BGR888_1X24 codes must not be +used for CSI-2. Packed RGB Formats ^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 032516783e96..52bbbb553ce1 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -907,10 +907,12 @@ The irq_type field has the following values: - KVM_ARM_IRQ_TYPE_CPU: out-of-kernel GIC: irq_id 0 is IRQ, irq_id 1 is FIQ - KVM_ARM_IRQ_TYPE_SPI: - in-kernel GIC: SPI, irq_id between 32 and 1019 (incl.) + in-kernel GICv2/GICv3: SPI, irq_id between 32 and 1019 (incl.) (the vcpu_index field is ignored) + in-kernel GICv5: SPI, irq_id between 0 and 65535 (incl.) - KVM_ARM_IRQ_TYPE_PPI: - in-kernel GIC: PPI, irq_id between 16 and 31 (incl.) + in-kernel GICv2/GICv3: PPI, irq_id between 16 and 31 (incl.) + in-kernel GICv5: PPI, irq_id between 0 and 127 (incl.) (The irq_id field thus corresponds nicely to the IRQ ID in the ARM GIC specs) @@ -9436,6 +9438,14 @@ KVM exits with the register state of either the L1 or L2 guest depending on which executed at the time of an exit. Userspace must take care to differentiate between these cases. +8.47 KVM_CAP_S390_VSIE_ESAMODE +------------------------------ + +:Architectures: s390 + +The presence of this capability indicates that the nested KVM guest can +start in ESA mode. + 9. Known KVM API problems ========================= diff --git a/Documentation/virt/kvm/arm/index.rst b/Documentation/virt/kvm/arm/index.rst index ec09881de4cf..0856b4942e05 100644 --- a/Documentation/virt/kvm/arm/index.rst +++ b/Documentation/virt/kvm/arm/index.rst @@ -10,6 +10,7 @@ ARM fw-pseudo-registers hyp-abi hypercalls + pkvm pvtime ptp_kvm vcpu-features diff --git a/Documentation/virt/kvm/arm/pkvm.rst b/Documentation/virt/kvm/arm/pkvm.rst new file mode 100644 index 000000000000..514992a79a83 --- /dev/null +++ b/Documentation/virt/kvm/arm/pkvm.rst @@ -0,0 +1,106 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +Protected KVM (pKVM) +==================== + +**NOTE**: pKVM is currently an experimental, development feature and +subject to breaking changes as new isolation features are implemented. +Please reach out to the developers at kvmarm@lists.linux.dev if you have +any questions. + +Overview +======== + +Booting a host kernel with '``kvm-arm.mode=protected``' enables +"Protected KVM" (pKVM). During boot, pKVM installs a stage-2 identity +map page-table for the host and uses it to isolate the hypervisor +running at EL2 from the rest of the host running at EL1/0. + +pKVM permits creation of protected virtual machines (pVMs) by passing +the ``KVM_VM_TYPE_ARM_PROTECTED`` machine type identifier to the +``KVM_CREATE_VM`` ioctl(). The hypervisor isolates pVMs from the host by +unmapping pages from the stage-2 identity map as they are accessed by a +pVM. Hypercalls are provided for a pVM to share specific regions of its +IPA space back with the host, allowing for communication with the VMM. +A Linux guest must be configured with ``CONFIG_ARM_PKVM_GUEST=y`` in +order to issue these hypercalls. + +See hypercalls.rst for more details. + +Isolation mechanisms +==================== + +pKVM relies on a number of mechanisms to isolate PVMs from the host: + +CPU memory isolation +-------------------- + +Status: Isolation of anonymous memory and metadata pages. + +Metadata pages (e.g. page-table pages and '``struct kvm_vcpu``' pages) +are donated from the host to the hypervisor during pVM creation and +are consequently unmapped from the stage-2 identity map until the pVM is +destroyed. + +Similarly to regular KVM, pages are lazily mapped into the guest in +response to stage-2 page faults handled by the host. However, when +running a pVM, these pages are first pinned and then unmapped from the +stage-2 identity map as part of the donation procedure. This gives rise +to some user-visible differences when compared to non-protected VMs, +largely due to the lack of MMU notifiers: + +* Memslots cannot be moved or deleted once the pVM has started running. +* Read-only memslots and dirty logging are not supported. +* With the exception of swap, file-backed pages cannot be mapped into a + pVM. +* Donated pages are accounted against ``RLIMIT_MLOCK`` and so the VMM + must have a sufficient resource limit or be granted ``CAP_IPC_LOCK``. + The lack of a runtime reclaim mechanism means that memory locked for + a pVM will remain locked until the pVM is destroyed. +* Changes to the VMM address space (e.g. a ``MAP_FIXED`` mmap() over a + mapping associated with a memslot) are not reflected in the guest and + may lead to loss of coherency. +* Accessing pVM memory that has not been shared back will result in the + delivery of a SIGSEGV. +* If a system call accesses pVM memory that has not been shared back + then it will either return ``-EFAULT`` or forcefully reclaim the + memory pages. Reclaimed memory is zeroed by the hypervisor and a + subsequent attempt to access it in the pVM will return ``-EFAULT`` + from the ``VCPU_RUN`` ioctl(). + +CPU state isolation +------------------- + +Status: **Unimplemented.** + +DMA isolation using an IOMMU +---------------------------- + +Status: **Unimplemented.** + +Proxying of Trustzone services +------------------------------ + +Status: FF-A and PSCI calls from the host are proxied by the pKVM +hypervisor. + +The FF-A proxy ensures that the host cannot share pVM or hypervisor +memory with Trustzone as part of a "confused deputy" attack. + +The PSCI proxy ensures that CPUs always have the stage-2 identity map +installed when they are executing in the host. + +Protected VM firmware (pvmfw) +----------------------------- + +Status: **Unimplemented.** + +Resources +========= + +Quentin Perret's KVM Forum 2022 talk entitled "Protected KVM on arm64: A +technical deep dive" remains a good resource for learning more about +pKVM, despite some of the details having changed in the meantime: + +https://www.youtube.com/watch?v=9npebeVFbFw diff --git a/Documentation/virt/kvm/devices/arm-vgic-v5.rst b/Documentation/virt/kvm/devices/arm-vgic-v5.rst new file mode 100644 index 000000000000..29335ea823fc --- /dev/null +++ b/Documentation/virt/kvm/devices/arm-vgic-v5.rst @@ -0,0 +1,50 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================================================== +ARM Virtual Generic Interrupt Controller v5 (VGICv5) +==================================================== + + +Device types supported: + - KVM_DEV_TYPE_ARM_VGIC_V5 ARM Generic Interrupt Controller v5.0 + +Only one VGIC instance may be instantiated through this API. The created VGIC +will act as the VM interrupt controller, requiring emulated user-space devices +to inject interrupts to the VGIC instead of directly to CPUs. + +Creating a guest GICv5 device requires a host GICv5 host. The current VGICv5 +device only supports PPI interrupts. These can either be injected from emulated +in-kernel devices (such as the Arch Timer, or PMU), or via the KVM_IRQ_LINE +ioctl. + +Groups: + KVM_DEV_ARM_VGIC_GRP_CTRL + Attributes: + + KVM_DEV_ARM_VGIC_CTRL_INIT + request the initialization of the VGIC, no additional parameter in + kvm_device_attr.addr. Must be called after all VCPUs have been created. + + KVM_DEV_ARM_VGIC_USERPSPACE_PPIs + request the mask of userspace-drivable PPIs. Only a subset of the PPIs can + be directly driven from userspace with GICv5, and the returned mask + informs userspace of which it is allowed to drive via KVM_IRQ_LINE. + + Userspace must allocate and point to __u64[2] of data in + kvm_device_attr.addr. When this call returns, the provided memory will be + populated with the userspace PPI mask. The lower __u64 contains the mask + for the lower 64 PPIS, with the remaining 64 being in the second __u64. + + This is a read-only attribute, and cannot be set. Attempts to set it are + rejected. + + Errors: + + ======= ======================================================== + -ENXIO VGIC not properly configured as required prior to calling + this attribute + -ENODEV no online VCPU + -ENOMEM memory shortage when allocating vgic internal data + -EFAULT Invalid guest ram access + -EBUSY One or more VCPUS are running + ======= ======================================================== diff --git a/Documentation/virt/kvm/devices/index.rst b/Documentation/virt/kvm/devices/index.rst index 192cda7405c8..70845aba38f4 100644 --- a/Documentation/virt/kvm/devices/index.rst +++ b/Documentation/virt/kvm/devices/index.rst @@ -10,6 +10,7 @@ Devices arm-vgic-its arm-vgic arm-vgic-v3 + arm-vgic-v5 mpic s390_flic vcpu diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst index 60bf205cb373..5e3805820010 100644 --- a/Documentation/virt/kvm/devices/vcpu.rst +++ b/Documentation/virt/kvm/devices/vcpu.rst @@ -37,7 +37,8 @@ Returns: A value describing the PMUv3 (Performance Monitor Unit v3) overflow interrupt number for this vcpu. This interrupt could be a PPI or SPI, but the interrupt type must be same for each vcpu. As a PPI, the interrupt number is the same for -all vcpus, while as an SPI it must be a separate number per vcpu. +all vcpus, while as an SPI it must be a separate number per vcpu. For +GICv5-based guests, the architected PPI (23) must be used. 1.2 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_INIT --------------------------------------- @@ -50,7 +51,7 @@ Returns: -EEXIST Interrupt number already used -ENODEV PMUv3 not supported or GIC not initialized -ENXIO PMUv3 not supported, missing VCPU feature or interrupt - number not set + number not set (non-GICv5 guests, only) -EBUSY PMUv3 already initialized ======= ====================================================== diff --git a/Documentation/wmi/devices/bitland-mifs-wmi.rst b/Documentation/wmi/devices/bitland-mifs-wmi.rst new file mode 100644 index 000000000000..9e86ecc2993c --- /dev/null +++ b/Documentation/wmi/devices/bitland-mifs-wmi.rst @@ -0,0 +1,207 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +======================================== +Bitland MIFS driver (bitland-mifs-wmi) +======================================== + +Introduction +============ + + +EC WMI interface description +============================ + +The EC WMI interface description can be decoded from the embedded binary MOF (bmof) +data using the `bmfdec <https://github.com/pali/bmfdec>`_ utility: + +:: + + class WMIEvent : __ExtrinsicEvent { + }; + + [WMI, Dynamic, Provider("WmiProv"), Locale("MS\\0x40A"), Description("Root WMI HID_EVENT20"), guid("{46c93e13-ee9b-4262-8488-563bca757fef}")] + class HID_EVENT20 : WmiEvent { + [key, read] string InstanceName; + [read] boolean Active; + [WmiDataId(1), read, write, Description("Package Data")] uint8 EventDetail[8]; + }; + + [WMI, Dynamic, Provider("WmiProv"), Locale("MS\\0x40A"), Description("Root WMI HID_EVENT21"), guid("{fa78e245-2c0f-4ca1-91cf-15f34e474850}")] + class HID_EVENT21 : WmiEvent { + [key, read] string InstanceName; + [read] boolean Active; + [WmiDataId(1), read, write, Description("Package Data")] uint8 EventDetail[8]; + }; + + [WMI, Dynamic, Provider("WmiProv"), Locale("MS\\0x40A"), Description("Root WMI HID_EVENT22"), guid("{1dceaf0a-4d63-44bb-bd0c-0d6281bfddc5}")] + class HID_EVENT22 : WmiEvent { + [key, read] string InstanceName; + [read] boolean Active; + [WmiDataId(1), read, write, Description("Package Data")] uint8 EventDetail[8]; + }; + + [WMI, Dynamic, Provider("WmiProv"), Locale("MS\\0x40A"), Description("Root WMI HID_EVENT23"), guid("{3f9e3c26-b077-4f86-91f5-37ff64d8c7ed}")] + class HID_EVENT23 : WmiEvent { + [key, read] string InstanceName; + [read] boolean Active; + [WmiDataId(1), read, write, Description("Package Data")] uint8 EventDetail[8]; + }; + + [WMI, Dynamic, provider("WmiProv"), Locale("MS\\0x409"), Description("Class used to operate firmware interface"), guid("{b60bfb48-3e5b-49e4-a0e9-8cffe1b3434b}")] + class MICommonInterface { + [key, read] string InstanceName; + [read] boolean Active; + + [WmiMethodId(1), Implemented, read, write, Description("Method used to support system functions.")] void MiInterface([in, Description("WMI Interface")] uint8 InData[32], [out] uint8 OutData[30], [out] uint16 Reserved); + }; + +Reverse-Engineering the EC WMI interface +======================================== + +The OEM software can be download from `this link <https://iknow.lenovo.com.cn/detail/429447>`_ + +Nothing is obfuscated, In this case, `ILSpy <https://github.com/icsharpcode/ILSpy>`_ could be helpful. + +WMI Methods (MICommonInterface) +======================================== + +The ``MICommonInterface`` class (GUID: ``{b60bfb48-3e5b-49e4-a0e9-8cffe1b3434b}``) +is the primary control interface. It uses a 32-byte buffer for both input +(``InData``) and output (``OutData``). + +Method Structure +---------------- + +The data packet follows a standardized format: + ++----------+------------------------------------------------------------------+ +| Byte | Description | ++==========+==================================================================+ +| 1 | Method Type: Get (0xFA / 250) or Set (0xFB / 251) | ++----------+------------------------------------------------------------------+ +| 3 | Command ID (Method Name) | ++----------+------------------------------------------------------------------+ +| 4 - 31 | Arguments (for Set) or Return Data (for Get) | ++----------+------------------------------------------------------------------+ + + +Command IDs +----------- + +The following Command IDs are used in the third byte of the buffer: + ++----------+-----------------------+------------------------------------------+ +| ID | Name | Values / Description | ++==========+=======================+==========================================+ +| 8 | SystemPerMode | 0: Balance, 1: Performance, 2: Quiet, | +| | | 3: Full-speed | ++----------+-----------------------+------------------------------------------+ +| 9 | GPUMode | 0: Hybrid, 1: Discrete, 2: UMA | ++----------+-----------------------+------------------------------------------+ +| 10 | KeyboardType | 0: White, 1: Single RGB, 2: Zone RGB | ++----------+-----------------------+------------------------------------------+ +| 11 | FnLock | 0: Off, 1: On | ++----------+-----------------------+------------------------------------------+ +| 12 | TPLock | 0: Unlock, 1: Lock (Touchpad) | ++----------+-----------------------+------------------------------------------+ +| 13 | CPUGPUSYSFanSpeed | Returns 12 bytes of fan data: | +| | | Bytes 4-5: CPU Fan RPM (Little Endian) | +| | | Bytes 6-7: GPU Fan RPM (Little Endian) | +| | | Bytes 10-11: SYS Fan RPM (Little Endian) | ++----------+-----------------------+------------------------------------------+ +| 16 | RGBKeyboardMode | 0: Off, 1: Auto Cyclic, 2: Fixed, | +| | | 3: Custom | ++----------+-----------------------+------------------------------------------+ +| 17 | RGBKeyboardColor | Bytes 4, 5, 6: Red, Green, Blue values | ++----------+-----------------------+------------------------------------------+ +| 18 | RGBKeyboardBrightness | 0-10: Brightness Levels, 128: Auto | ++----------+-----------------------+------------------------------------------+ +| 19 | SystemAcType | 1: Type-C, 2: Circular Hole (DC) | ++----------+-----------------------+------------------------------------------+ +| 20 | MaxFanSpeedSwitch | Byte 4: Fan Type (0: CPU/GPU, 1: SYS) | +| | | Byte 5: State (0: Off, 1: On) | ++----------+-----------------------+------------------------------------------+ +| 21 | MaxFanSpeed | Sets manual fan speed duty cycle | ++----------+-----------------------+------------------------------------------+ +| 22 | CPUThermometer | Returns CPU Temperature | ++----------+-----------------------+------------------------------------------+ + +WMI Events (HID_EVENT20) +======================== + +The driver listens for events from the ``HID_EVENT20`` class +(GUID: ``{46c93e13-ee9b-4262-8488-563bca757fef}``). These events are triggered +by hotkeys or system state changes (e.g., plugging in AC power). + +Event Structure +--------------- + +The event data is provided in an 8-byte array (``EventDetail``): + ++----------+------------------------------------------------------------------+ +| Byte | Description | ++==========+==================================================================+ +| 0 | Event Type (Always 0x01 for HotKey/Notification) | ++----------+------------------------------------------------------------------+ +| 1 | Event ID (Corresponds to the Command IDs above) | ++----------+------------------------------------------------------------------+ +| 2 | Value (The new state or value of the feature) | ++----------+------------------------------------------------------------------+ + +Common Event IDs: +----------------- + +Note: reserved event ids are not listed there + ++----------+------------------------------------------------------------------+ +| Event Id | Description | ++==========+==================================================================+ +| 4 | AirPlane mode change | ++----------+------------------------------------------------------------------+ +| 5 | Keyboard brightness change | ++----------+------------------------------------------------------------------+ +| 6 | Touchpad state (enabled/disabled) change | ++----------+------------------------------------------------------------------+ +| 7 | FnLock state (enabled/disabled) change | ++----------+------------------------------------------------------------------+ +| 8 | Keyboard mode change | ++----------+------------------------------------------------------------------+ +| 9 | CapsLock state change | ++----------+------------------------------------------------------------------+ +| 13 | NumLock state change | ++----------+------------------------------------------------------------------+ +| 14 | ScrollLock state change | ++----------+------------------------------------------------------------------+ +| 15 | Performance plan change | ++----------+------------------------------------------------------------------+ +| 25 | Display refresh rate change | ++----------+------------------------------------------------------------------+ +| 33 | Super key lock state (enabled/disabled) change | ++----------+------------------------------------------------------------------+ +| 35 | Open control center key | ++----------+------------------------------------------------------------------+ + +Implementation Details +====================== + +Performance Modes +----------------- +Changing the performance mode via Command ID 0x08 (SystemPerMode) affects the +power limits (PL1/PL2) and fan curves managed by the Embedded Controller (EC). +Note that the "Full-speed" and "Performance" mode (1, 3) is typically only +available when the system is connected to a DC power source (not USB-C/PD). + +In the driver implementation, switch to performance/full-speed mode without +DC power connected will throw the EOPNOTSUPP error. + +Graphics Switching +------------------ +The ``GPUMode`` (0x09) allows switching between Hybrid (Muxless) and Discrete +(Muxed) graphics. Changing this value usually requires a system reboot to +take effect in the BIOS/Firmware. + +Fan Control +----------- +The system supports both automatic EC control and manual overrides. Command ID +0x14 (``MaxFanSpeedSwitch``) is used to toggle manual control, while ID 0x15 +sets the actual PWM duty cycle. diff --git a/Documentation/wmi/driver-development-guide.rst b/Documentation/wmi/driver-development-guide.rst index fbc2d9b12fe9..387f508d57ad 100644 --- a/Documentation/wmi/driver-development-guide.rst +++ b/Documentation/wmi/driver-development-guide.rst @@ -71,7 +71,7 @@ to matching WMI devices using a struct wmi_device_id table: .remove = foo_remove, /* optional, devres is preferred */ .shutdown = foo_shutdown, /* optional, called during shutdown */ .notify_new = foo_notify, /* optional, for event handling */ - .no_notify_data = true, /* optional, enables events containing no additional data */ + .min_event_size = X, /* optional, simplifies event payload size verification */ .no_singleton = true, /* required for new WMI drivers */ }; module_wmi_driver(foo_driver); @@ -106,7 +106,8 @@ WMI method drivers WMI drivers can call WMI device methods using wmidev_invoke_method(). For each WMI method invocation the WMI driver needs to provide the instance number and the method ID, as well as -a buffer with the method arguments and optionally a buffer for the results. +a buffer with the method arguments and optionally a buffer for the results. When calling WMI +methods that do not return any values, wmidev_invoke_procedure() should be used instead. The layout of said buffers is device-specific and described by the Binary MOF data associated with a given WMI device. Said Binary MOF data also describes the method ID of a given WMI method @@ -141,8 +142,10 @@ right before and after calling its remove() or shutdown() callback. However WMI driver developers should be aware that multiple WMI events can be received concurrently, so any locking (if necessary) needs to be provided by the WMI driver itself. -In order to be able to receive WMI events containing no additional event data, -the ``no_notify_data`` flag inside struct wmi_driver should be set to ``true``. +The WMI driver can furthermore instruct the WMI driver core to automatically reject WMI events +that contain a undersized event payload by populating the ``min_event_size`` field inside +struct wmi_driver. Setting this field to 0 will thus enable the WMI driver to receive WMI events +without any event payload. Take a look at drivers/platform/x86/xiaomi-wmi.c for an example WMI event driver. |