diff options
Diffstat (limited to 'Documentation')
43 files changed, 287 insertions, 653 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 index e8698afcd952..f7e32f218f73 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 @@ -43,6 +43,13 @@ Description: read only This sysfs interface exposes the number of cores per chip present in the system. +What: /sys/devices/hv_24x7/interface/cpumask +Date: July 2020 +Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> +Description: read only + This sysfs file exposes the cpumask which is designated to make + HCALLs to retrieve hv-24x7 pmu event counter data. + What: /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name> Date: February 2014 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem index 5b10d036a8d4..c1a67275c43f 100644 --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem @@ -25,3 +25,30 @@ Description: NVDIMM have been scrubbed. * "locked" : Indicating that NVDIMM contents cant be modified until next power cycle. + +What: /sys/bus/nd/devices/nmemX/papr/perf_stats +Date: May, 2020 +KernelVersion: v5.9 +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org, +Description: + (RO) Report various performance stats related to papr-scm NVDIMM + device. Each stat is reported on a new line with each line + composed of a stat-identifier followed by it value. Below are + currently known dimm performance stats which are reported: + + * "CtlResCt" : Controller Reset Count + * "CtlResTm" : Controller Reset Elapsed Time + * "PonSecs " : Power-on Seconds + * "MemLife " : Life Remaining + * "CritRscU" : Critical Resource Utilization + * "HostLCnt" : Host Load Count + * "HostSCnt" : Host Store Count + * "HostSDur" : Host Store Duration + * "HostLDur" : Host Load Duration + * "MedRCnt " : Media Read Count + * "MedWCnt " : Media Write Count + * "MedRDur " : Media Read Duration + * "MedWDur " : Media Write Duration + * "CchRHCnt" : Cache Read Hit Count + * "CchWHCnt" : Cache Write Hit Count + * "FastWCnt" : Fast Write Count
\ No newline at end of file diff --git a/Documentation/ABI/testing/sysfs-class-ocxl b/Documentation/ABI/testing/sysfs-class-ocxl index b5b1fa197592..ae1276efa45a 100644 --- a/Documentation/ABI/testing/sysfs-class-ocxl +++ b/Documentation/ABI/testing/sysfs-class-ocxl @@ -33,3 +33,14 @@ Date: January 2018 Contact: linuxppc-dev@lists.ozlabs.org Description: read/write Give access the global mmio area for the AFU + +What: /sys/class/ocxl/<afu name>/reload_on_reset +Date: February 2020 +Contact: linuxppc-dev@lists.ozlabs.org +Description: read/write + Control whether the FPGA is reloaded on a link reset. Enabled + through a vendor-specific logic block on the FPGA. + 0 Do not reload FPGA image from flash + 1 Reload FPGA image from flash + unavailable + The device does not support this capability diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index 016724ec26d5..d1a352194d2e 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -883,3 +883,139 @@ Contact: Subhash Jadavani <subhashj@codeaurora.org> Description: This entry shows the target state of an UFS UIC link for the chosen system power management level. The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_presv_us_en +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows if preserve user-space was configured + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_shared_alloc_units +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the shared allocated units of WB buffer + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_type +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the configured WB type. + 0x1 for shared buffer mode. 0x0 for dedicated buffer mode. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_buff_cap_adj +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the total user-space decrease in shared + buffer mode. + The value of this parameter is 3 for TLC NAND when SLC mode + is used as WriteBooster Buffer. 2 for MLC NAND. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_alloc_units +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the Maximum total WriteBooster Buffer size + which is supported by the entire device. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_wb_luns +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the maximum number of luns that can support + WriteBooster. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_red_type +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: The supportability of user space reduction mode + and preserve user space mode. + 00h: WriteBooster Buffer can be configured only in + user space reduction type. + 01h: WriteBooster Buffer can be configured only in + preserve user space type. + 02h: Device can be configured in either user space + reduction type or preserve user space type. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_wb_type +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: The supportability of WriteBooster Buffer type. + 00h: LU based WriteBooster Buffer configuration + 01h: Single shared WriteBooster Buffer + configuration + 02h: Supporting both LU based WriteBooster + Buffer and Single shared WriteBooster Buffer + configuration + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_enable +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the status of WriteBooster. + 0: WriteBooster is not enabled. + 1: WriteBooster is enabled + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_en +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows if flush is enabled. + 0: Flush operation is not performed. + 1: Flush operation is performed. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_during_h8 +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: Flush WriteBooster Buffer during hibernate state. + 0: Device is not allowed to flush the + WriteBooster Buffer during link hibernate + state. + 1: Device is allowed to flush the + WriteBooster Buffer during link hibernate + state + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_avail_buf +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the amount of unused WriteBooster buffer + available. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_cur_buf +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the amount of unused current buffer. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_flush_status +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the flush operation status. + 00h: idle + 01h: Flush operation in progress + 02h: Flush operation stopped prematurely. + 03h: Flush operation completed successfully + 04h: Flush operation general failure + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_life_time_est +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows an indication of the WriteBooster Buffer + lifetime based on the amount of performed program/erase cycles + 01h: 0% - 10% WriteBooster Buffer life time used + ... + 0Ah: 90% - 100% WriteBooster Buffer life time used + The file is read only. + +What: /sys/class/scsi_device/*/device/unit_descriptor/wb_buf_alloc_units +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the configured size of WriteBooster buffer. + 0400h corresponds to 4GB. + The file is read only. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index c95552269689..98ea67f27809 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -916,6 +916,10 @@ disable_radix [PPC] Disable RADIX MMU mode on POWER9 + radix_hcall_invalidate=on [PPC/PSERIES] + Disable RADIX GTSE feature and use hcall for TLB + invalidate. + disable_tlbie [PPC] Disable TLBIE instruction. Currently does not work with KVM, with HASH MMU, or with coherent accelerators. diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst index f64668759b6a..298c9c8bea9a 100644 --- a/Documentation/core-api/cpu_hotplug.rst +++ b/Documentation/core-api/cpu_hotplug.rst @@ -50,13 +50,6 @@ Command Line Switches This option is limited to the X86 and S390 architecture. -``cede_offline={"off","on"}`` - Use this option to disable/enable putting offlined processors to an extended - ``H_CEDE`` state on supported pseries platforms. If nothing is specified, - ``cede_offline`` is set to "on". - - This option is limited to the PowerPC architecture. - ``cpu0_hotplug`` Allow to shutdown CPU0. diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt index 1f293ea24cd8..55deb68230eb 100644 --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt @@ -102,7 +102,7 @@ Required sub-node properties: [0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Documentation/devicetree/bindings/power/power-domain.yaml -[3] Documentation/devicetree/bindings/thermal/thermal.txt +[3] Documentation/devicetree/bindings/thermal/thermal*.yaml [4] Documentation/devicetree/bindings/sram/sram.yaml [5] Documentation/devicetree/bindings/reset/reset.txt diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt index dd04d9d9a1b8..bcd6c3ec471e 100644 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -108,7 +108,7 @@ Required properties: [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html [1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/thermal/thermal.txt +[2] Documentation/devicetree/bindings/thermal/thermal*.yaml [3] Documentation/devicetree/bindings/sram/sram.yaml [4] Documentation/devicetree/bindings/power/power-domain.yaml diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 10b8459e49f8..6064d98b1031 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -176,7 +176,7 @@ Required properties: "fsl,imx8qxp-sc-thermal" followed by "fsl,imx-sc-thermal"; -- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal.txt +- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Example (imx8qxp): diff --git a/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt index 098d932fc963..e31511255d8e 100644 --- a/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt @@ -111,7 +111,7 @@ Thermal: -------- For common binding part and usage, refer to -Documentation/devicetree/bindings/thermal/thermal.txt +Documentation/devicetree/bindings/thermal/thermal*.yaml The thermal IP can probe the temperature all around the processor. It may feature several channels, each of them wired to one sensor. diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt index f982a8ed9396..a21f7709596c 100644 --- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt @@ -203,7 +203,7 @@ It is possible to setup an overheat interrupt by giving at least one critical point to any subnode of the thermal-zone node. For common binding part and usage, refer to -Documentation/devicetree/bindings/thermal/thermal.txt +Documentation/devicetree/bindings/thermal/thermal*.yaml Required properties: - compatible: must be one of: diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt index 332aed8f4597..56f442374383 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt @@ -18,7 +18,8 @@ Optional properties: in unit of nanoseconds. - voltage-tolerance: Specify the CPU voltage tolerance in percentage. - #cooling-cells: - Please refer to Documentation/devicetree/bindings/thermal/thermal.txt. + Please refer to + Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml. Examples: diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt index 0551c78619de..ea4994b35207 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt @@ -21,8 +21,8 @@ Optional properties: flow is handled by hardware, hence no software "voltage tracking" is needed. - #cooling-cells: - Please refer to Documentation/devicetree/bindings/thermal/thermal.txt - for detail. + For details, please refer to + Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml Example 1 (MT7623 SoC): diff --git a/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt index daeca6ae6b76..52a24b82fd86 100644 --- a/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt +++ b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt @@ -5,7 +5,7 @@ Required properties: - clocks: Must contain an entry for the CPU clock. See ../clocks/clock-bindings.txt for details. - operating-points-v2: See ../bindings/opp/opp.txt for details. -- #cooling-cells: Should be 2. See ../thermal/thermal.txt for details. +- #cooling-cells: Should be 2. See ../thermal/thermal-cooling-devices.yaml for details. For each opp entry in 'operating-points-v2' table: - opp-supported-hw: Two bitfields indicating: diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt index 2becdcfdc840..f4cfa350f6a1 100644 --- a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt +++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt @@ -12,7 +12,8 @@ Optional properties: - alarm-gpios: This pin going active indicates something is wrong with the fan, and a udev event will be fired. - #cooling-cells: If used as a cooling device, must be <2> - Also see: Documentation/devicetree/bindings/thermal/thermal.txt + Also see: + Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml min and max states are derived from the speed-map of the fan. Note: At least one the "gpios" or "alarm-gpios" properties must be set. diff --git a/Documentation/devicetree/bindings/hwmon/lm90.txt b/Documentation/devicetree/bindings/hwmon/lm90.txt index c76a7ac47c34..398dcb965751 100644 --- a/Documentation/devicetree/bindings/hwmon/lm90.txt +++ b/Documentation/devicetree/bindings/hwmon/lm90.txt @@ -34,8 +34,8 @@ Optional properties: LM90 "-ALERT" pin output. See interrupt-controller/interrupts.txt for the format. -- #thermal-sensor-cells: should be set to 1. See thermal/thermal.txt for - details. See <include/dt-bindings/thermal/lm90.h> for the +- #thermal-sensor-cells: should be set to 1. See thermal/thermal-sensor.yaml + for details. See <include/dt-bindings/thermal/lm90.h> for the definition of the local, remote and 2nd remote sensor index constants. diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml index 87369264feb9..44ba6765697d 100644 --- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml +++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml @@ -50,7 +50,7 @@ properties: nvmem-cell-names: const: calibration - # See ./thermal.txt for details + # See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for details "#thermal-sensor-cells": enum: - 0 diff --git a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt index 703979dbd577..12fc4ef04837 100644 --- a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt @@ -6,7 +6,7 @@ transaction. Required properties: - compatible: "amazon,al-thermal". - reg: The physical base address and length of the sensor's registers. -- #thermal-sensor-cells: Must be 1. See ./thermal.txt for a description. +- #thermal-sensor-cells: Must be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Example: thermal: thermal { diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml b/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml index f3e68ed03abf..1ab5070c751d 100644 --- a/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml @@ -23,7 +23,7 @@ properties: compatible: const: brcm,bcm2711-thermal - # See ./thermal.txt for details + # See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for details "#thermal-sensor-cells": const: 0 diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt index da8c5b73ad10..a3e9ec5dc7ac 100644 --- a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt @@ -7,7 +7,7 @@ compatible: should be one of: "brcm,bcm2835-thermal", "brcm,bcm2836-thermal" or "brcm,bcm2837-thermal" reg: Address range of the thermal registers. clocks: Phandle of the clock used by the thermal sensor. -#thermal-sensor-cells: should be 0 (see thermal.txt) +#thermal-sensor-cells: should be 0 (see Documentation/devicetree/bindings/thermal/thermal-sensor.yaml) Example: diff --git a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt index cef716a236f1..4b19d80e6558 100644 --- a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt @@ -9,7 +9,7 @@ by /SOCTHERM/tsensor. - clock-names: Input clock name, should be 'thermal_clk'. - clocks: phandles for clock specified in "clock-names" property. -- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description. +- #thermal-sensor-cells: Should be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Example : diff --git a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt b/Documentation/devicetree/bindings/thermal/max77620_thermal.txt index 323a3b3822aa..82ed5d487966 100644 --- a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt +++ b/Documentation/devicetree/bindings/thermal/max77620_thermal.txt @@ -8,12 +8,12 @@ below threshold level. Required properties: ------------------- -#thermal-sensor-cells: Please refer <devicetree/bindings/thermal/thermal.txt> - for more details. +#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.txt>. +<devicetree/bindings/thermal/thermal*.yaml>. Please refer <devicetree/bindings/mfd/max77620.txt> for mfd DT binding document for the MAX77620. diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt index f8d7831f3974..1e249c42fae0 100644 --- a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt @@ -23,7 +23,7 @@ Required properties: - resets: Reference to the reset controller controlling the thermal controller. - mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses - mediatek,apmixedsys: A phandle to the APMIXEDSYS controller. -- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description. +- #thermal-sensor-cells : Should be 0. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Optional properties: - nvmem-cells: A phandle to the calibration data provided by a nvmem device. If diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt index f02f38527a6b..db880e7ed713 100644 --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt @@ -28,9 +28,10 @@ Required properties : See ../reset/reset.txt for details. - reset-names : Must include the following entries: - soctherm -- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description - of this property. See <dt-bindings/thermal/tegra124-soctherm.h> for a - list of valid values when referring to thermal sensors. +- #thermal-sensor-cells : Should be 1. For a description of this property, see + Documentation/devicetree/bindings/thermal/thermal-sensor.yaml. + See <dt-bindings/thermal/tegra124-soctherm.h> for a list of valid values + when referring to thermal sensors. - throttle-cfgs: A sub-node which is a container of configuration for each hardware throttle events. These events can be set as cooling devices. * throttle events: Sub-nodes must be named as "light" or "heavy". @@ -62,7 +63,8 @@ Required properties : TEGRA_SOCTHERM_THROT_LEVEL_MED (75%), TEGRA_SOCTHERM_THROT_LEVEL_HIGH (85%). - #cooling-cells: Should be 1. This cooling device only support on/off state. - See ./thermal.txt for a description of this property. + For a description of this property see: + Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml Optional properties: The following properties are T210 specific and valid only for OCx throttle events. diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt index e17c07be270b..fc87f6aa1b8f 100644 --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt @@ -8,7 +8,7 @@ exposed by BPMP. The BPMP thermal node must be located directly inside the main BPMP node. See ../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding. -This node represents a thermal sensor. See thermal.txt for details of the +This node represents a thermal sensor. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for details of the core thermal binding. Required properties: diff --git a/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt b/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt index 0273a92a2a84..2d5b2ad03314 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt +++ b/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt @@ -8,7 +8,7 @@ Required properties: - compatible: Should contain "qcom,spmi-temp-alarm". - reg: Specifies the SPMI address. - interrupts: PMIC temperature alarm interrupt. -- #thermal-sensor-cells: Should be 0. See thermal.txt for a description. +- #thermal-sensor-cells: Should be 0. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Optional properties: - io-channels: Should contain IIO channel specifier for the ADC channel, diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index adac01c9d9cd..95462e071ab4 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -23,6 +23,7 @@ properties: items: - enum: - qcom,msm8916-tsens + - qcom,msm8939-tsens - qcom,msm8974-tsens - const: qcom,tsens-v0_1 diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index c6aac9bcacf1..7f94669e9ebe 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt @@ -24,7 +24,7 @@ Required properties: - pinctrl-1 : The "default" pinctrl state, it will be set after reset the TSADC controller. - pinctrl-2 : The "sleep" pinctrl state, it will be in for suspend. -- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description. +- #thermal-sensor-cells : Should be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Optional properties: - rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value. diff --git a/Documentation/devicetree/bindings/thermal/tango-thermal.txt b/Documentation/devicetree/bindings/thermal/tango-thermal.txt index 212198d4b937..2c918d742867 100644 --- a/Documentation/devicetree/bindings/thermal/tango-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/tango-thermal.txt @@ -4,7 +4,7 @@ The SMP8758 SoC includes 3 instances of this temperature sensor (in the CPU, video decoder, and PCIe controller). Required properties: -- #thermal-sensor-cells: Should be 0 (see thermal.txt) +- #thermal-sensor-cells: Should be 0 (see Documentation/devicetree/bindings/thermal/thermal-sensor.yaml) - compatible: "sigma,smp8758-thermal" - reg: Address range of the thermal registers diff --git a/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt index 691a09db2fef..e136946a2f4f 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt +++ b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt @@ -8,7 +8,7 @@ temperature using voltage-temperature lookup table. Required properties: =================== - compatible: Must be "generic-adc-thermal". -- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description +- #thermal-sensor-cells: Should be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description of this property. Optional properties: =================== diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt deleted file mode 100644 index f78bec19ca35..000000000000 --- a/Documentation/devicetree/bindings/thermal/thermal.txt +++ /dev/null @@ -1,586 +0,0 @@ -* Thermal Framework Device Tree descriptor - -This file describes a generic binding to provide a way of -defining hardware thermal structure using device tree. -A thermal structure includes thermal zones and their components, -such as trip points, polling intervals, sensors and cooling devices -binding descriptors. - -The target of device tree thermal descriptors is to describe only -the hardware thermal aspects. The thermal device tree bindings are -not about how the system must control or which algorithm or policy -must be taken in place. - -There are five types of nodes involved to describe thermal bindings: -- thermal sensors: devices which may be used to take temperature - measurements. -- cooling devices: devices which may be used to dissipate heat. -- trip points: describe key temperatures at which cooling is recommended. The - set of points should be chosen based on hardware limits. -- cooling maps: used to describe links between trip points and cooling devices; -- thermal zones: used to describe thermal data within the hardware; - -The following is a description of each of these node types. - -* Thermal sensor devices - -Thermal sensor devices are nodes providing temperature sensing capabilities on -thermal zones. Typical devices are I2C ADC converters and bandgaps. These are -nodes providing temperature data to thermal zones. Thermal sensor devices may -control one or more internal sensors. - -Required property: -- #thermal-sensor-cells: Used to provide sensor device specific information - Type: unsigned while referring to it. Typically 0 on thermal sensor - Size: one cell nodes with only one sensor, and at least 1 on nodes - with several internal sensors, in order - to identify uniquely the sensor instances within - the IC. See thermal zone binding for more details - on how consumers refer to sensor devices. - -* Cooling device nodes - -Cooling devices are nodes providing control on power dissipation. There -are essentially two ways to provide control on power dissipation. First -is by means of regulating device performance, which is known as passive -cooling. A typical passive cooling is a CPU that has dynamic voltage and -frequency scaling (DVFS), and uses lower frequencies as cooling states. -Second is by means of activating devices in order to remove -the dissipated heat, which is known as active cooling, e.g. regulating -fan speeds. In both cases, cooling devices shall have a way to determine -the state of cooling in which the device is. - -Any cooling device has a range of cooling states (i.e. different levels -of heat dissipation). For example a fan's cooling states correspond to -the different fan speeds possible. Cooling states are referred to by -single unsigned integers, where larger numbers mean greater heat -dissipation. The precise set of cooling states associated with a device -should be defined in a particular device's binding. -For more examples of cooling devices, refer to the example sections below. - -Required properties: -- #cooling-cells: Used to provide cooling device specific information - Type: unsigned while referring to it. Must be at least 2, in order - Size: one cell to specify minimum and maximum cooling state used - in the reference. The first cell is the minimum - cooling state requested and the second cell is - the maximum cooling state requested in the reference. - See Cooling device maps section below for more details - on how consumers refer to cooling devices. - -* Trip points - -The trip node is a node to describe a point in the temperature domain -in which the system takes an action. This node describes just the point, -not the action. - -Required properties: -- temperature: An integer indicating the trip temperature level, - Type: signed in millicelsius. - Size: one cell - -- hysteresis: A low hysteresis value on temperature property (above). - Type: unsigned This is a relative value, in millicelsius. - Size: one cell - -- type: a string containing the trip type. Expected values are: - "active": A trip point to enable active cooling - "passive": A trip point to enable passive cooling - "hot": A trip point to notify emergency - "critical": Hardware not reliable. - Type: string - -* Cooling device maps - -The cooling device maps node is a node to describe how cooling devices -get assigned to trip points of the zone. The cooling devices are expected -to be loaded in the target system. - -Required properties: -- cooling-device: A list of phandles of cooling devices with their specifiers, - Type: phandle + referring to which cooling devices are used in this - cooling specifier binding. In the cooling specifier, the first cell - is the minimum cooling state and the second cell - is the maximum cooling state used in this map. -- trip: A phandle of a trip point node within the same thermal - Type: phandle of zone. - trip point node - -Optional property: -- contribution: The cooling contribution to the thermal zone of the - Type: unsigned referred cooling device at the referred trip point. - Size: one cell The contribution is a ratio of the sum - of all cooling contributions within a thermal zone. - -Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle -limit specifier means: -(i) - minimum state allowed for minimum cooling state used in the reference. -(ii) - maximum state allowed for maximum cooling state used in the reference. -Refer to include/dt-bindings/thermal/thermal.h for definition of this constant. - -* Thermal zone nodes - -The thermal zone node is the node containing all the required info -for describing a thermal zone, including its cooling device bindings. The -thermal zone node must contain, apart from its own properties, one sub-node -containing trip nodes and one sub-node containing all the zone cooling maps. - -Required properties: -- polling-delay: The maximum number of milliseconds to wait between polls - Type: unsigned when checking this thermal zone. - Size: one cell - -- polling-delay-passive: The maximum number of milliseconds to wait - Type: unsigned between polls when performing passive cooling. - Size: one cell - -- thermal-sensors: A list of thermal sensor phandles and sensor specifier - Type: list of used while monitoring the thermal zone. - phandles + sensor - specifier - -- trips: A sub-node which is a container of only trip point nodes - Type: sub-node required to describe the thermal zone. - -Optional property: -- cooling-maps: A sub-node which is a container of only cooling device - Type: sub-node map nodes, used to describe the relation between trips - and cooling devices. - -- coefficients: An array of integers (one signed cell) containing - Type: array coefficients to compose a linear relation between - Elem size: one cell the sensors listed in the thermal-sensors property. - Elem type: signed Coefficients defaults to 1, in case this property - is not specified. A simple linear polynomial is used: - Z = c0 * x0 + c1 * x1 + ... + c(n-1) * x(n-1) + cn. - - The coefficients are ordered and they match with sensors - by means of sensor ID. Additional coefficients are - interpreted as constant offset. - -- sustainable-power: An estimate of the sustainable power (in mW) that the - Type: unsigned thermal zone can dissipate at the desired - Size: one cell control temperature. For reference, the - sustainable power of a 4'' phone is typically - 2000mW, while on a 10'' tablet is around - 4500mW. - -Note: The delay properties are bound to the maximum dT/dt (temperature -derivative over time) in two situations for a thermal zone: -(i) - when passive cooling is activated (polling-delay-passive); and -(ii) - when the zone just needs to be monitored (polling-delay) or -when active cooling is activated. - -The maximum dT/dt is highly bound to hardware power consumption and dissipation -capability. The delays should be chosen to account for said max dT/dt, -such that a device does not cross several trip boundaries unexpectedly -between polls. Choosing the right polling delays shall avoid having the -device in temperature ranges that may damage the silicon structures and -reduce silicon lifetime. - -* The thermal-zones node - -The "thermal-zones" node is a container for all thermal zone nodes. It shall -contain only sub-nodes describing thermal zones as in the section -"Thermal zone nodes". The "thermal-zones" node appears under "/". - -* Examples - -Below are several examples on how to use thermal data descriptors -using device tree bindings: - -(a) - CPU thermal zone - -The CPU thermal zone example below describes how to setup one thermal zone -using one single sensor as temperature source and many cooling devices and -power dissipation control sources. - -#include <dt-bindings/thermal/thermal.h> - -cpus { - /* - * Here is an example of describing a cooling device for a DVFS - * capable CPU. The CPU node describes its four OPPs. - * The cooling states possible are 0..3, and they are - * used as OPP indexes. The minimum cooling state is 0, which means - * all four OPPs can be available to the system. The maximum - * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V) - * can be available in the system. - */ - cpu0: cpu@0 { - ... - operating-points = < - /* kHz uV */ - 970000 1200000 - 792000 1100000 - 396000 950000 - 198000 850000 - >; - #cooling-cells = <2>; /* min followed by max */ - }; - ... -}; - -&i2c1 { - ... - /* - * A simple fan controller which supports 10 speeds of operation - * (represented as 0-9). - */ - fan0: fan@48 { - ... - #cooling-cells = <2>; /* min followed by max */ - }; -}; - -ocp { - ... - /* - * A simple IC with a single bandgap temperature sensor. - */ - bandgap0: bandgap@0000ed00 { - ... - #thermal-sensor-cells = <0>; - }; -}; - -thermal-zones { - cpu_thermal: cpu-thermal { - polling-delay-passive = <250>; /* milliseconds */ - polling-delay = <1000>; /* milliseconds */ - - thermal-sensors = <&bandgap0>; - - trips { - cpu_alert0: cpu-alert0 { - temperature = <90000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "active"; - }; - cpu_alert1: cpu-alert1 { - temperature = <100000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - cpu_crit: cpu-crit { - temperature = <125000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - map0 { - trip = <&cpu_alert0>; - cooling-device = <&fan0 THERMAL_NO_LIMIT 4>; - }; - map1 { - trip = <&cpu_alert1>; - cooling-device = <&fan0 5 THERMAL_NO_LIMIT>, <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; - }; - }; - }; -}; - -In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is -used to monitor the zone 'cpu-thermal' using its sole sensor. A fan -device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten -different cooling states 0-9. It is used to remove the heat out of -the thermal zone 'cpu-thermal' using its cooling states -from its minimum to 4, when it reaches trip point 'cpu_alert0' -at 90C, as an example of active cooling. The same cooling device is used at -'cpu_alert1', but from 5 to its maximum state. The cpu@0 device is also -linked to the same thermal zone, 'cpu-thermal', as a passive cooling device, -using all its cooling states at trip point 'cpu_alert1', -which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the -temperature of 125C, represented by the trip point 'cpu_crit', the silicon -is not reliable anymore. - -(b) - IC with several internal sensors - -The example below describes how to deploy several thermal zones based off a -single sensor IC, assuming it has several internal sensors. This is a common -case on SoC designs with several internal IPs that may need different thermal -requirements, and thus may have their own sensor to monitor or detect internal -hotspots in their silicon. - -#include <dt-bindings/thermal/thermal.h> - -ocp { - ... - /* - * A simple IC with several bandgap temperature sensors. - */ - bandgap0: bandgap@0000ed00 { - ... - #thermal-sensor-cells = <1>; - }; -}; - -thermal-zones { - cpu_thermal: cpu-thermal { - polling-delay-passive = <250>; /* milliseconds */ - polling-delay = <1000>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&bandgap0 0>; - - trips { - /* each zone within the SoC may have its own trips */ - cpu_alert: cpu-alert { - temperature = <100000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - cpu_crit: cpu-crit { - temperature = <125000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - /* each zone within the SoC may have its own cooling */ - ... - }; - }; - - gpu_thermal: gpu-thermal { - polling-delay-passive = <120>; /* milliseconds */ - polling-delay = <1000>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&bandgap0 1>; - - trips { - /* each zone within the SoC may have its own trips */ - gpu_alert: gpu-alert { - temperature = <90000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - gpu_crit: gpu-crit { - temperature = <105000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - /* each zone within the SoC may have its own cooling */ - ... - }; - }; - - dsp_thermal: dsp-thermal { - polling-delay-passive = <50>; /* milliseconds */ - polling-delay = <1000>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&bandgap0 2>; - - trips { - /* each zone within the SoC may have its own trips */ - dsp_alert: dsp-alert { - temperature = <90000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - dsp_crit: gpu-crit { - temperature = <135000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - /* each zone within the SoC may have its own cooling */ - ... - }; - }; -}; - -In the example above, there is one bandgap IC which has the capability to -monitor three sensors. The hardware has been designed so that sensors are -placed on different places in the DIE to monitor different temperature -hotspots: one for CPU thermal zone, one for GPU thermal zone and the -other to monitor a DSP thermal zone. - -Thus, there is a need to assign each sensor provided by the bandgap IC -to different thermal zones. This is achieved by means of using the -#thermal-sensor-cells property and using the first cell of the sensor -specifier as sensor ID. In the example, then, <bandgap 0> is used to -monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal -zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone -may be uncorrelated, having its own dT/dt requirements, trips -and cooling maps. - - -(c) - Several sensors within one single thermal zone - -The example below illustrates how to use more than one sensor within -one thermal zone. - -#include <dt-bindings/thermal/thermal.h> - -&i2c1 { - ... - /* - * A simple IC with a single temperature sensor. - */ - adc: sensor@49 { - ... - #thermal-sensor-cells = <0>; - }; -}; - -ocp { - ... - /* - * A simple IC with a single bandgap temperature sensor. - */ - bandgap0: bandgap@0000ed00 { - ... - #thermal-sensor-cells = <0>; - }; -}; - -thermal-zones { - cpu_thermal: cpu-thermal { - polling-delay-passive = <250>; /* milliseconds */ - polling-delay = <1000>; /* milliseconds */ - - thermal-sensors = <&bandgap0>, /* cpu */ - <&adc>; /* pcb north */ - - /* hotspot = 100 * bandgap - 120 * adc + 484 */ - coefficients = <100 -120 484>; - - trips { - ... - }; - - cooling-maps { - ... - }; - }; -}; - -In some cases, there is a need to use more than one sensor to extrapolate -a thermal hotspot in the silicon. The above example illustrates this situation. -For instance, it may be the case that a sensor external to CPU IP may be placed -close to CPU hotspot and together with internal CPU sensor, it is used -to determine the hotspot. Assuming this is the case for the above example, -the hypothetical extrapolation rule would be: - hotspot = 100 * bandgap - 120 * adc + 484 - -In other context, the same idea can be used to add fixed offset. For instance, -consider the hotspot extrapolation rule below: - hotspot = 1 * adc + 6000 - -In the above equation, the hotspot is always 6C higher than what is read -from the ADC sensor. The binding would be then: - thermal-sensors = <&adc>; - - /* hotspot = 1 * adc + 6000 */ - coefficients = <1 6000>; - -(d) - Board thermal - -The board thermal example below illustrates how to setup one thermal zone -with many sensors and many cooling devices. - -#include <dt-bindings/thermal/thermal.h> - -&i2c1 { - ... - /* - * An IC with several temperature sensor. - */ - adc_dummy: sensor@50 { - ... - #thermal-sensor-cells = <1>; /* sensor internal ID */ - }; -}; - -thermal-zones { - batt-thermal { - polling-delay-passive = <500>; /* milliseconds */ - polling-delay = <2500>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&adc_dummy 4>; - - trips { - ... - }; - - cooling-maps { - ... - }; - }; - - board_thermal: board-thermal { - polling-delay-passive = <1000>; /* milliseconds */ - polling-delay = <2500>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&adc_dummy 0>, /* pcb top edge */ - <&adc_dummy 1>, /* lcd */ - <&adc_dummy 2>; /* back cover */ - /* - * An array of coefficients describing the sensor - * linear relation. E.g.: - * z = c1*x1 + c2*x2 + c3*x3 - */ - coefficients = <1200 -345 890>; - - sustainable-power = <2500>; - - trips { - /* Trips are based on resulting linear equation */ - cpu_trip: cpu-trip { - temperature = <60000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - gpu_trip: gpu-trip { - temperature = <55000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - } - lcd_trip: lcp-trip { - temperature = <53000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - crit_trip: crit-trip { - temperature = <68000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - map0 { - trip = <&cpu_trip>; - cooling-device = <&cpu0 0 2>; - contribution = <55>; - }; - map1 { - trip = <&gpu_trip>; - cooling-device = <&gpu0 0 2>; - contribution = <20>; - }; - map2 { - trip = <&lcd_trip>; - cooling-device = <&lcd0 5 10>; - contribution = <15>; - }; - }; - }; -}; - -The above example is a mix of previous examples, a sensor IP with several internal -sensors used to monitor different zones, one of them is composed by several sensors and -with different cooling devices. diff --git a/Documentation/features/core/jump-labels/arch-support.txt b/Documentation/features/core/jump-labels/arch-support.txt index f8ec5c13cde4..894d9693b380 100644 --- a/Documentation/features/core/jump-labels/arch-support.txt +++ b/Documentation/features/core/jump-labels/arch-support.txt @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | ok | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | TODO | | sparc: | ok | diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt index ca6bacb1e99e..53da483c8326 100644 --- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | TODO | | sparc: | TODO | diff --git a/Documentation/features/sched/membarrier-sync-core/arch-support.txt b/Documentation/features/sched/membarrier-sync-core/arch-support.txt index 68658a6f8c5b..47e6903f47a5 100644 --- a/Documentation/features/sched/membarrier-sync-core/arch-support.txt +++ b/Documentation/features/sched/membarrier-sync-core/arch-support.txt @@ -5,7 +5,7 @@ # # Architecture requirements # -# * arm/arm64 +# * arm/arm64/powerpc # # Rely on implicit context synchronization as a result of exception return # when returning from IPI handler, and when returning to user-space. @@ -45,7 +45,7 @@ | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | - | powerpc: | TODO | + | powerpc: | ok | | riscv: | TODO | | s390: | TODO | | sh: | TODO | diff --git a/Documentation/filesystems/quota.rst b/Documentation/filesystems/quota.rst index a30cdd47c652..abd4303c546e 100644 --- a/Documentation/filesystems/quota.rst +++ b/Documentation/filesystems/quota.rst @@ -18,7 +18,7 @@ Quota limits (and amount of grace time) are set independently for each filesystem. For more details about quota design, see the documentation in quota-tools package -(http://sourceforge.net/projects/linuxquota). +(https://sourceforge.net/projects/linuxquota). Quota netlink interface ======================= @@ -31,11 +31,11 @@ the above events to userspace. There they can be captured by an application and processed accordingly. The interface uses generic netlink framework (see -http://lwn.net/Articles/208755/ and http://people.suug.ch/~tgr/libnl/ for more -details about this layer). The name of the quota generic netlink interface -is "VFS_DQUOT". Definitions of constants below are in <linux/quota.h>. -Since the quota netlink protocol is not namespace aware, quota netlink messages -are sent only in initial network namespace. +https://lwn.net/Articles/208755/ and http://www.infradead.org/~tgr/libnl/ for +more details about this layer). The name of the quota generic netlink interface +is "VFS_DQUOT". Definitions of constants below are in <linux/quota.h>. Since +the quota netlink protocol is not namespace aware, quota netlink messages are +sent only in initial network namespace. Currently, the interface supports only one message type QUOTA_NL_C_WARNING. This command is used to send a notification about any of the above mentioned diff --git a/Documentation/filesystems/udf.rst b/Documentation/filesystems/udf.rst index d9badbf285b2..f9489ddbb767 100644 --- a/Documentation/filesystems/udf.rst +++ b/Documentation/filesystems/udf.rst @@ -72,4 +72,4 @@ For the latest version and toolset see: Documentation on UDF and ECMA 167 is available FREE from: - http://www.osta.org/ - - http://www.ecma-international.org/ + - https://www.ecma-international.org/ diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 4e55aba3eb4a..96186332e5f4 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1935,6 +1935,20 @@ There are some more advanced barrier functions: relaxed I/O accessors and the Documentation/DMA-API.txt file for more information on consistent memory. + (*) pmem_wmb(); + + This is for use with persistent memory to ensure that stores for which + modifications are written to persistent storage reached a platform + durability domain. + + For example, after a non-temporal write to pmem region, we use pmem_wmb() + to ensure that stores have reached a platform durability domain. This ensures + that stores have updated persistent storage before any data access or + data transfer caused by subsequent instructions is initiated. This is + in addition to the ordering done by wmb(). + + For load from persistent memory, existing read memory barriers are sufficient + to ensure read ordering. =============================== IMPLICIT KERNEL MEMORY BARRIERS diff --git a/Documentation/powerpc/cpu_families.rst b/Documentation/powerpc/cpu_families.rst index 1e063c5440c3..9b84e045e713 100644 --- a/Documentation/powerpc/cpu_families.rst +++ b/Documentation/powerpc/cpu_families.rst @@ -9,7 +9,9 @@ and are supported by arch/powerpc. Book3S (aka sPAPR) ------------------ -- Hash MMU +- Hash MMU (except 603 and e300) +- Software loaded TLB (603 and e300) +- Selectable Software loaded TLB in addition to hash MMU (755, 7450, e600) - Mix of 32 & 64 bit:: +--------------+ +----------------+ @@ -24,9 +26,9 @@ Book3S (aka sPAPR) | | | | v v - +--------------+ +----------------+ +-------+ - | 604 | | 750 (G3) | ---> | 750CX | - +--------------+ +----------------+ +-------+ + +--------------+ +-----+ +----------------+ +-------+ + | 604 | | 755 | <--- | 750 (G3) | ---> | 750CX | + +--------------+ +-----+ +----------------+ +-------+ | | | | | | v v v diff --git a/Documentation/powerpc/mpc52xx.rst b/Documentation/powerpc/mpc52xx.rst index 8676ac63e077..30260707c3fe 100644 --- a/Documentation/powerpc/mpc52xx.rst +++ b/Documentation/powerpc/mpc52xx.rst @@ -2,7 +2,7 @@ Linux 2.6.x on MPC52xx family ============================= -For the latest info, go to http://www.246tNt.com/mpc52xx/ +For the latest info, go to https://www.246tNt.com/mpc52xx/ To compile/use : diff --git a/Documentation/powerpc/syscall64-abi.rst b/Documentation/powerpc/syscall64-abi.rst index e49f69f941b9..46caaadbb029 100644 --- a/Documentation/powerpc/syscall64-abi.rst +++ b/Documentation/powerpc/syscall64-abi.rst @@ -5,6 +5,15 @@ Power Architecture 64-bit Linux system call ABI syscall ======= +Invocation +---------- +The syscall is made with the sc instruction, and returns with execution +continuing at the instruction following the sc instruction. + +If PPC_FEATURE2_SCV appears in the AT_HWCAP2 ELF auxiliary vector, the +scv 0 instruction is an alternative that may provide better performance, +with some differences to calling sequence. + syscall calling sequence\ [1]_ matches the Power Architecture 64-bit ELF ABI specification C function calling sequence, including register preservation rules, with the following differences. @@ -12,16 +21,23 @@ rules, with the following differences. .. [1] Some syscalls (typically low-level management functions) may have different calling sequences (e.g., rt_sigreturn). -Parameters and return value ---------------------------- +Parameters +---------- The system call number is specified in r0. There is a maximum of 6 integer parameters to a syscall, passed in r3-r8. -Both a return value and a return error code are returned. cr0.SO is the return -error code, and r3 is the return value or error code. When cr0.SO is clear, -the syscall succeeded and r3 is the return value. When cr0.SO is set, the -syscall failed and r3 is the error code that generally corresponds to errno. +Return value +------------ +- For the sc instruction, both a value and an error condition are returned. + cr0.SO is the error condition, and r3 is the return value. When cr0.SO is + clear, the syscall succeeded and r3 is the return value. When cr0.SO is set, + the syscall failed and r3 is the error value (that normally corresponds to + errno). + +- For the scv 0 instruction, the return value indicates failure if it is + -4095..-1 (i.e., it is >= -MAX_ERRNO (-4095) as an unsigned comparison), + in which case the error value is the negated return value. Stack ----- @@ -34,22 +50,23 @@ Register preservation rules match the ELF ABI calling sequence with the following differences: =========== ============= ======================================== +--- For the sc instruction, differences with the ELF ABI --- r0 Volatile (System call number.) r3 Volatile (Parameter 1, and return value.) r4-r8 Volatile (Parameters 2-6.) -cr0 Volatile (cr0.SO is the return error condition) +cr0 Volatile (cr0.SO is the return error condition.) cr1, cr5-7 Nonvolatile lr Nonvolatile + +--- For the scv 0 instruction, differences with the ELF ABI --- +r0 Volatile (System call number.) +r3 Volatile (Parameter 1, and return value.) +r4-r8 Volatile (Parameters 2-6.) =========== ============= ======================================== All floating point and vector data registers as well as control and status registers are nonvolatile. -Invocation ----------- -The syscall is performed with the sc instruction, and returns with execution -continuing at the instruction following the sc instruction. - Transactional Memory -------------------- Syscall behavior can change if the processor is in transactional or suspended @@ -75,6 +92,7 @@ auxiliary vector. returning to the caller. This case is not well defined or supported, so this behavior should not be relied upon. +scv 0 syscalls will always behave as PPC_FEATURE2_HTM_NOSC. vsyscall ======== diff --git a/Documentation/scsi/advansys.rst b/Documentation/scsi/advansys.rst index e0367e179696..7ea12b100ff4 100644 --- a/Documentation/scsi/advansys.rst +++ b/Documentation/scsi/advansys.rst @@ -125,7 +125,7 @@ The following constants can be defined in the source file. c. klogd is started with the appropriate -c parameter (e.g. klogd -c 8) - This will cause printk() messages to be be displayed on the + This will cause printk() messages to be displayed on the current console. Refer to the klogd(8) and syslogd(8) man pages for details. diff --git a/Documentation/scsi/scsi-parameters.rst b/Documentation/scsi/scsi-parameters.rst index 9aba897c97ac..e5f68b431f5c 100644 --- a/Documentation/scsi/scsi-parameters.rst +++ b/Documentation/scsi/scsi-parameters.rst @@ -94,7 +94,7 @@ parameters may be changed at runtime by the command (/proc/sys/dev/scsi/logging_level). There is also a nice 'scsi_logging_level' script in the S390-tools package, available for download at - http://www-128.ibm.com/developerworks/linux/linux390/s390-tools-1.5.4.html + https://github.com/ibm-s390-tools/s390-tools/blob/master/scripts/scsi_logging_level scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are discovered. async scans them in kernel threads, diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index cdfd98155311..eb3a1316f03e 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -2160,9 +2160,12 @@ registers, find a list below: PPC KVM_REG_PPC_MMCRA 64 PPC KVM_REG_PPC_MMCR2 64 PPC KVM_REG_PPC_MMCRS 64 + PPC KVM_REG_PPC_MMCR3 64 PPC KVM_REG_PPC_SIAR 64 PPC KVM_REG_PPC_SDAR 64 PPC KVM_REG_PPC_SIER 64 + PPC KVM_REG_PPC_SIER2 64 + PPC KVM_REG_PPC_SIER3 64 PPC KVM_REG_PPC_PMC1 32 PPC KVM_REG_PPC_PMC2 32 PPC KVM_REG_PPC_PMC3 32 |