Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-11-26 14:12:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'torvalds/master' into perf/core

Browse Source 
To pick up fixes that went thru perf/urgent and now are fixed by an
upcoming patch.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This commit is contained in:
Arnaldo Carvalho de Melo 2022-03-22 17:52:10 -03:00
commit 34fe4ccb77
1717 changed files with 53103 additions and 22550 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Documentation/ABI/obsolete/procfs-i8k Normal file
View File

@ -0,0 +1,10 @@
What: /proc/i8k
Date: November 2001
KernelVersion: 2.4.14
Contact: Pali Rohár <pali@kernel.org>
Description: Legacy interface for getting/setting sensor information like
fan speed, temperature, serial number, hotkey status etc
on Dell Laptops.
Since the driver is now using the standard hwmon sysfs interface,
the procfs interface is deprecated.
Users: https://github.com/vitorafsr/i8kutils

49
Documentation/ABI/stable/sysfs-block
View File

@ -155,6 +155,55 @@ Description:
last zone of the device which may be smaller.
What: /sys/block/<disk>/queue/crypto/
Date: February 2022
Contact: linux-block@vger.kernel.org
Description:
The presence of this subdirectory of /sys/block/<disk>/queue/
indicates that the device supports inline encryption. This
subdirectory contains files which describe the inline encryption
capabilities of the device. For more information about inline
encryption, refer to Documentation/block/inline-encryption.rst.
What: /sys/block/<disk>/queue/crypto/max_dun_bits
Date: February 2022
Contact: linux-block@vger.kernel.org
Description:
[RO] This file shows the maximum length, in bits, of data unit
numbers accepted by the device in inline encryption requests.
What: /sys/block/<disk>/queue/crypto/modes/<mode>
Date: February 2022
Contact: linux-block@vger.kernel.org
Description:
[RO] For each crypto mode (i.e., encryption/decryption
algorithm) the device supports with inline encryption, a file
will exist at this location. It will contain a hexadecimal
number that is a bitmask of the supported data unit sizes, in
bytes, for that crypto mode.
Currently, the crypto modes that may be supported are:
* AES-256-XTS
* AES-128-CBC-ESSIV
* Adiantum
For example, if a device supports AES-256-XTS inline encryption
with data unit sizes of 512 and 4096 bytes, the file
/sys/block/<disk>/queue/crypto/modes/AES-256-XTS will exist and
will contain "0x1200".
What: /sys/block/<disk>/queue/crypto/num_keyslots
Date: February 2022
Contact: linux-block@vger.kernel.org
Description:
[RO] This file shows the number of keyslots the device has for
use with inline encryption.
What: /sys/block/<disk>/queue/dax
Date: June 2016
Contact: linux-block@vger.kernel.org

4
Documentation/ABI/stable/sysfs-devices-system-cpu
View File

@ -86,6 +86,10 @@ What: /sys/devices/system/cpu/cpuX/topology/die_cpus
Description: internal kernel map of CPUs within the same die.
Values: hexadecimal bitmask.
What: /sys/devices/system/cpu/cpuX/topology/ppin
Description: per-socket protected processor inventory number
Values: hexadecimal.
What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list
Description: human-readable list of CPUs within the same die.
The format is like 0-3, 8-11, 14,17.

178
Documentation/ABI/testing/debugfs-hisi-hpre
View File

@ -1,140 +1,150 @@
What: /sys/kernel/debug/hisi_hpre/<bdf>/cluster[0-3]/regs
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: Dump debug registers from the HPRE cluster.
What: /sys/kernel/debug/hisi_hpre/<bdf>/cluster[0-3]/regs
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: Dump debug registers from the HPRE cluster.
Only available for PF.
What: /sys/kernel/debug/hisi_hpre/<bdf>/cluster[0-3]/cluster_ctrl
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: Write the HPRE core selection in the cluster into this file,
What: /sys/kernel/debug/hisi_hpre/<bdf>/cluster[0-3]/cluster_ctrl
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: Write the HPRE core selection in the cluster into this file,
and then we can read the debug information of the core.
Only available for PF.
What: /sys/kernel/debug/hisi_hpre/<bdf>/rdclr_en
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: HPRE cores debug registers read clear control. 1 means enable
What: /sys/kernel/debug/hisi_hpre/<bdf>/rdclr_en
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: HPRE cores debug registers read clear control. 1 means enable
register read clear, otherwise 0. Writing to this file has no
functional effect, only enable or disable counters clear after
reading of these registers.
Only available for PF.
What: /sys/kernel/debug/hisi_hpre/<bdf>/current_qm
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: One HPRE controller has one PF and multiple VFs, each function
What: /sys/kernel/debug/hisi_hpre/<bdf>/current_qm
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: One HPRE controller has one PF and multiple VFs, each function
has a QM. Select the QM which below qm refers to.
Only available for PF.
What: /sys/kernel/debug/hisi_hpre/<bdf>/regs
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: Dump debug registers from the HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/alg_qos
Date: Jun 2021
Contact: linux-crypto@vger.kernel.org
Description: The <bdf> is related the function for PF and VF.
HPRE driver supports to configure each function's QoS, the driver
supports to write <bdf> value to alg_qos in the host. Such as
"echo <bdf> value > alg_qos". The qos value is 1~1000, means
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_hpre/<bdf>/regs
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: Dump debug registers from the HPRE.
Only available for PF.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/regs
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: Dump debug registers from the QM.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/regs
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
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>/qm/current_q
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: One QM may contain multiple queues. Select specific queue to
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/current_q
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: One QM may contain multiple queues. Select specific queue to
show its debug registers in above regs.
Only available for PF.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/clear_enable
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: QM debug registers(regs) read clear control. 1 means enable
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/clear_enable
Date: Sep 2019
Contact: linux-crypto@vger.kernel.org
Description: QM debug registers(regs) read clear control. 1 means enable
register read clear, otherwise 0.
Writing to this file has no functional effect, only enable or
disable counters clear after reading of these registers.
Only available for PF.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/err_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of invalid interrupts for
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/err_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of invalid interrupts for
QM task completion.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/aeq_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of QM async event queue interrupts.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/aeq_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of QM async event queue interrupts.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/abnormal_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of interrupts for QM abnormal event.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/abnormal_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of interrupts for QM abnormal event.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/create_qp_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of queue allocation errors.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/create_qp_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of queue allocation errors.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/mb_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of failed QM mailbox commands.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/mb_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of failed QM mailbox commands.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
Four states: initiated, started, stopped and closed.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of sent requests.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of sent requests.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/recv_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of received requests.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/recv_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of received requests.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_busy_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of requests sent
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_busy_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of requests sent
with returning busy.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_fail_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of completed but error requests.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_fail_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of completed but error requests.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/invalid_req_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of invalid requests being received.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/invalid_req_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of invalid requests being received.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/overtime_thrhld
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Set the threshold time for counting the request which is
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/overtime_thrhld
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Set the threshold time for counting the request which is
processed longer than the threshold.
0: disable(default), 1: 1 microsecond.
Available for both PF and VF, and take no other effect on HPRE.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/over_thrhld_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of time out requests.
What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/over_thrhld_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of time out requests.
Available for both PF and VF, and take no other effect on HPRE.

146
Documentation/ABI/testing/debugfs-hisi-sec
View File

@ -1,113 +1,123 @@
What: /sys/kernel/debug/hisi_sec2/<bdf>/clear_enable
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: Enabling/disabling of clear action after reading
What: /sys/kernel/debug/hisi_sec2/<bdf>/clear_enable
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: Enabling/disabling of clear action after reading
the SEC debug registers.
0: disable, 1: enable.
Only available for PF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/current_qm
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: One SEC controller has one PF and multiple VFs, each function
What: /sys/kernel/debug/hisi_sec2/<bdf>/current_qm
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: One SEC controller has one PF and multiple VFs, each function
has a QM. This file can be used to select the QM which below
qm refers to.
Only available for PF.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/qm_regs
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: Dump of QM related debug registers.
What: /sys/kernel/debug/hisi_sec2/<bdf>/alg_qos
Date: Jun 2021
Contact: linux-crypto@vger.kernel.org
Description: The <bdf> is related the function for PF and VF.
SEC driver supports to configure each function's QoS, the driver
supports to write <bdf> value to alg_qos in the host. Such as
"echo <bdf> value > alg_qos". The qos value is 1~1000, means
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>/qm/qm_regs
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: Dump of QM related debug registers.
Available for PF and VF in host. VF in guest currently only
has one debug register.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/current_q
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: One QM of SEC may contain multiple queues. Select specific
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/current_q
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: One QM of SEC may contain multiple queues. Select specific
queue to show its debug registers in above 'regs'.
Only available for PF.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/clear_enable
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: Enabling/disabling of clear action after reading
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/clear_enable
Date: Oct 2019
Contact: linux-crypto@vger.kernel.org
Description: Enabling/disabling of clear action after reading
the SEC's QM debug registers.
0: disable, 1: enable.
Only available for PF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/err_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of invalid interrupts for
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/err_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of invalid interrupts for
QM task completion.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/aeq_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of QM async event queue interrupts.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/aeq_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of QM async event queue interrupts.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/abnormal_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of interrupts for QM abnormal event.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/abnormal_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of interrupts for QM abnormal event.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/create_qp_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of queue allocation errors.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/create_qp_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of queue allocation errors.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/mb_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of failed QM mailbox commands.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/mb_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of failed QM mailbox commands.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
Four states: initiated, started, stopped and closed.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of sent requests.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of sent requests.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/recv_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of received requests.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/recv_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of received requests.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_busy_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of requests sent with returning busy.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_busy_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of requests sent with returning busy.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/err_bd_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of BD type error requests
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/err_bd_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of BD type error requests
to be received.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/invalid_req_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of invalid requests being received.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/invalid_req_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of invalid requests being received.
Available for both PF and VF, and take no other effect on SEC.
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/done_flag_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of completed but marked error requests
What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/done_flag_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of completed but marked error requests
to be received.
Available for both PF and VF, and take no other effect on SEC.

146
Documentation/ABI/testing/debugfs-hisi-zip
View File

@ -1,114 +1,124 @@
What: /sys/kernel/debug/hisi_zip/<bdf>/comp_core[01]/regs
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Dump of compression cores related debug registers.
What: /sys/kernel/debug/hisi_zip/<bdf>/comp_core[01]/regs
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Dump of compression cores related debug registers.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/decomp_core[0-5]/regs
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Dump of decompression cores related debug registers.
What: /sys/kernel/debug/hisi_zip/<bdf>/decomp_core[0-5]/regs
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Dump of decompression cores related debug registers.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/clear_enable
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Compression/decompression core debug registers read clear
What: /sys/kernel/debug/hisi_zip/<bdf>/clear_enable
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Compression/decompression core debug registers read clear
control. 1 means enable register read clear, otherwise 0.
Writing to this file has no functional effect, only enable or
disable counters clear after reading of these registers.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/current_qm
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: One ZIP controller has one PF and multiple VFs, each function
What: /sys/kernel/debug/hisi_zip/<bdf>/current_qm
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: One ZIP controller has one PF and multiple VFs, each function
has a QM. Select the QM which below qm refers to.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/regs
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Dump of QM related debug registers.
What: /sys/kernel/debug/hisi_zip/<bdf>/alg_qos
Date: Jun 2021
Contact: linux-crypto@vger.kernel.org
Description: The <bdf> is related the function for PF and VF.
ZIP driver supports to configure each function's QoS, the driver
supports to write <bdf> value to alg_qos in the host. Such as
"echo <bdf> value > alg_qos". The qos value is 1~1000, means
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>/qm/regs
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: Dump of QM related debug registers.
Available for PF and VF in host. VF in guest currently only
has one debug register.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/current_q
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: One QM may contain multiple queues. Select specific queue to
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/current_q
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: One QM may contain multiple queues. Select specific queue to
show its debug registers in above regs.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/clear_enable
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: QM debug registers(regs) read clear control. 1 means enable
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/clear_enable
Date: Nov 2018
Contact: linux-crypto@vger.kernel.org
Description: QM debug registers(regs) read clear control. 1 means enable
register read clear, otherwise 0.
Writing to this file has no functional effect, only enable or
disable counters clear after reading of these registers.
Only available for PF.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/err_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of invalid interrupts for
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/err_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of invalid interrupts for
QM task completion.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/aeq_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of QM async event queue interrupts.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/aeq_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of QM async event queue interrupts.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/abnormal_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of interrupts for QM abnormal event.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/abnormal_irq
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of interrupts for QM abnormal event.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/create_qp_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of queue allocation errors.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/create_qp_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of queue allocation errors.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/mb_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of failed QM mailbox commands.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/mb_err
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the number of failed QM mailbox commands.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
What: /sys/kernel/debug/hisi_zip/<bdf>/qm/status
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the status of the QM.
Four states: initiated, started, stopped and closed.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of sent requests.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of sent requests.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/recv_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of received requests.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/recv_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of received requests.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_busy_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of requests received
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_busy_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of requests received
with returning busy.
Available for both PF and VF, and take no other effect on ZIP.
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/err_bd_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of BD type error requests
What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/err_bd_cnt
Date: Apr 2020
Contact: linux-crypto@vger.kernel.org
Description: Dump the total number of BD type error requests
to be received.
Available for both PF and VF, and take no other effect on ZIP.

8
Documentation/ABI/testing/sysfs-class-hwmon
View File

@ -9,6 +9,14 @@ Description:
RO
What: /sys/class/hwmon/hwmonX/label
Description:
A descriptive label that allows to uniquely identify a
device within the system.
The contents of the label are free-form.
RO
What: /sys/class/hwmon/hwmonX/update_interval
Description:
The interval at which the chip will update readings.

2
Documentation/ABI/testing/sysfs-class-thermal
View File

@ -203,7 +203,7 @@ Description:
- for generic ACPI: should be "Fan", "Processor" or "LCD"
- for memory controller device on intel_menlow platform:
should be "Memory controller".
should be "Memory controller".
RO, Required

7
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -73,6 +73,7 @@ What: /sys/devices/system/cpu/cpuX/topology/core_id
/sys/devices/system/cpu/cpuX/topology/physical_package_id
/sys/devices/system/cpu/cpuX/topology/thread_siblings
/sys/devices/system/cpu/cpuX/topology/thread_siblings_list
/sys/devices/system/cpu/cpuX/topology/ppin
Date: December 2008
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: CPU topology files that describe a logical CPU's relationship
@ -103,6 +104,11 @@ Description: CPU topology files that describe a logical CPU's relationship
thread_siblings_list: human-readable list of cpuX's hardware
threads within the same core as cpuX
ppin: human-readable Protected Processor Identification
Number of the socket the cpu# belongs to. There should be
one per physical_package_id. File is readable only to
admin.
See Documentation/admin-guide/cputopology.rst for more information.
@ -662,6 +668,7 @@ Description: Preferred MTE tag checking mode
================ ==============================================
"sync" Prefer synchronous mode
"asymm" Prefer asymmetric mode
"async" Prefer asynchronous mode
================ ==============================================

54
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@ -55,8 +55,9 @@ Description: Controls the in-place-update policy.
0x04 F2FS_IPU_UTIL
0x08 F2FS_IPU_SSR_UTIL
0x10 F2FS_IPU_FSYNC
0x20 F2FS_IPU_ASYNC,
0x20 F2FS_IPU_ASYNC
0x40 F2FS_IPU_NOCACHE
0x80 F2FS_IPU_HONOR_OPU_WRITE
==== =================
Refer segment.h for details.
@ -98,6 +99,33 @@ Description: Controls the issue rate of discard commands that consist of small
checkpoint is triggered, and issued during the checkpoint.
By default, it is disabled with 0.
What: /sys/fs/f2fs/<disk>/max_discard_request
Date: December 2021
Contact: "Konstantin Vyshetsky" <vkon@google.com>
Description: Controls the number of discards a thread will issue at a time.
Higher number will allow the discard thread to finish its work
faster, at the cost of higher latency for incomming I/O.
What: /sys/fs/f2fs/<disk>/min_discard_issue_time
Date: December 2021
Contact: "Konstantin Vyshetsky" <vkon@google.com>
Description: Controls the interval the discard thread will wait between
issuing discard requests when there are discards to be issued and
no I/O aware interruptions occur.
What: /sys/fs/f2fs/<disk>/mid_discard_issue_time
Date: December 2021
Contact: "Konstantin Vyshetsky" <vkon@google.com>
Description: Controls the interval the discard thread will wait between
issuing discard requests when there are discards to be issued and
an I/O aware interruption occurs.
What: /sys/fs/f2fs/<disk>/max_discard_issue_time
Date: December 2021
Contact: "Konstantin Vyshetsky" <vkon@google.com>
Description: Controls the interval the discard thread will wait when there are
no discard operations to be issued.
What: /sys/fs/f2fs/<disk>/discard_granularity
Date: July 2017
Contact: "Chao Yu" <yuchao0@huawei.com>
@ -269,11 +297,16 @@ Description: Shows current reserved blocks in system, it may be temporarily
What: /sys/fs/f2fs/<disk>/gc_urgent
Date: August 2017
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Do background GC aggressively when set. When gc_urgent = 1,
background thread starts to do GC by given gc_urgent_sleep_time
interval. When gc_urgent = 2, F2FS will lower the bar of
checking idle in order to process outstanding discard commands
and GC a little bit aggressively. It is set to 0 by default.
Description: Do background GC aggressively when set. Set to 0 by default.
gc urgent high(1): does GC forcibly in a period of given
gc_urgent_sleep_time and ignores I/O idling check. uses greedy
GC approach and turns SSR mode on.
gc urgent low(2): lowers the bar of checking I/O idling in
order to process outstanding discard commands and GC a
little bit aggressively. uses cost benefit GC approach.
gc urgent mid(3): does GC forcibly in a period of given
gc_urgent_sleep_time and executes a mid level of I/O idling check.
uses cost benefit GC approach.
What: /sys/fs/f2fs/<disk>/gc_urgent_sleep_time
Date: August 2017
@ -430,6 +463,7 @@ Description: Show status of f2fs superblock in real time.
0x800 SBI_QUOTA_SKIP_FLUSH skip flushing quota in current CP
0x1000 SBI_QUOTA_NEED_REPAIR quota file may be corrupted
0x2000 SBI_IS_RESIZEFS resizefs is in process
0x4000 SBI_IS_FREEZING freefs is in process
====== ===================== =================================
What: /sys/fs/f2fs/<disk>/ckpt_thread_ioprio
@ -503,7 +537,7 @@ Date: July 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show how many segments have been reclaimed by GC during a specific
GC mode (0: GC normal, 1: GC idle CB, 2: GC idle greedy,
3: GC idle AT, 4: GC urgent high, 5: GC urgent low)
3: GC idle AT, 4: GC urgent high, 5: GC urgent low 6: GC urgent mid)
You can re-initialize this value to "0".
What: /sys/fs/f2fs/<disk>/gc_segment_mode
@ -540,3 +574,9 @@ Contact: "Daeho Jeong" <daehojeong@google.com>
Description: You can set the trial count limit for GC urgent high mode with this value.
If GC thread gets to the limit, the mode will turn back to GC normal mode.
By default, the value is zero, which means there is no limit like before.
What: /sys/fs/f2fs/<disk>/max_roll_forward_node_blocks
Date: January 2022
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Controls max # of node block writes to be used for roll forward
recovery. This can limit the roll forward recovery time.

2
Documentation/Makefile
View File

@ -26,7 +26,7 @@ SPHINX_CONF = conf.py
PAPER =
BUILDDIR = $(obj)/output
PDFLATEX = xelatex
LATEXOPTS = -interaction=batchmode
LATEXOPTS = -interaction=batchmode -no-shell-escape
ifeq ($(KBUILD_VERBOSE),0)
SPHINXOPTS += "-q"

28
Documentation/admin-guide/acpi/fan_performance_states.rst
View File

@ -60,3 +60,31 @@ For example::
When a given field is not populated or its value provided by the platform
firmware is invalid, the "not-defined" string is shown instead of the value.
ACPI Fan Fine Grain Control
=============================
When _FIF object specifies support for fine grain control, then fan speed
can be set from 0 to 100% with the recommended minimum "step size" via
_FSL object. User can adjust fan speed using thermal sysfs cooling device.
Here use can look at fan performance states for a reference speed (speed_rpm)
and set it by changing cooling device cur_state. If the fine grain control
is supported then user can also adjust to some other speeds which are
not defined in the performance states.
The support of fine grain control is presented via sysfs attribute
"fine_grain_control". If fine grain control is present, this attribute
will show "1" otherwise "0".
This sysfs attribute is presented in the same directory as performance states.
ACPI Fan Performance Feedback
=============================
The optional _FST object provides status information for the fan device.
This includes field to provide current fan speed in revolutions per minute
at which the fan is rotating.
This speed is presented in the sysfs using the attribute "fan_speed_rpm",
in the same directory as performance states.

20
Documentation/admin-guide/blockdev/zram.rst
View File

@ -315,8 +315,8 @@ To use the feature, admin should set up backing device via::
echo /dev/sda5 > /sys/block/zramX/backing_dev
before disksize setting. It supports only partition at this moment.
If admin wants to use incompressible page writeback, they could do via::
before disksize setting. It supports only partitions at this moment.
If admin wants to use incompressible page writeback, they could do it via::
echo huge > /sys/block/zramX/writeback
@ -341,9 +341,9 @@ Admin can request writeback of those idle pages at right timing via::
echo idle > /sys/block/zramX/writeback
With the command, zram writeback idle pages from memory to the storage.
With the command, zram will writeback idle pages from memory to the storage.
If admin want to write a specific page in zram device to backing device,
If an admin wants to write a specific page in zram device to the backing device,
they could write a page index into the interface.
echo "page_index=1251" > /sys/block/zramX/writeback
@ -354,7 +354,7 @@ to guarantee storage health for entire product life.
To overcome the concern, zram supports "writeback_limit" feature.
The "writeback_limit_enable"'s default value is 0 so that it doesn't limit
any writeback. IOW, if admin wants to apply writeback budget, he should
any writeback. IOW, if admin wants to apply writeback budget, they should
enable writeback_limit_enable via::
$ echo 1 > /sys/block/zramX/writeback_limit_enable
@ -365,7 +365,7 @@ until admin sets the budget via /sys/block/zramX/writeback_limit.
(If admin doesn't enable writeback_limit_enable, writeback_limit's value
assigned via /sys/block/zramX/writeback_limit is meaningless.)
If admin want to limit writeback as per-day 400M, he could do it
If admin wants to limit writeback as per-day 400M, they could do it
like below::
$ MB_SHIFT=20
@ -375,16 +375,16 @@ like below::
$ echo 1 > /sys/block/zram0/writeback_limit_enable
If admins want to allow further write again once the budget is exhausted,
he could do it like below::
they could do it like below::
$ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \
/sys/block/zram0/writeback_limit
If admin wants to see remaining writeback budget since last set::
If an admin wants to see the remaining writeback budget since last set::
$ cat /sys/block/zramX/writeback_limit
If admin want to disable writeback limit, he could do::
If an admin wants to disable writeback limit, they could do::
$ echo 0 > /sys/block/zramX/writeback_limit_enable
@ -393,7 +393,7 @@ system reboot, echo 1 > /sys/block/zramX/reset) so keeping how many of
writeback happened until you reset the zram to allocate extra writeback
budget in next setting is user's job.
If admin wants to measure writeback count in a certain period, he could
If admin wants to measure writeback count in a certain period, they could
know it via /sys/block/zram0/bd_stat's 3rd column.
memory tracking

1
Documentation/admin-guide/index.rst
View File

@ -35,6 +35,7 @@ problems and bugs in particular.
:maxdepth: 1
reporting-issues
reporting-regressions
security-bugs
bug-hunting
bug-bisect

6
Documentation/admin-guide/iostats.rst
View File

@ -76,7 +76,7 @@ Field 3 -- # of sectors read (unsigned long)
Field 4 -- # of milliseconds spent reading (unsigned int)
This is the total number of milliseconds spent by all reads (as
measured from __make_request() to end_that_request_last()).
measured from blk_mq_alloc_request() to __blk_mq_end_request()).
Field 5 -- # of writes completed (unsigned long)
This is the total number of writes completed successfully.
@ -89,7 +89,7 @@ Field 7 -- # of sectors written (unsigned long)
Field 8 -- # of milliseconds spent writing (unsigned int)
This is the total number of milliseconds spent by all writes (as
measured from __make_request() to end_that_request_last()).
measured from blk_mq_alloc_request() to __blk_mq_end_request()).
Field 9 -- # of I/Os currently in progress (unsigned int)
The only field that should go to zero. Incremented as requests are
@ -120,7 +120,7 @@ Field 14 -- # of sectors discarded (unsigned long)
Field 15 -- # of milliseconds spent discarding (unsigned int)
This is the total number of milliseconds spent by all discards (as
measured from __make_request() to end_that_request_last()).
measured from blk_mq_alloc_request() to __blk_mq_end_request()).
Field 16 -- # of flush requests completed
This is the total number of flush requests completed successfully.

8
Documentation/admin-guide/kdump/vmcoreinfo.rst
View File

@ -494,6 +494,14 @@ architecture which is used to lookup the page-tables for the Virtual
addresses in the higher VA range (refer to ARMv8 ARM document for
more details).
MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END
-----------------------------------------------------------------------------
Used to get the correct ranges:
MODULES_VADDR ~ MODULES_END-1 : Kernel module space.
VMALLOC_START ~ VMALLOC_END-1 : vmalloc() / ioremap() space.
VMEMMAP_START ~ VMEMMAP_END-1 : vmemmap region, used for struct page array.
arm
===

55
Documentation/admin-guide/kernel-parameters.txt
View File

@ -944,6 +944,30 @@
dump out devices still on the deferred probe list after
retrying.
dell_smm_hwmon.ignore_dmi=
[HW] Continue probing hardware even if DMI data
indicates that the driver is running on unsupported
hardware.
dell_smm_hwmon.force=
[HW] Activate driver even if SMM BIOS signature does
not match list of supported models and enable otherwise
blacklisted features.
dell_smm_hwmon.power_status=
[HW] Report power status in /proc/i8k
(disabled by default).
dell_smm_hwmon.restricted=
[HW] Allow controlling fans only if SYS_ADMIN
capability is set.
dell_smm_hwmon.fan_mult=
[HW] Factor to multiply fan speed with.
dell_smm_hwmon.fan_max=
[HW] Maximum configurable fan speed.
dfltcc= [HW,S390]
Format: { on | off | def_only | inf_only | always }
on: s390 zlib hardware support for compression on
@ -1703,17 +1727,6 @@
i810= [HW,DRM]
i8k.ignore_dmi [HW] Continue probing hardware even if DMI data
indicates that the driver is running on unsupported
hardware.
i8k.force [HW] Activate i8k driver even if SMM BIOS signature
does not match list of supported models.
i8k.power_status
[HW] Report power status in /proc/i8k
(disabled by default)
i8k.restricted [HW] Allow controlling fans only if SYS_ADMIN
capability is set.
i915.invert_brightness=
[DRM] Invert the sense of the variable that is used to
set the brightness of the panel backlight. Normally a
@ -2827,6 +2840,9 @@
For details see: Documentation/admin-guide/hw-vuln/mds.rst
mem=nn[KMG] [HEXAGON] Set the memory size.
Must be specified, otherwise memory size will be 0.
mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
Amount of memory to be used in cases as follows:
@ -2834,6 +2850,13 @@
2 when the kernel is not able to see the whole system memory;
3 memory that lies after 'mem=' boundary is excluded from
the hypervisor, then assigned to KVM guests.
4 to limit the memory available for kdump kernel.
[ARC,MICROBLAZE] - the limit applies only to low memory,
high memory is not affected.
[ARM64] - only limits memory covered by the linear
mapping. The NOMAP regions are not affected.
[X86] Work as limiting max address. Use together
with memmap= to avoid physical address space collisions.
@ -2844,6 +2867,14 @@
in above case 3, memory may need be hot added after boot
if system memory of hypervisor is not sufficient.
mem=nn[KMG]@ss[KMG]
[ARM,MIPS] - override the memory layout reported by
firmware.
Define a memory region of size nn[KMG] starting at
ss[KMG].
Multiple different regions can be specified with
multiple mem= parameters on the command line.
mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel
memory.
@ -4504,6 +4535,8 @@
(the least-favored priority). Otherwise, when
RCU_BOOST is not set, valid values are 0-99 and
the default is zero (non-realtime operation).
When RCU_NOCB_CPU is set, also adjust the
priority of NOCB callback kthreads.
rcutree.rcu_nocb_gp_stride= [KNL]
Set the number of NOCB callback kthreads in

1
Documentation/admin-guide/perf/index.rst
View File

@ -8,6 +8,7 @@ Performance monitor support
:maxdepth: 1
hisi-pmu
hisi-pcie-pmu
imx-ddr
qcom_l2_pmu
qcom_l3_pmu

26
Documentation/admin-guide/pm/amd-pstate.rst
View File

@ -369,6 +369,32 @@ governor (for the policies it is attached to), or by the ``CPUFreq`` core (for t
policies with other scaling governors).
Tracer Tool
-------------
``amd_pstate_tracer.py`` can record and parse ``amd-pstate`` trace log, then
generate performance plots. This utility can be used to debug and tune the
performance of ``amd-pstate`` driver. The tracer tool needs to import intel
pstate tracer.
Tracer tool located in ``linux/tools/power/x86/amd_pstate_tracer``. It can be
used in two ways. If trace file is available, then directly parse the file
with command ::
./amd_pstate_trace.py [-c cpus] -t <trace_file> -n <test_name>
Or generate trace file with root privilege, then parse and plot with command ::
sudo ./amd_pstate_trace.py [-c cpus] -n <test_name> -i <interval> [-m kbytes]
The test result can be found in ``results/test_name``. Following is the example
about part of the output. ::
common_cpu common_secs common_usecs min_perf des_perf max_perf freq mperf apef tsc load duration_ms sample_num elapsed_time common_comm
CPU_005 712 116384 39 49 166 0.7565 9645075 2214891 38431470 25.1 11.646 469 2.496 kworker/5:0-40
CPU_006 712 116408 39 49 166 0.6769 8950227 1839034 37192089 24.06 11.272 470 2.496 kworker/6:0-1264
Reference
===========

60
Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst Normal file
View File

@ -0,0 +1,60 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
==============================
Intel Uncore Frequency Scaling
==============================
:Copyright: |copy| 2022 Intel Corporation
:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Introduction
------------
The uncore can consume significant amount of power in Intel's Xeon servers based
on the workload characteristics. To optimize the total power and improve overall
performance, SoCs have internal algorithms for scaling uncore frequency. These
algorithms monitor workload usage of uncore and set a desirable frequency.
It is possible that users have different expectations of uncore performance and
want to have control over it. The objective is similar to allowing users to set
the scaling min/max frequencies via cpufreq sysfs to improve CPU performance.
Users may have some latency sensitive workloads where they do not want any
change to uncore frequency. Also, users may have workloads which require
different core and uncore performance at distinct phases and they may want to
use both cpufreq and the uncore scaling interface to distribute power and
improve overall performance.
Sysfs Interface
---------------
To control uncore frequency, a sysfs interface is provided in the directory:
`/sys/devices/system/cpu/intel_uncore_frequency/`.
There is one directory for each package and die combination as the scope of
uncore scaling control is per die in multiple die/package SoCs or per
package for single die per package SoCs. The name represents the
scope of control. For example: 'package_00_die_00' is for package id 0 and
die 0.
Each package_*_die_* contains the following attributes:
``initial_max_freq_khz``
Out of reset, this attribute represent the maximum possible frequency.
This is a read-only attribute. If users adjust max_freq_khz,
they can always go back to maximum using the value from this attribute.
``initial_min_freq_khz``
Out of reset, this attribute represent the minimum possible frequency.
This is a read-only attribute. If users adjust min_freq_khz,
they can always go back to minimum using the value from this attribute.
``max_freq_khz``
This attribute is used to set the maximum uncore frequency.
``min_freq_khz``
This attribute is used to set the minimum uncore frequency.
``current_freq_khz``
This attribute is used to get the current uncore frequency.

1
Documentation/admin-guide/pm/working-state.rst
View File

@ -15,3 +15,4 @@ Working-State Power Management
cpufreq_drivers
intel_epb
intel-speed-select
intel_uncore_frequency_scaling

73
Documentation/admin-guide/reporting-issues.rst
View File

@ -1,14 +1,5 @@
.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
..
If you want to distribute this text under CC-BY-4.0 only, please use 'The
Linux kernel developers' for author attribution and link this as source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
..
Note: Only the content of this RST file as found in the Linux kernel sources
is available under CC-BY-4.0, as versions of this text that were processed
(for example by the kernel's build system) might contain content taken from
files which use a more restrictive license.
.. See the bottom of this file for additional redistribution information.
Reporting issues
++++++++++++++++
@ -395,22 +386,16 @@ fixed as soon as possible, hence there are 'issues of high priority' that get
handled slightly differently in the reporting process. Three type of cases
qualify: regressions, security issues, and really severe problems.
You deal with a 'regression' if something that worked with an older version of
the Linux kernel does not work with a newer one or somehow works worse with it.
It thus is a regression when a WiFi driver that did a fine job with Linux 5.7
somehow misbehaves with 5.8 or doesn't work at all. It's also a regression if
an application shows erratic behavior with a newer kernel, which might happen
due to incompatible changes in the interface between the kernel and the
userland (like procfs and sysfs). Significantly reduced performance or
increased power consumption also qualify as regression. But keep in mind: the
new kernel needs to be built with a configuration that is similar to the one
from the old kernel (see below how to achieve that). That's because the kernel
developers sometimes can not avoid incompatibilities when implementing new
features; but to avoid regressions such features have to be enabled explicitly
during build time configuration.
You deal with a regression if some application or practical use case running
fine with one Linux kernel works worse or not at all with a newer version
compiled using a similar configuration. The document
Documentation/admin-guide/reporting-regressions.rst explains this in more
detail. It also provides a good deal of other information about regressions you
might want to be aware of; it for example explains how to add your issue to the
list of tracked regressions, to ensure it won't fall through the cracks.
What qualifies as security issue is left to your judgment. Consider reading
'Documentation/admin-guide/security-bugs.rst' before proceeding, as it
Documentation/admin-guide/security-bugs.rst before proceeding, as it
provides additional details how to best handle security issues.
An issue is a 'really severe problem' when something totally unacceptably bad
@ -517,7 +502,7 @@ line starting with 'CPU:'. It should end with 'Not tainted' if the kernel was
not tainted when it noticed the problem; it was tainted if you see 'Tainted:'
followed by a few spaces and some letters.
If your kernel is tainted, study 'Documentation/admin-guide/tainted-kernels.rst'
If your kernel is tainted, study Documentation/admin-guide/tainted-kernels.rst
to find out why. Try to eliminate the reason. Often it's caused by one these
three things:
@ -1043,7 +1028,7 @@ down the culprit, as maintainers often won't have the time or setup at hand to
reproduce it themselves.
To find the change there is a process called 'bisection' which the document
'Documentation/admin-guide/bug-bisect.rst' describes in detail. That process
Documentation/admin-guide/bug-bisect.rst describes in detail. That process
will often require you to build about ten to twenty kernel images, trying to
reproduce the issue with each of them before building the next. Yes, that takes
some time, but don't worry, it works a lot quicker than most people assume.
@ -1073,10 +1058,11 @@ When dealing with regressions make sure the issue you face is really caused by
the kernel and not by something else, as outlined above already.
In the whole process keep in mind: an issue only qualifies as regression if the
older and the newer kernel got built with a similar configuration. The best way
to archive this: copy the configuration file (``.config``) from the old working
kernel freshly to each newer kernel version you try. Afterwards run ``make
olddefconfig`` to adjust it for the needs of the new version.
older and the newer kernel got built with a similar configuration. This can be
achieved by using ``make olddefconfig``, as explained in more detail by
Documentation/admin-guide/reporting-regressions.rst; that document also
provides a good deal of other information about regressions you might want to be
aware of.
Write and send the report
@ -1283,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward
the report's text to these addresses; but on top of it put a small note where
you mention that you filed it with a link to the ticket.
See 'Documentation/admin-guide/security-bugs.rst' for more information.
See Documentation/admin-guide/security-bugs.rst for more information.
Duties after the report went out
@ -1571,7 +1557,7 @@ Once your report is out your might get asked to do a proper one, as it allows to
pinpoint the exact change that causes the issue (which then can easily get
reverted to fix the issue quickly). Hence consider to do a proper bisection
right away if time permits. See the section 'Special care for regressions' and
the document 'Documentation/admin-guide/bug-bisect.rst' for details how to
the document Documentation/admin-guide/bug-bisect.rst for details how to
perform one. In case of a successful bisection add the author of the culprit to
the recipients; also CC everyone in the signed-off-by chain, which you find at
the end of its commit message.
@ -1594,7 +1580,7 @@ Some fixes are too complex
Even small and seemingly obvious code-changes sometimes introduce new and
totally unexpected problems. The maintainers of the stable and longterm kernels
are very aware of that and thus only apply changes to these kernels that are
within rules outlined in 'Documentation/process/stable-kernel-rules.rst'.
within rules outlined in Documentation/process/stable-kernel-rules.rst.
Complex or risky changes for example do not qualify and thus only get applied
to mainline. Other fixes are easy to get backported to the newest stable and
@ -1756,10 +1742,23 @@ art will lay some groundwork to improve the situation over time.
..
This text is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If you
spot a typo or small mistake, feel free to let him know directly and he'll
fix it. You are free to do the same in a mostly informal way if you want
to contribute changes to the text, but for copyright reasons please CC
end-of-content
..
This document is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If
you spot a typo or small mistake, feel free to let him know directly and
he'll fix it. You are free to do the same in a mostly informal way if you
want to contribute changes to the text, but for copyright reasons please CC
linux-doc@vger.kernel.org and "sign-off" your contribution as
Documentation/process/submitting-patches.rst outlines in the section "Sign
your work - the Developer's Certificate of Origin".
..
This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
of the file. If you want to distribute this text under CC-BY-4.0 only,
please use "The Linux kernel developers" for author attribution and link
this as source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
..
Note: Only the content of this RST file as found in the Linux kernel sources
is available under CC-BY-4.0, as versions of this text that were processed
(for example by the kernel's build system) might contain content taken from
files which use a more restrictive license.

451
Documentation/admin-guide/reporting-regressions.rst Normal file
View File

@ -0,0 +1,451 @@
.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
.. [see the bottom of this file for redistribution information]
Reporting regressions
+++++++++++++++++++++
"*We don't cause regressions*" is the first rule of Linux kernel development;
Linux founder and lead developer Linus Torvalds established it himself and
ensures it's obeyed.
This document describes what the rule means for users and how the Linux kernel's
development model ensures to address all reported regressions; aspects relevant
for kernel developers are left to Documentation/process/handling-regressions.rst.
The important bits (aka "TL;DR")
================================
#. It's a regression if something running fine with one Linux kernel works worse
or not at all with a newer version. Note, the newer kernel has to be compiled
using a similar configuration; the detailed explanations below describes this
and other fine print in more detail.
#. Report your issue as outlined in Documentation/admin-guide/reporting-issues.rst,
it already covers all aspects important for regressions and repeated
below for convenience. Two of them are important: start your report's subject
with "[REGRESSION]" and CC or forward it to `the regression mailing list
<https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev).
#. Optional, but recommended: when sending or forwarding your report, make the
Linux kernel regression tracking bot "regzbot" track the issue by specifying
when the regression started like this::
#regzbot introduced v5.13..v5.14-rc1
All the details on Linux kernel regressions relevant for users
==============================================================
The important basics
--------------------
What is a "regression" and what is the "no regressions rule"?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's a regression if some application or practical use case running fine with
one Linux kernel works worse or not at all with a newer version compiled using a
similar configuration. The "no regressions rule" forbids this to take place; if
it happens by accident, developers that caused it are expected to quickly fix
the issue.
It thus is a regression when a WiFi driver from Linux 5.13 works fine, but with
5.14 doesn't work at all, works significantly slower, or misbehaves somehow.
It's also a regression if a perfectly working application suddenly shows erratic
behavior with a newer kernel version; such issues can be caused by changes in
procfs, sysfs, or one of the many other interfaces Linux provides to userland
software. But keep in mind, as mentioned earlier: 5.14 in this example needs to
be built from a configuration similar to the one from 5.13. This can be achieved
using ``make olddefconfig``, as explained in more detail below.
Note the "practical use case" in the first sentence of this section: developers
despite the "no regressions" rule are free to change any aspect of the kernel
and even APIs or ABIs to userland, as long as no existing application or use
case breaks.
Also be aware the "no regressions" rule covers only interfaces the kernel
provides to the userland. It thus does not apply to kernel-internal interfaces
like the module API, which some externally developed drivers use to hook into
the kernel.
How do I report a regression?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Just report the issue as outlined in
Documentation/admin-guide/reporting-issues.rst, it already describes the
important points. The following aspects outlined there are especially relevant
for regressions:
* When checking for existing reports to join, also search the `archives of the
Linux regressions mailing list <https://lore.kernel.org/regressions/>`_ and
`regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_.
* Start your report's subject with "[REGRESSION]".
* In your report, clearly mention the last kernel version that worked fine and
the first broken one. Ideally try to find the exact change causing the
regression using a bisection, as explained below in more detail.
* Remember to let the Linux regressions mailing list
(regressions@lists.linux.dev) know about your report:
* If you report the regression by mail, CC the regressions list.
* If you report your regression to some bug tracker, forward the submitted
report by mail to the regressions list while CCing the maintainer and the
mailing list for the subsystem in question.
If it's a regression within a stable or longterm series (e.g.
v5.15.3..v5.15.5), remember to CC the `Linux stable mailing list
<https://lore.kernel.org/stable/>`_ (stable@vger.kernel.org).
In case you performed a successful bisection, add everyone to the CC the
culprit's commit message mentions in lines starting with "Signed-off-by:".
When CCing for forwarding your report to the list, consider directly telling the
aforementioned Linux kernel regression tracking bot about your report. To do
that, include a paragraph like this in your mail::
#regzbot introduced: v5.13..v5.14-rc1
Regzbot will then consider your mail a report for a regression introduced in the
specified version range. In above case Linux v5.13 still worked fine and Linux
v5.14-rc1 was the first version where you encountered the issue. If you
performed a bisection to find the commit that caused the regression, specify the
culprit's commit-id instead::
#regzbot introduced: 1f2e3d4c5d
Placing such a "regzbot command" is in your interest, as it will ensure the
report won't fall through the cracks unnoticed. If you omit this, the Linux
kernel's regressions tracker will take care of telling regzbot about your
regression, as long as you send a copy to the regressions mailing lists. But the
regression tracker is just one human which sometimes has to rest or occasionally
might even enjoy some time away from computers (as crazy as that might sound).
Relying on this person thus will result in an unnecessary delay before the
regressions becomes mentioned `on the list of tracked and unresolved Linux
kernel regressions <https://linux-regtracking.leemhuis.info/regzbot/>`_ and the
weekly regression reports sent by regzbot. Such delays can result in Linus
Torvalds being unaware of important regressions when deciding between "continue
development or call this finished and release the final?".
Are really all regressions fixed?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nearly all of them are, as long as the change causing the regression (the
"culprit commit") is reliably identified. Some regressions can be fixed without
this, but often it's required.
Who needs to find the root cause of a regression?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Developers of the affected code area should try to locate the culprit on their
own. But for them that's often impossible to do with reasonable effort, as quite
a lot of issues only occur in a particular environment outside the developer's
reach -- for example, a specific hardware platform, firmware, Linux distro,
system's configuration, or application. That's why in the end it's often up to
the reporter to locate the culprit commit; sometimes users might even need to
run additional tests afterwards to pinpoint the exact root cause. Developers
should offer advice and reasonably help where they can, to make this process
relatively easy and achievable for typical users.
How can I find the culprit?
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Perform a bisection, as roughly outlined in
Documentation/admin-guide/reporting-issues.rst and described in more detail by
Documentation/admin-guide/bug-bisect.rst. It might sound like a lot of work, but
in many cases finds the culprit relatively quickly. If it's hard or
time-consuming to reliably reproduce the issue, consider teaming up with other
affected users to narrow down the search range together.
Who can I ask for advice when it comes to regressions?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Send a mail to the regressions mailing list (regressions@lists.linux.dev) while
CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the
issue might better be dealt with in private, feel free to omit the list.
Additional details about regressions
------------------------------------
What is the goal of the "no regressions rule"?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Users should feel safe when updating kernel versions and not have to worry
something might break. This is in the interest of the kernel developers to make
updating attractive: they don't want users to stay on stable or longterm Linux
series that are either abandoned or more than one and a half years old. That's
in everybody's interest, as `those series might have known bugs, security
issues, or other problematic aspects already fixed in later versions
<http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_.
Additionally, the kernel developers want to make it simple and appealing for
users to test the latest pre-release or regular release. That's also in
everybody's interest, as it's a lot easier to track down and fix problems, if
they are reported shortly after being introduced.
Is the "no regressions" rule really adhered in practice?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's taken really seriously, as can be seen by many mailing list posts from
Linux creator and lead developer Linus Torvalds, some of which are quoted in
Documentation/process/handling-regressions.rst.
Exceptions to this rule are extremely rare; in the past developers almost always
turned out to be wrong when they assumed a particular situation was warranting
an exception.
Who ensures the "no regressions" is actually followed?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The subsystem maintainers should take care of that, which are watched and
supported by the tree maintainers -- e.g. Linus Torvalds for mainline and
Greg Kroah-Hartman et al. for various stable/longterm series.
All of them are helped by people trying to ensure no regression report falls
through the cracks. One of them is Thorsten Leemhuis, who's currently acting as
the Linux kernel's "regressions tracker"; to facilitate this work he relies on
regzbot, the Linux kernel regression tracking bot. That's why you want to bring
your report on the radar of these people by CCing or forwarding each report to
the regressions mailing list, ideally with a "regzbot command" in your mail to
get it tracked immediately.
How quickly are regressions normally fixed?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Developers should fix any reported regression as quickly as possible, to provide
affected users with a solution in a timely manner and prevent more users from
running into the issue; nevertheless developers need to take enough time and
care to ensure regression fixes do not cause additional damage.
The answer thus depends on various factors like the impact of a regression, its
age, or the Linux series in which it occurs. In the end though, most regressions
should be fixed within two weeks.
Is it a regression, if the issue can be avoided by updating some software?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Almost always: yes. If a developer tells you otherwise, ask the regression
tracker for advice as outlined above.
Is it a regression, if a newer kernel works slower or consumes more energy?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yes, but the difference has to be significant. A five percent slow-down in a
micro-benchmark thus is unlikely to qualify as regression, unless it also
influences the results of a broad benchmark by more than one percent. If in
doubt, ask for advice.
Is it a regression, if an external kernel module breaks when updating Linux?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No, as the "no regression" rule is about interfaces and services the Linux
kernel provides to the userland. It thus does not cover building or running
externally developed kernel modules, as they run in kernel-space and hook into
the kernel using internal interfaces occasionally changed.
How are regressions handled that are caused by security fixes?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In extremely rare situations security issues can't be fixed without causing
regressions; those fixes are given way, as they are the lesser evil in the end.
Luckily this middling almost always can be avoided, as key developers for the
affected area and often Linus Torvalds himself try very hard to fix security
issues without causing regressions.
If you nevertheless face such a case, check the mailing list archives if people
tried their best to avoid the regression. If not, report it; if in doubt, ask
for advice as outlined above.
What happens if fixing a regression is impossible without causing another?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sadly these things happen, but luckily not very often; if they occur, expert
developers of the affected code area should look into the issue to find a fix
that avoids regressions or at least their impact. If you run into such a
situation, do what was outlined already for regressions caused by security
fixes: check earlier discussions if people already tried their best and ask for
advice if in doubt.
A quick note while at it: these situations could be avoided, if people would
regularly give mainline pre-releases (say v5.15-rc1 or -rc3) from each
development cycle a test run. This is best explained by imagining a change
integrated between Linux v5.14 and v5.15-rc1 which causes a regression, but at
the same time is a hard requirement for some other improvement applied for
5.15-rc1. All these changes often can simply be reverted and the regression thus
solved, if someone finds and reports it before 5.15 is released. A few days or
weeks later this solution can become impossible, as some software might have
started to rely on aspects introduced by one of the follow-up changes: reverting
all changes would then cause a regression for users of said software and thus is
out of the question.
Is it a regression, if some feature I relied on was removed months ago?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is, but often it's hard to fix such regressions due to the aspects outlined
in the previous section. It hence needs to be dealt with on a case-by-case
basis. This is another reason why it's in everybody's interest to regularly test
mainline pre-releases.
Does the "no regression" rule apply if I seem to be the only affected person?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It does, but only for practical usage: the Linux developers want to be free to
remove support for hardware only to be found in attics and museums anymore.
Note, sometimes regressions can't be avoided to make progress -- and the latter
is needed to prevent Linux from stagnation. Hence, if only very few users seem
to be affected by a regression, it for the greater good might be in their and
everyone else's interest to lettings things pass. Especially if there is an
easy way to circumvent the regression somehow, for example by updating some
software or using a kernel parameter created just for this purpose.
Does the regression rule apply for code in the staging tree as well?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Not according to the `help text for the configuration option covering all
staging code <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_,
which since its early days states::
Please note that these drivers are under heavy development, may or
may not work, and may contain userspace interfaces that most likely
will be changed in the near future.
The staging developers nevertheless often adhere to the "no regressions" rule,
but sometimes bend it to make progress. That's for example why some users had to
deal with (often negligible) regressions when a WiFi driver from the staging
tree was replaced by a totally different one written from scratch.
Why do later versions have to be "compiled with a similar configuration"?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Because the Linux kernel developers sometimes integrate changes known to cause
regressions, but make them optional and disable them in the kernel's default
configuration. This trick allows progress, as the "no regressions" rule
otherwise would lead to stagnation.
Consider for example a new security feature blocking access to some kernel
interfaces often abused by malware, which at the same time are required to run a
few rarely used applications. The outlined approach makes both camps happy:
people using these applications can leave the new security feature off, while
everyone else can enable it without running into trouble.
How to create a configuration similar to the one of an older kernel?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Start your machine with a known-good kernel and configure the newer Linux
version with ``make olddefconfig``. This makes the kernel's build scripts pick
up the configuration file (the ".config" file) from the running kernel as base
for the new one you are about to compile; afterwards they set all new
configuration options to their default value, which should disable new features
that might cause regressions.
Can I report a regression I found with pre-compiled vanilla kernels?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You need to ensure the newer kernel was compiled with a similar configuration
file as the older one (see above), as those that built them might have enabled
some known-to-be incompatible feature for the newer kernel. If in doubt, report
the matter to the kernel's provider and ask for advice.
More about regression tracking with "regzbot"
---------------------------------------------
What is regression tracking and why should I care about it?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rules like "no regressions" need someone to ensure they are followed, otherwise
they are broken either accidentally or on purpose. History has shown this to be
true for Linux kernel development as well. That's why Thorsten Leemhuis, the
Linux Kernel's regression tracker, and some people try to ensure all regression
are fixed by keeping an eye on them until they are resolved. Neither of them are
paid for this, that's why the work is done on a best effort basis.
Why and how are Linux kernel regressions tracked using a bot?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tracking regressions completely manually has proven to be quite hard due to the
distributed and loosely structured nature of Linux kernel development process.
That's why the Linux kernel's regression tracker developed regzbot to facilitate
the work, with the long term goal to automate regression tracking as much as
possible for everyone involved.
Regzbot works by watching for replies to reports of tracked regressions.
Additionally, it's looking out for posted or committed patches referencing such
reports with "Link:" tags; replies to such patch postings are tracked as well.
Combined this data provides good insights into the current state of the fixing
process.
How to see which regressions regzbot tracks currently?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Check out `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_.
What kind of issues are supposed to be tracked by regzbot?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The bot is meant to track regressions, hence please don't involve regzbot for
regular issues. But it's okay for the Linux kernel's regression tracker if you
involve regzbot to track severe issues, like reports about hangs, corrupted
data, or internal errors (Panic, Oops, BUG(), warning, ...).
How to change aspects of a tracked regression?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By using a 'regzbot command' in a direct or indirect reply to the mail with the
report. The easiest way to do that: find the report in your "Sent" folder or the
mailing list archive and reply to it using your mailer's "Reply-all" function.
In that mail, use one of the following commands in a stand-alone paragraph (IOW:
use blank lines to separate one or multiple of these commands from the rest of
the mail's text).
* Update when the regression started to happen, for example after performing a
bisection::
#regzbot introduced: 1f2e3d4c5d
* Set or update the title::
#regzbot title: foo
* Monitor a discussion or bugzilla.kernel.org ticket where additions aspects of
the issue or a fix are discussed:::
#regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
#regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
* Point to a place with further details of interest, like a mailing list post
or a ticket in a bug tracker that are slightly related, but about a different
topic::
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
* Mark a regression as invalid::
#regzbot invalid: wasn't a regression, problem has always existed
Regzbot supports a few other commands primarily used by developers or people
tracking regressions. They and more details about the aforementioned regzbot
commands can be found in the `getting started guide
<https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_ and
the `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
for regzbot.
..
end-of-content
..
This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
of the file. If you want to distribute this text under CC-BY-4.0 only,
please use "The Linux kernel developers" for author attribution and link
this as source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-regressions.rst
..
Note: Only the content of this RST file as found in the Linux kernel sources
is available under CC-BY-4.0, as versions of this text that were processed
(for example by the kernel's build system) might contain content taken from
files which use a more restrictive license.

16
Documentation/admin-guide/sysctl/kernel.rst
View File

@ -1029,23 +1029,17 @@ This is a directory, with the following entries:
* ``poolsize``: the entropy pool size, in bits;
* ``urandom_min_reseed_secs``: obsolete (used to determine the minimum
number of seconds between urandom pool reseeding).
number of seconds between urandom pool reseeding). This file is
writable for compatibility purposes, but writing to it has no effect
on any RNG behavior.
* ``uuid``: a UUID generated every time this is retrieved (this can
thus be used to generate UUIDs at will);
* ``write_wakeup_threshold``: when the entropy count drops below this
(as a number of bits), processes waiting to write to ``/dev/random``
are woken up.
If ``drivers/char/random.c`` is built with ``ADD_INTERRUPT_BENCH``
defined, these additional entries are present:
* ``add_interrupt_avg_cycles``: the average number of cycles between
interrupts used to feed the pool;
* ``add_interrupt_avg_deviation``: the standard deviation seen on the
number of cycles between interrupts used to feed the pool.
are woken up. This file is writable for compatibility purposes, but
writing to it has no effect on any RNG behavior.
randomize_va_space

10
Documentation/arm64/booting.rst
View File

@ -10,9 +10,9 @@ This document is based on the ARM booting document by Russell King and
is relevant to all public releases of the AArch64 Linux kernel.
The AArch64 exception model is made up of a number of exception levels
(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure
counterpart. EL2 is the hypervisor level and exists only in non-secure
mode. EL3 is the highest priority level and exists only in secure mode.
(EL0 - EL3), with EL0, EL1 and EL2 having a secure and a non-secure
counterpart. EL2 is the hypervisor level, EL3 is the highest priority
level and exists only in secure mode. Both are architecturally optional.
For the purposes of this document, we will use the term `boot loader`
simply to define all software that executes on the CPU(s) before control
@ -167,8 +167,8 @@ Before jumping into the kernel, the following conditions must be met:
All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
IRQ and FIQ).
The CPU must be in either EL2 (RECOMMENDED in order to have access to
the virtualisation extensions) or non-secure EL1.
The CPU must be in non-secure state, either in EL2 (RECOMMENDED in order
to have access to the virtualisation extensions), or in EL1.
- Caches, MMUs

5
Documentation/arm64/elf_hwcaps.rst
View File

@ -259,6 +259,11 @@ HWCAP2_RPRES
Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
HWCAP2_MTE3
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described
by Documentation/arm64/memory-tagging-extension.rst.
4. Unused AT_HWCAP bits
-----------------------

54
Documentation/arm64/memory-tagging-extension.rst
View File

@ -76,6 +76,9 @@ configurable behaviours:
with ``.si_code = SEGV_MTEAERR`` and ``.si_addr = 0`` (the faulting
address is unknown).
- *Asymmetric* - Reads are handled as for synchronous mode while writes
are handled as for asynchronous mode.
The user can select the above modes, per thread, using the
``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where ``flags``
contains any number of the following values in the ``PR_MTE_TCF_MASK``
@ -91,8 +94,9 @@ mode is specified, the program will run in that mode. If multiple
modes are specified, the mode is selected as described in the "Per-CPU
preferred tag checking modes" section below.
The current tag check fault mode can be read using the
``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call.
The current tag check fault configuration can be read using the
``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call. If
multiple modes were requested then all will be reported.
Tag checking can also be disabled for a user thread by setting the
``PSTATE.TCO`` bit with ``MSR TCO, #1``.
@ -139,18 +143,25 @@ tag checking mode as the CPU's preferred tag checking mode.
The preferred tag checking mode for each CPU is controlled by
``/sys/devices/system/cpu/cpu<N>/mte_tcf_preferred``, to which a
privileged user may write the value ``async`` or ``sync``. The default
preferred mode for each CPU is ``async``.
privileged user may write the value ``async``, ``sync`` or ``asymm``. The
default preferred mode for each CPU is ``async``.
To allow a program to potentially run in the CPU's preferred tag
checking mode, the user program may set multiple tag check fault mode
bits in the ``flags`` argument to the ``prctl(PR_SET_TAGGED_ADDR_CTRL,
flags, 0, 0, 0)`` system call. If the CPU's preferred tag checking
mode is in the task's set of provided tag checking modes (this will
always be the case at present because the kernel only supports two
tag checking modes, but future kernels may support more modes), that
mode will be selected. Otherwise, one of the modes in the task's mode
set will be selected in a currently unspecified manner.
flags, 0, 0, 0)`` system call. If both synchronous and asynchronous
modes are requested then asymmetric mode may also be selected by the
kernel. If the CPU's preferred tag checking mode is in the task's set
of provided tag checking modes, that mode will be selected. Otherwise,
one of the modes in the task's mode will be selected by the kernel
from the task's mode set using the preference order:
1. Asynchronous
2. Asymmetric
3. Synchronous
Note that there is no way for userspace to request multiple modes and
also disable asymmetric mode.
Initial process state
---------------------
@ -213,6 +224,29 @@ address ABI control and MTE configuration of a process as per the
Documentation/arm64/tagged-address-abi.rst and above. The corresponding
``regset`` is 1 element of 8 bytes (``sizeof(long))``).
Core dump support
-----------------
The allocation tags for user memory mapped with ``PROT_MTE`` are dumped
in the core file as additional ``PT_ARM_MEMTAG_MTE`` segments. The
program header for such segment is defined as:
:``p_type``: ``PT_ARM_MEMTAG_MTE``
:``p_flags``: 0
:``p_offset``: segment file offset
:``p_vaddr``: segment virtual address, same as the corresponding
``PT_LOAD`` segment
:``p_paddr``: 0
:``p_filesz``: segment size in file, calculated as ``p_mem_sz / 32``
(two 4-bit tags cover 32 bytes of memory)
:``p_memsz``: segment size in memory, same as the corresponding
``PT_LOAD`` segment
:``p_align``: 0
The tags are stored in the core file at ``p_offset`` as two 4-bit tags
in a byte. With the tag granule of 16 bytes, a 4K page requires 128
bytes in the core file.
Example of correct usage
========================

2
Documentation/arm64/silicon-errata.rst
View File

@ -136,7 +136,7 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
| Cavium | ThunderX GICv3 | #23154,38545 | CAVIUM_ERRATUM_23154 |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX GICv3 | #38539 | N/A |
+----------------+-----------------+-----------------+-----------------------------+

11
Documentation/asm-annotations.rst
View File

@ -130,14 +130,13 @@ denoting a range of code via ``SYM_*_START/END`` annotations.
In fact, this kind of annotation corresponds to the now deprecated ``ENTRY``
and ``ENDPROC`` macros.
* ``SYM_FUNC_START_ALIAS`` and ``SYM_FUNC_START_LOCAL_ALIAS`` serve for those
who decided to have two or more names for one function. The typical use is::
* ``SYM_FUNC_ALIAS``, ``SYM_FUNC_ALIAS_LOCAL``, and ``SYM_FUNC_ALIAS_WEAK`` can
be used to define multiple names for a function. The typical use is::
SYM_FUNC_START_ALIAS(__memset)
SYM_FUNC_START(memset)
SYM_FUNC_START(__memset)
... asm insns ...
SYM_FUNC_END(memset)
SYM_FUNC_END_ALIAS(__memset)
SYN_FUNC_END(__memset)
SYM_FUNC_ALIAS(memset, __memset)
In this example, one can call ``__memset`` or ``memset`` with the same
result, except the debug information for the instructions is generated to

1164
Documentation/block/biodoc.rst
View File

File diff suppressed because it is too large Load Diff

2
Documentation/block/capability.rst
View File

@ -7,4 +7,4 @@ This file documents the sysfs file ``block/<disk>/capability``.
``capability`` is a bitfield, printed in hexadecimal, indicating which
capabilities a specific block device supports:
.. kernel-doc:: include/linux/genhd.h
.. kernel-doc:: include/linux/blkdev.h

1
Documentation/block/index.rst
View File

@ -8,7 +8,6 @@ Block
:maxdepth: 1
bfq-iosched
biodoc
biovecs
blk-mq
capability

4
Documentation/cdrom/packet-writing.rst
View File

@ -11,7 +11,7 @@ Getting started quick
- Compile and install kernel and modules, reboot.
- You need the udftools package (pktsetup, mkudffs, cdrwtool).
Download from http://sourceforge.net/projects/linux-udf/
Download from https://github.com/pali/udftools
- Grab a new CD-RW disc and format it (assuming CD-RW is hdc, substitute
as appropriate)::
@ -102,7 +102,7 @@ Using the pktcdvd sysfs interface
Since Linux 2.6.20, the pktcdvd module has a sysfs interface
and can be controlled by it. For example the "pktcdvd" tool uses
this interface. (see http://tom.ist-im-web.de/download/pktcdvd )
this interface. (see http://tom.ist-im-web.de/linux/software/pktcdvd )
"pktcdvd" works similar to "pktsetup", e.g.::

131
Documentation/conf.py
View File

@ -409,135 +409,25 @@ latex_elements = {
# Additional stuff for the LaTeX preamble.
'preamble': '''
% Prevent column squeezing of tabulary.
\\setlength{\\tymin}{20em}
% Use some font with UTF-8 support with XeLaTeX
\\usepackage{fontspec}
\\setsansfont{DejaVu Sans}
\\setromanfont{DejaVu Serif}
\\setmonofont{DejaVu Sans Mono}
% Adjust \\headheight for fancyhdr
\\addtolength{\\headheight}{1.6pt}
\\addtolength{\\topmargin}{-1.6pt}
''',
''',
}
# Translations have Asian (CJK) characters which are only displayed if
# xeCJK is used
latex_elements['preamble'] += '''
\\IfFontExistsTF{Noto Sans CJK SC}{
% This is needed for translations
\\usepackage{xeCJK}
\\IfFontExistsTF{Noto Serif CJK SC}{
\\setCJKmainfont{Noto Serif CJK SC}[AutoFakeSlant]
}{
\\setCJKmainfont{Noto Sans CJK SC}[AutoFakeSlant]
}
\\setCJKsansfont{Noto Sans CJK SC}[AutoFakeSlant]
\\setCJKmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant]
% CJK Language-specific font choices
\\IfFontExistsTF{Noto Serif CJK SC}{
\\newCJKfontfamily[SCmain]\\scmain{Noto Serif CJK SC}[AutoFakeSlant]
\\newCJKfontfamily[SCserif]\\scserif{Noto Serif CJK SC}[AutoFakeSlant]
}{
\\newCJKfontfamily[SCmain]\\scmain{Noto Sans CJK SC}[AutoFakeSlant]
\\newCJKfontfamily[SCserif]\\scserif{Noto Sans CJK SC}[AutoFakeSlant]
}
\\newCJKfontfamily[SCsans]\\scsans{Noto Sans CJK SC}[AutoFakeSlant]
\\newCJKfontfamily[SCmono]\\scmono{Noto Sans Mono CJK SC}[AutoFakeSlant]
\\IfFontExistsTF{Noto Serif CJK TC}{
\\newCJKfontfamily[TCmain]\\tcmain{Noto Serif CJK TC}[AutoFakeSlant]
\\newCJKfontfamily[TCserif]\\tcserif{Noto Serif CJK TC}[AutoFakeSlant]
}{
\\newCJKfontfamily[TCmain]\\tcmain{Noto Sans CJK TC}[AutoFakeSlant]
\\newCJKfontfamily[TCserif]\\tcserif{Noto Sans CJK TC}[AutoFakeSlant]
}
\\newCJKfontfamily[TCsans]\\tcsans{Noto Sans CJK TC}[AutoFakeSlant]
\\newCJKfontfamily[TCmono]\\tcmono{Noto Sans Mono CJK TC}[AutoFakeSlant]
\\IfFontExistsTF{Noto Serif CJK KR}{
\\newCJKfontfamily[KRmain]\\krmain{Noto Serif CJK KR}[AutoFakeSlant]
\\newCJKfontfamily[KRserif]\\krserif{Noto Serif CJK KR}[AutoFakeSlant]
}{
\\newCJKfontfamily[KRmain]\\krmain{Noto Sans CJK KR}[AutoFakeSlant]
\\newCJKfontfamily[KRserif]\\krserif{Noto Sans CJK KR}[AutoFakeSlant]
}
\\newCJKfontfamily[KRsans]\\krsans{Noto Sans CJK KR}[AutoFakeSlant]
\\newCJKfontfamily[KRmono]\\krmono{Noto Sans Mono CJK KR}[AutoFakeSlant]
\\IfFontExistsTF{Noto Serif CJK JP}{
\\newCJKfontfamily[JPmain]\\jpmain{Noto Serif CJK JP}[AutoFakeSlant]
\\newCJKfontfamily[JPserif]\\jpserif{Noto Serif CJK JP}[AutoFakeSlant]
}{
\\newCJKfontfamily[JPmain]\\jpmain{Noto Sans CJK JP}[AutoFakeSlant]
\\newCJKfontfamily[JPserif]\\jpserif{Noto Sans CJK JP}[AutoFakeSlant]
}
\\newCJKfontfamily[JPsans]\\jpsans{Noto Sans CJK JP}[AutoFakeSlant]
\\newCJKfontfamily[JPmono]\\jpmono{Noto Sans Mono CJK JP}[AutoFakeSlant]
% Dummy commands for Sphinx < 2.3 (no 'extrapackages' support)
\\providecommand{\\onehalfspacing}{}
\\providecommand{\\singlespacing}{}
% Define custom macros to on/off CJK
\\newcommand{\\kerneldocCJKon}{\\makexeCJKactive\\onehalfspacing}
\\newcommand{\\kerneldocCJKoff}{\\makexeCJKinactive\\singlespacing}
\\newcommand{\\kerneldocBeginSC}{%
\\begingroup%
\\scmain%
}
\\newcommand{\\kerneldocEndSC}{\\endgroup}
\\newcommand{\\kerneldocBeginTC}{%
\\begingroup%
\\tcmain%
\\renewcommand{\\CJKrmdefault}{TCserif}%
\\renewcommand{\\CJKsfdefault}{TCsans}%
\\renewcommand{\\CJKttdefault}{TCmono}%
}
\\newcommand{\\kerneldocEndTC}{\\endgroup}
\\newcommand{\\kerneldocBeginKR}{%
\\begingroup%
\\xeCJKDeclareCharClass{HalfLeft}{`“,`‘}%
\\xeCJKDeclareCharClass{HalfRight}{`”,`’}%
\\krmain%
\\renewcommand{\\CJKrmdefault}{KRserif}%
\\renewcommand{\\CJKsfdefault}{KRsans}%
\\renewcommand{\\CJKttdefault}{KRmono}%
\\xeCJKsetup{CJKspace = true} % For inter-phrase space
}
\\newcommand{\\kerneldocEndKR}{\\endgroup}
\\newcommand{\\kerneldocBeginJP}{%
\\begingroup%
\\xeCJKDeclareCharClass{HalfLeft}{`“,`‘}%
\\xeCJKDeclareCharClass{HalfRight}{`”,`’}%
\\jpmain%
\\renewcommand{\\CJKrmdefault}{JPserif}%
\\renewcommand{\\CJKsfdefault}{JPsans}%
\\renewcommand{\\CJKttdefault}{JPmono}%
}
\\newcommand{\\kerneldocEndJP}{\\endgroup}
% Single spacing in literal blocks
\\fvset{baselinestretch=1}
% To customize \\sphinxtableofcontents
\\usepackage{etoolbox}
% Inactivate CJK after tableofcontents
\\apptocmd{\\sphinxtableofcontents}{\\kerneldocCJKoff}{}{}
}{ % No CJK font found
% Custom macros to on/off CJK (Dummy)
\\newcommand{\\kerneldocCJKon}{}
\\newcommand{\\kerneldocCJKoff}{}
\\newcommand{\\kerneldocBeginSC}{}
\\newcommand{\\kerneldocEndSC}{}
\\newcommand{\\kerneldocBeginTC}{}
\\newcommand{\\kerneldocEndTC}{}
\\newcommand{\\kerneldocBeginKR}{}
\\newcommand{\\kerneldocEndKR}{}
\\newcommand{\\kerneldocBeginJP}{}
\\newcommand{\\kerneldocEndJP}{}
}
'''
# Fix reference escape troubles with Sphinx 1.4.x
if major == 1:
latex_elements['preamble'] += '\\renewcommand*{\\DUrole}[2]{ #2 }\n'
# Load kerneldoc specific LaTeX settings
latex_elements['preamble'] += '''
% Load kerneldoc specific LaTeX settings
\\input{kerneldoc-preamble.sty}
'''
# With Sphinx 1.6, it is possible to change the Bg color directly
# by using:
# \definecolor{sphinxnoteBgColor}{RGB}{204,255,255}
@ -599,6 +489,11 @@ for fn in os.listdir('.'):
# If false, no module index is generated.
#latex_domain_indices = True
# Additional LaTeX stuff to be copied to build directory
latex_additional_files = [
'sphinx/kerneldoc-preamble.sty',
]
# -- Options for manual page output ---------------------------------------

279
Documentation/core-api/entry.rst Normal file
View File

@ -0,0 +1,279 @@
Entry/exit handling for exceptions, interrupts, syscalls and KVM
================================================================
All transitions between execution domains require state updates which are
subject to strict ordering constraints. State updates are required for the
following:
* Lockdep
* RCU / Context tracking
* Preemption counter
* Tracing
* Time accounting
The update order depends on the transition type and is explained below in
the transition type sections: `Syscalls`_, `KVM`_, `Interrupts and regular
exceptions`_, `NMI and NMI-like exceptions`_.
Non-instrumentable code - noinstr
---------------------------------
Most instrumentation facilities depend on RCU, so intrumentation is prohibited
for entry code before RCU starts watching and exit code after RCU stops
watching. In addition, many architectures must save and restore register state,
which means that (for example) a breakpoint in the breakpoint entry code would
overwrite the debug registers of the initial breakpoint.
Such code must be marked with the 'noinstr' attribute, placing that code into a
special section inaccessible to instrumentation and debug facilities. Some
functions are partially instrumentable, which is handled by marking them
noinstr and using instrumentation_begin() and instrumentation_end() to flag the
instrumentable ranges of code:
.. code-block:: c
noinstr void entry(void)
{
handle_entry(); // <-- must be 'noinstr' or '__always_inline'
...
instrumentation_begin();
handle_context(); // <-- instrumentable code
instrumentation_end();
...
handle_exit(); // <-- must be 'noinstr' or '__always_inline'
}
This allows verification of the 'noinstr' restrictions via objtool on
supported architectures.
Invoking non-instrumentable functions from instrumentable context has no
restrictions and is useful to protect e.g. state switching which would
cause malfunction if instrumented.
All non-instrumentable entry/exit code sections before and after the RCU
state transitions must run with interrupts disabled.
Syscalls
--------
Syscall-entry code starts in assembly code and calls out into low-level C code
after establishing low-level architecture-specific state and stack frames. This
low-level C code must not be instrumented. A typical syscall handling function
invoked from low-level assembly code looks like this:
.. code-block:: c
noinstr void syscall(struct pt_regs *regs, int nr)
{
arch_syscall_enter(regs);
nr = syscall_enter_from_user_mode(regs, nr);
instrumentation_begin();
if (!invoke_syscall(regs, nr) && nr != -1)
result_reg(regs) = __sys_ni_syscall(regs);
instrumentation_end();
syscall_exit_to_user_mode(regs);
}
syscall_enter_from_user_mode() first invokes enter_from_user_mode() which
establishes state in the following order:
* Lockdep
* RCU / Context tracking
* Tracing
and then invokes the various entry work functions like ptrace, seccomp, audit,
syscall tracing, etc. After all that is done, the instrumentable invoke_syscall
function can be invoked. The instrumentable code section then ends, after which
syscall_exit_to_user_mode() is invoked.
syscall_exit_to_user_mode() handles all work which needs to be done before
returning to user space like tracing, audit, signals, task work etc. After
that it invokes exit_to_user_mode() which again handles the state
transition in the reverse order:
* Tracing
* RCU / Context tracking
* Lockdep
syscall_enter_from_user_mode() and syscall_exit_to_user_mode() are also
available as fine grained subfunctions in cases where the architecture code
has to do extra work between the various steps. In such cases it has to
ensure that enter_from_user_mode() is called first on entry and
exit_to_user_mode() is called last on exit.
Do not nest syscalls. Nested systcalls will cause RCU and/or context tracking
to print a warning.
KVM
---
Entering or exiting guest mode is very similar to syscalls. From the host
kernel point of view the CPU goes off into user space when entering the
guest and returns to the kernel on exit.
kvm_guest_enter_irqoff() is a KVM-specific variant of exit_to_user_mode()
and kvm_guest_exit_irqoff() is the KVM variant of enter_from_user_mode().
The state operations have the same ordering.
Task work handling is done separately for guest at the boundary of the
vcpu_run() loop via xfer_to_guest_mode_handle_work() which is a subset of
the work handled on return to user space.
Do not nest KVM entry/exit transitions because doing so is nonsensical.
Interrupts and regular exceptions
---------------------------------
Interrupts entry and exit handling is slightly more complex than syscalls
and KVM transitions.
If an interrupt is raised while the CPU executes in user space, the entry
and exit handling is exactly the same as for syscalls.
If the interrupt is raised while the CPU executes in kernel space the entry and
exit handling is slightly different. RCU state is only updated when the
interrupt is raised in the context of the CPU's idle task. Otherwise, RCU will
already be watching. Lockdep and tracing have to be updated unconditionally.
irqentry_enter() and irqentry_exit() provide the implementation for this.
The architecture-specific part looks similar to syscall handling:
.. code-block:: c
noinstr void interrupt(struct pt_regs *regs, int nr)
{
arch_interrupt_enter(regs);
state = irqentry_enter(regs);
instrumentation_begin();
irq_enter_rcu();
invoke_irq_handler(regs, nr);
irq_exit_rcu();
instrumentation_end();
irqentry_exit(regs, state);
}
Note that the invocation of the actual interrupt handler is within a
irq_enter_rcu() and irq_exit_rcu() pair.
irq_enter_rcu() updates the preemption count which makes in_hardirq()
return true, handles NOHZ tick state and interrupt time accounting. This
means that up to the point where irq_enter_rcu() is invoked in_hardirq()
returns false.
irq_exit_rcu() handles interrupt time accounting, undoes the preemption
count update and eventually handles soft interrupts and NOHZ tick state.
In theory, the preemption count could be updated in irqentry_enter(). In
practice, deferring this update to irq_enter_rcu() allows the preemption-count
code to be traced, while also maintaining symmetry with irq_exit_rcu() and
irqentry_exit(), which are described in the next paragraph. The only downside
is that the early entry code up to irq_enter_rcu() must be aware that the
preemption count has not yet been updated with the HARDIRQ_OFFSET state.
Note that irq_exit_rcu() must remove HARDIRQ_OFFSET from the preemption count
before it handles soft interrupts, whose handlers must run in BH context rather
than irq-disabled context. In addition, irqentry_exit() might schedule, which
also requires that HARDIRQ_OFFSET has been removed from the preemption count.
Even though interrupt handlers are expected to run with local interrupts
disabled, interrupt nesting is common from an entry/exit perspective. For
example, softirq handling happens within an irqentry_{enter,exit}() block with
local interrupts enabled. Also, although uncommon, nothing prevents an
interrupt handler from re-enabling interrupts.
Interrupt entry/exit code doesn't strictly need to handle reentrancy, since it
runs with local interrupts disabled. But NMIs can happen anytime, and a lot of
the entry code is shared between the two.
NMI and NMI-like exceptions
---------------------------
NMIs and NMI-like exceptions (machine checks, double faults, debug
interrupts, etc.) can hit any context and must be extra careful with
the state.
State changes for debug exceptions and machine-check exceptions depend on
whether these exceptions happened in user-space (breakpoints or watchpoints) or
in kernel mode (code patching). From user-space, they are treated like
interrupts, while from kernel mode they are treated like NMIs.
NMIs and other NMI-like exceptions handle state transitions without
distinguishing between user-mode and kernel-mode origin.
The state update on entry is handled in irqentry_nmi_enter() which updates
state in the following order:
* Preemption counter
* Lockdep
* RCU / Context tracking
* Tracing
The exit counterpart irqentry_nmi_exit() does the reverse operation in the
reverse order.
Note that the update of the preemption counter has to be the first
operation on enter and the last operation on exit. The reason is that both
lockdep and RCU rely on in_nmi() returning true in this case. The
preemption count modification in the NMI entry/exit case must not be
traced.
Architecture-specific code looks like this:
.. code-block:: c
noinstr void nmi(struct pt_regs *regs)
{
arch_nmi_enter(regs);
state = irqentry_nmi_enter(regs);
instrumentation_begin();
nmi_handler(regs);
instrumentation_end();
irqentry_nmi_exit(regs);
}
and for e.g. a debug exception it can look like this:
.. code-block:: c
noinstr void debug(struct pt_regs *regs)
{
arch_nmi_enter(regs);
debug_regs = save_debug_regs();
if (user_mode(regs)) {
state = irqentry_enter(regs);
instrumentation_begin();
user_mode_debug_handler(regs, debug_regs);
instrumentation_end();
irqentry_exit(regs, state);
} else {
state = irqentry_nmi_enter(regs);
instrumentation_begin();
kernel_mode_debug_handler(regs, debug_regs);
instrumentation_end();
irqentry_nmi_exit(regs, state);
}
}
There is no combined irqentry_nmi_if_kernel() function available as the
above cannot be handled in an exception-agnostic way.
NMIs can happen in any context. For example, an NMI-like exception triggered
while handling an NMI. So NMI entry code has to be reentrant and state updates
need to handle nesting.

8
Documentation/core-api/index.rst
View File

@ -44,6 +44,14 @@ Library functionality that is used throughout the kernel.
timekeeping
errseq
Low level entry and exit
========================
.. toctree::
:maxdepth: 1
entry
Concurrency primitives
======================

49
Documentation/dev-tools/ktap.rst
View File

@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
========================================
The Kernel Test Anything Protocol (KTAP)
========================================
===================================================
The Kernel Test Anything Protocol (KTAP), version 1
===================================================
TAP, or the Test Anything Protocol is a format for specifying test results used
by a number of projects. It's website and specification are found at this `link
@ -68,7 +68,7 @@ Test case result lines
Test case result lines indicate the final status of a test.
They are required and must have the format:
.. code-block::
.. code-block:: none
<result> <number> [<description>][ # [<directive>] [<diagnostic data>]]
@ -117,32 +117,32 @@ separator.
Example result lines include:
.. code-block::
.. code-block:: none
ok 1 test_case_name
The test "test_case_name" passed.
.. code-block::
.. code-block:: none
not ok 1 test_case_name
The test "test_case_name" failed.
.. code-block::
.. code-block:: none
ok 1 test # SKIP necessary dependency unavailable
The test "test" was SKIPPED with the diagnostic message "necessary dependency
unavailable".
.. code-block::
.. code-block:: none
not ok 1 test # TIMEOUT 30 seconds
The test "test" timed out, with diagnostic data "30 seconds".
.. code-block::
.. code-block:: none
ok 5 check return code # rcode=0
@ -174,6 +174,13 @@ There may be lines within KTAP output that do not follow the format of one of
the four formats for lines described above. This is allowed, however, they will
not influence the status of the tests.
This is an important difference from TAP. Kernel tests may print messages
to the system console or a log file. Both of these destinations may contain
messages either from unrelated kernel or userspace activity, or kernel
messages from non-test code that is invoked by the test. The kernel code
invoked by the test likely is not aware that a test is in progress and
thus can not print the message as a diagnostic message.
Nested tests
------------
@ -186,13 +193,16 @@ starting with another KTAP version line and test plan, and end with the overall
result. If one of the subtests fail, for example, the parent test should also
fail.
Additionally, all result lines in a subtest should be indented. One level of
Additionally, all lines in a subtest should be indented. One level of
indentation is two spaces: " ". The indentation should begin at the version
line and should end before the parent test's result line.
"Unknown lines" are not considered to be lines in a subtest and thus are
allowed to be either indented or not indented.
An example of a test with two nested subtests:
.. code-block::
.. code-block:: none
KTAP version 1
1..1
@ -205,7 +215,7 @@ An example of a test with two nested subtests:
An example format with multiple levels of nested testing:
.. code-block::
.. code-block:: none
KTAP version 1
1..2
@ -224,10 +234,15 @@ An example format with multiple levels of nested testing:
Major differences between TAP and KTAP
--------------------------------------
Note the major differences between the TAP and KTAP specification:
- yaml and json are not recommended in diagnostic messages
- TODO directive not recognized
- KTAP allows for an arbitrary number of tests to be nested
================================================== ========= ===============
Feature TAP KTAP
================================================== ========= ===============
yaml and json in diagnosic message ok not recommended
TODO directive ok not recognized
allows an arbitrary number of tests to be nested no yes
"Unknown lines" are in category of "Anything else" yes no
"Unknown lines" are incorrect allowed
================================================== ========= ===============
The TAP14 specification does permit nested tests, but instead of using another
nested version line, uses a line of the form
@ -235,7 +250,7 @@ nested version line, uses a line of the form
Example KTAP output
--------------------
.. code-block::
.. code-block:: none
KTAP version 1
1..1

2
Documentation/devicetree/bindings/arm/pmu.yaml
View File

@ -20,6 +20,8 @@ properties:
items:
- enum:
- apm,potenza-pmu
- apple,firestorm-pmu
- apple,icestorm-pmu
- arm,armv8-pmuv3 # Only for s/w models
- arm,arm1136-pmu
- arm,arm1176-pmu

40
Documentation/devicetree/bindings/extcon/maxim,max77843.yaml Normal file
View File

@ -0,0 +1,40 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/extcon/maxim,max77843.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX77843 MicroUSB and Companion Power Management IC Extcon
maintainers:
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description: |
This is a part of device tree bindings for Maxim MAX77843 MicroUSB
Integrated Circuit (MUIC).
See also Documentation/devicetree/bindings/mfd/maxim,max77843.yaml for
additional information and example.
properties:
compatible:
const: maxim,max77843-muic
connector:
$ref: /schemas/connector/usb-connector.yaml#
ports:
$ref: /schemas/graph.yaml#/properties/port
description:
Any connector to the data bus of this controller should be modelled using
the OF graph bindings specified
properties:
port:
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- connector
additionalProperties: false

68
Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml
View File

@ -37,6 +37,72 @@ properties:
description:
Shunt resistor value in micro-Ohm.
adi,volt-curr-sample-average:
description: |
Number of samples to be used to report voltage and current values.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 2, 4, 8, 16, 32, 64, 128]
adi,power-sample-average:
description: |
Number of samples to be used to report power values.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 2, 4, 8, 16, 32, 64, 128]
allOf:
- if:
properties:
compatible:
contains:
enum:
- adi,adm1075
- adi,adm1276
then:
properties:
adi,volt-curr-sample-average:
default: 128
adi,power-sample-average: false
- if:
properties:
compatible:
contains:
enum:
- adi,adm1275
then:
properties:
adi,volt-curr-sample-average:
default: 16
adi,power-sample-average: false
- if:
properties:
compatible:
contains:
enum:
- adi,adm1272
then:
properties:
adi,volt-curr-sample-average:
default: 128
adi,power-sample-average:
default: 128
- if:
properties:
compatible:
contains:
enum:
- adi,adm1278
- adi,adm1293
- adi,adm1294
then:
properties:
adi,volt-curr-sample-average:
default: 128
adi,power-sample-average:
default: 1
required:
- compatible
- reg
@ -53,5 +119,7 @@ examples:
compatible = "adi,adm1272";
reg = <0x10>;
shunt-resistor-micro-ohms = <500>;
adi,volt-curr-sample-average = <128>;
adi,power-sample-average = <128>;
};
};

4
Documentation/devicetree/bindings/hwmon/national,lm90.yaml
View File

@ -60,7 +60,6 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/tegra-gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
@ -71,8 +70,7 @@ examples:
compatible = "onnn,nct1008";
reg = <0x4c>;
vcc-supply = <&palmas_ldo6_reg>;
interrupt-parent = <&gpio>;
interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>;
interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
#thermal-sensor-cells = <1>;
};
};

114
Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml Normal file
View File

@ -0,0 +1,114 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/ti,tmp464.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TMP464 and TMP468 temperature sensors
maintainers:
- Agathe Porte <agathe.porte@nokia.com>
description: |
±0.0625°C Remote and Local temperature sensor
https://www.ti.com/lit/ds/symlink/tmp464.pdf
https://www.ti.com/lit/ds/symlink/tmp468.pdf
properties:
compatible:
enum:
- ti,tmp464
- ti,tmp468
reg:
maxItems: 1
'#address-cells':
const: 1
'#size-cells':
const: 0
required:
- compatible
- reg
additionalProperties: false
patternProperties:
"^channel@([0-8])$":
type: object
description: |
Represents channels of the device and their specific configuration.
properties:
reg:
description: |
The channel number. 0 is local channel, 1-8 are remote channels.
items:
minimum: 0
maximum: 8
label:
description: |
A descriptive name for this channel, like "ambient" or "psu".
ti,n-factor:
description: |
The value (two's complement) to be programmed in the channel specific N correction register.
For remote channels only.
$ref: /schemas/types.yaml#/definitions/int32
items:
minimum: -128
maximum: 127
required:
- reg
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
sensor@4b {
compatible = "ti,tmp464";
reg = <0x4b>;
};
};
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
sensor@4b {
compatible = "ti,tmp464";
reg = <0x4b>;
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
reg = <0x0>;
label = "local";
};
channel@1 {
reg = <0x1>;
ti,n-factor = <(-10)>;
label = "external";
};
channel@2 {
reg = <0x2>;
ti,n-factor = <0x10>;
label = "somelabel";
};
channel@3 {
reg = <0x3>;
status = "disabled";
};
};
};

1
Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
View File

@ -18,6 +18,7 @@ Required properties:
"amlogic,meson-g12a-gpio-intc" for G12A SoCs (S905D2, S905X2, S905Y2)
"amlogic,meson-sm1-gpio-intc" for SM1 SoCs (S905D3, S905X3, S905Y3)
"amlogic,meson-a1-gpio-intc" for A1 SoCs (A113L)
"amlogic,meson-s4-gpio-intc" for S4 SoCs (S802X2, S905Y4, S805X2G, S905W2)
- reg : Specifies base physical address and size of the registers.
- interrupt-controller : Identifies the node as an interrupt controller.
- #interrupt-cells : Specifies the number of cells needed to encode an

31
Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
View File

@ -56,6 +56,8 @@ properties:
- 1: virtual HV timer
- 2: physical guest timer
- 3: virtual guest timer
- 4: 'efficient' CPU PMU
- 5: 'performance' CPU PMU
The 3rd cell contains the interrupt flags. This is normally
IRQ_TYPE_LEVEL_HIGH (4).
@ -68,6 +70,35 @@ properties:
power-domains:
maxItems: 1
affinities:
type: object
additionalProperties: false
description:
FIQ affinity can be expressed as a single "affinities" node,
containing a set of sub-nodes, one per FIQ with a non-default
affinity.
patternProperties:
"^.+-affinity$":
type: object
additionalProperties: false
properties:
apple,fiq-index:
description:
The interrupt number specified as a FIQ, and for which
the affinity is not the default.
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 5
cpus:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
Should be a list of phandles to CPU nodes (as described in
Documentation/devicetree/bindings/arm/cpus.yaml).
required:
- fiq-index
- cpus
required:
- compatible
- '#interrupt-cells'

98
Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml Normal file
View File

@ -0,0 +1,98 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/apple,aic2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple Interrupt Controller 2
maintainers:
- Hector Martin <marcan@marcan.st>
description: |
The Apple Interrupt Controller 2 is a simple interrupt controller present on
Apple ARM SoC platforms starting with t600x (M1 Pro and Max).
It provides the following features:
- Level-triggered hardware IRQs wired to SoC blocks
- Single mask bit per IRQ
- Automatic masking on event delivery (auto-ack)
- Software triggering (ORed with hw line)
- Automatic prioritization (single event/ack register per CPU, lower IRQs =
higher priority)
- Automatic masking on ack
- Support for multiple dies
This device also represents the FIQ interrupt sources on platforms using AIC,
which do not go through a discrete interrupt controller. It also handles
FIQ-based Fast IPIs.
properties:
compatible:
items:
- const: apple,t6000-aic
- const: apple,aic2
interrupt-controller: true
'#interrupt-cells':
const: 4
description: |
The 1st cell contains the interrupt type:
- 0: Hardware IRQ
- 1: FIQ
The 2nd cell contains the die ID.
The next cell contains the interrupt number.
- HW IRQs: interrupt number
- FIQs:
- 0: physical HV timer
- 1: virtual HV timer
- 2: physical guest timer
- 3: virtual guest timer
The last cell contains the interrupt flags. This is normally
IRQ_TYPE_LEVEL_HIGH (4).
reg:
items:
- description: Address and size of the main AIC2 registers.
- description: Address and size of the AIC2 Event register.
reg-names:
items:
- const: core
- const: event
power-domains:
maxItems: 1
required:
- compatible
- '#interrupt-cells'
- interrupt-controller
- reg
- reg-names
additionalProperties: false
allOf:
- $ref: /schemas/interrupt-controller.yaml#
examples:
- |
soc {
#address-cells = <2>;
#size-cells = <2>;
aic: interrupt-controller@28e100000 {
compatible = "apple,t6000-aic", "apple,aic2";
#interrupt-cells = <4>;
interrupt-controller;
reg = <0x2 0x8e100000 0x0 0xc000>,
<0x2 0x8e10c000 0x0 0x4>;
reg-names = "core", "event";
};
};

96
Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml Normal file
View File

@ -0,0 +1,96 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/qcom,mpm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcom MPM Interrupt Controller
maintainers:
- Shawn Guo <shawn.guo@linaro.org>
description:
Qualcomm Technologies Inc. SoCs based on the RPM architecture have a
MSM Power Manager (MPM) that is in always-on domain. In addition to managing
resources during sleep, the hardware also has an interrupt controller that
monitors the interrupts when the system is asleep, wakes up the APSS when
one of these interrupts occur and replays it to GIC interrupt controller
after GIC becomes operational.
allOf:
- $ref: /schemas/interrupt-controller.yaml#
properties:
compatible:
items:
- const: qcom,mpm
reg:
maxItems: 1
description:
Specifies the base address and size of vMPM registers in RPM MSG RAM.
interrupts:
maxItems: 1
description:
Specify the IRQ used by RPM to wakeup APSS.
mboxes:
maxItems: 1
description:
Specify the mailbox used to notify RPM for writing vMPM registers.
interrupt-controller: true
'#interrupt-cells':
const: 2
description:
The first cell is the MPM pin number for the interrupt, and the second
is the trigger type.
qcom,mpm-pin-count:
description:
Specify the total MPM pin count that a SoC supports.
$ref: /schemas/types.yaml#/definitions/uint32
qcom,mpm-pin-map:
description:
A set of MPM pin numbers and the corresponding GIC SPIs.
$ref: /schemas/types.yaml#/definitions/uint32-matrix
items:
items:
- description: MPM pin number
- description: GIC SPI number for the MPM pin
required:
- compatible
- reg
- interrupts
- mboxes
- interrupt-controller
- '#interrupt-cells'
- qcom,mpm-pin-count
- qcom,mpm-pin-map
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
mpm: interrupt-controller@45f01b8 {
compatible = "qcom,mpm";
interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
reg = <0x45f01b8 0x1000>;
mboxes = <&apcs_glb 1>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
qcom,mpm-pin-count = <96>;
qcom,mpm-pin-map = <2 275>,
<5 296>,
<12 422>,
<24 79>,
<86 183>,
<90 260>,
<91 260>;
};

1
Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml
View File

@ -20,6 +20,7 @@ properties:
- items:
- enum:
- st,stm32mp1-exti
- st,stm32mp13-exti
- const: syscon
"#interrupt-cells":

31
Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
View File

@ -31,7 +31,7 @@ properties:
controller-data:
description:
SPI controller data, see bindings/spi/spi-samsung.txt
SPI controller data, see bindings/spi/samsung,spi-peripheral-props.yaml
type: object
google,cros-ec-spi-pre-delay:
@ -148,18 +148,21 @@ patternProperties:
required:
- compatible
if:
properties:
compatible:
contains:
enum:
- google,cros-ec-i2c
- google,cros-ec-rpmsg
then:
properties:
google,cros-ec-spi-pre-delay: false
google,cros-ec-spi-msg-delay: false
spi-max-frequency: false
allOf:
- if:
properties:
compatible:
contains:
enum:
- google,cros-ec-i2c
- google,cros-ec-rpmsg
then:
properties:
google,cros-ec-spi-pre-delay: false
google,cros-ec-spi-msg-delay: false
spi-max-frequency: false
else:
$ref: /schemas/spi/spi-peripheral-props.yaml
additionalProperties: false
@ -200,7 +203,7 @@ examples:
spi-max-frequency = <5000000>;
proximity {
compatible = "google,cros-ec-mkbp-proximity";
compatible = "google,cros-ec-mkbp-proximity";
};
cbas {

147
Documentation/devicetree/bindings/mfd/max14577.txt
View File

@ -1,147 +0,0 @@
Maxim MAX14577/77836 Multi-Function Device
MAX14577 is a Multi-Function Device with Micro-USB Interface Circuit, Li+
Battery Charger and SFOUT LDO output for powering USB devices. It is
interfaced to host controller using I2C.
MAX77836 additionally contains PMIC (with two LDO regulators) and Fuel Gauge.
For the description of Fuel Gauge low SOC alert interrupt see:
../power/supply/max17040_battery.txt
Required properties:
- compatible : Must be "maxim,max14577" or "maxim,max77836".
- reg : I2C slave address for the max14577 chip (0x25 for max14577/max77836)
- interrupts : IRQ line for the chip.
Required nodes:
- charger :
Node for configuring the charger driver.
Required properties:
- compatible : "maxim,max14577-charger"
or "maxim,max77836-charger"
- maxim,fast-charge-uamp : Current in uA for Fast Charge;
Valid values:
- for max14577: 90000 - 950000;
- for max77836: 45000 - 475000;
- maxim,eoc-uamp : Current in uA for End-Of-Charge mode;
Valid values:
- for max14577: 50000 - 200000;
- for max77836: 5000 - 100000;
- maxim,ovp-uvolt : OverVoltage Protection Threshold in uV;
In an overvoltage condition, INT asserts and charging
stops. Valid values:
- 6000000, 6500000, 7000000, 7500000;
- maxim,constant-uvolt : Battery Constant Voltage in uV;
Valid values:
- 4000000 - 4280000 (step by 20000);
- 4350000;
Optional nodes:
- max14577-muic/max77836-muic :
Node used only by extcon consumers.
Required properties:
- compatible : "maxim,max14577-muic" or "maxim,max77836-muic"
- regulators :
Required properties:
- compatible : "maxim,max14577-regulator"
or "maxim,max77836-regulator"
May contain a sub-node per regulator from the list below. Each
sub-node should contain the constraints and initialization information
for that regulator. See regulator.txt for a description of standard
properties for these sub-nodes.
List of valid regulator names:
- for max14577: CHARGER, SAFEOUT.
- for max77836: CHARGER, SAFEOUT, LDO1, LDO2.
The SAFEOUT is a fixed voltage regulator so there is no need to specify
voltages for it.
Example:
#include <dt-bindings/interrupt-controller/irq.h>
max14577@25 {
compatible = "maxim,max14577";
reg = <0x25>;
interrupt-parent = <&gpx1>;
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
muic: max14577-muic {
compatible = "maxim,max14577-muic";
};
regulators {
compatible = "maxim,max14577-regulator";
SAFEOUT {
regulator-name = "SAFEOUT";
};
CHARGER {
regulator-name = "CHARGER";
regulator-min-microamp = <90000>;
regulator-max-microamp = <950000>;
regulator-boot-on;
};
};
charger {
compatible = "maxim,max14577-charger";
maxim,constant-uvolt = <4350000>;
maxim,fast-charge-uamp = <450000>;
maxim,eoc-uamp = <50000>;
maxim,ovp-uvolt = <6500000>;
};
};
max77836@25 {
compatible = "maxim,max77836";
reg = <0x25>;
interrupt-parent = <&gpx1>;
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
muic: max77836-muic {
compatible = "maxim,max77836-muic";
};
regulators {
compatible = "maxim,max77836-regulator";
SAFEOUT {
regulator-name = "SAFEOUT";
};
CHARGER {
regulator-name = "CHARGER";
regulator-min-microamp = <90000>;
regulator-max-microamp = <950000>;
regulator-boot-on;
};
LDO1 {
regulator-name = "LDO1";
regulator-min-microvolt = <2700000>;
regulator-max-microvolt = <2700000>;
};
LDO2 {
regulator-name = "LDO2";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3950000>;
};
};
charger {
compatible = "maxim,max77836-charger";
maxim,constant-uvolt = <4350000>;
maxim,fast-charge-uamp = <225000>;
maxim,eoc-uamp = <7500>;
maxim,ovp-uvolt = <6500000>;
};
};

25
Documentation/devicetree/bindings/mfd/max77802.txt
View File

@ -1,25 +0,0 @@
Maxim MAX77802 multi-function device
The Maxim MAX77802 is a Power Management IC (PMIC) that contains 10 high
efficiency Buck regulators, 32 Low-DropOut (LDO) regulators used to power
up application processors and peripherals, a 2-channel 32kHz clock outputs,
a Real-Time-Clock (RTC) and a I2C interface to program the individual
regulators, clocks outputs and the RTC.
Bindings for the built-in 32k clock generator block and
regulators are defined in ../clk/maxim,max77802.txt and
../regulator/max77802.txt respectively.
Required properties:
- compatible : Must be "maxim,max77802"
- reg : Specifies the I2C slave address of PMIC block.
- interrupts : I2C device IRQ line connected to the main SoC.
Example:
max77802: pmic@9 {
compatible = "maxim,max77802";
interrupt-parent = <&intc>;
interrupts = <26 IRQ_TYPE_NONE>;
reg = <0x09>;
};

195
Documentation/devicetree/bindings/mfd/maxim,max14577.yaml Normal file
View File

@ -0,0 +1,195 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/maxim,max14577.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description: |
This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB
Integrated Circuit (MUIC).
The Maxim MAX14577 is a MicroUSB and Companion Power Management IC which
includes voltage safeout regulators, charger and MicroUSB management IC.
The Maxim MAX77836 is a MicroUSB and Companion Power Management IC which
includes voltage safeout and LDO regulators, charger, fuel-gauge and MicroUSB
management IC.
properties:
compatible:
enum:
- maxim,max14577
- maxim,max77836
interrupts:
maxItems: 1
reg:
maxItems: 1
wakeup-source: true
charger:
$ref: /schemas/power/supply/maxim,max14577.yaml
extcon:
type: object
properties:
compatible:
enum:
- maxim,max14577-muic
- maxim,max77836-muic
required:
- compatible
regulators:
$ref: /schemas/regulator/maxim,max14577.yaml
required:
- compatible
- interrupts
- reg
- charger
allOf:
- if:
properties:
compatible:
contains:
const: maxim,max14577
then:
properties:
charger:
properties:
compatible:
const: maxim,max14577-charger
extcon:
properties:
compatible:
const: maxim,max14577-muic
regulator:
properties:
compatible:
const: maxim,max14577-regulator
else:
properties:
charger:
properties:
compatible:
const: maxim,max77836-charger
extcon:
properties:
compatible:
const: maxim,max77836-muic
regulator:
properties:
compatible:
const: maxim,max77836-regulator
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
pmic@25 {
compatible = "maxim,max14577";
reg = <0x25>;
interrupt-parent = <&gpx1>;
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
extcon {
compatible = "maxim,max14577-muic";
};
regulators {
compatible = "maxim,max14577-regulator";
SAFEOUT {
regulator-name = "SAFEOUT";
};
CHARGER {
regulator-name = "CHARGER";
regulator-min-microamp = <90000>;
regulator-max-microamp = <950000>;
regulator-boot-on;
};
};
charger {
compatible = "maxim,max14577-charger";
maxim,constant-uvolt = <4350000>;
maxim,fast-charge-uamp = <450000>;
maxim,eoc-uamp = <50000>;
maxim,ovp-uvolt = <6500000>;
};
};
};
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
pmic@25 {
compatible = "maxim,max77836";
interrupt-parent = <&gpx1>;
interrupts = <5 IRQ_TYPE_NONE>;
reg = <0x25>;
wakeup-source;
extcon {
compatible = "maxim,max77836-muic";
};
regulators {
compatible = "maxim,max77836-regulator";
SAFEOUT {
regulator-name = "SAFEOUT";
};
CHARGER {
regulator-name = "CHARGER";
regulator-min-microamp = <45000>;
regulator-max-microamp = <475000>;
regulator-boot-on;
};
LDO1 {
regulator-name = "MOT_2.7V";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <2700000>;
};
LDO2 {
regulator-name = "UNUSED_LDO2";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3950000>;
};
};
charger {
compatible = "maxim,max77836-charger";
maxim,constant-uvolt = <4350000>;
maxim,fast-charge-uamp = <225000>;
maxim,eoc-uamp = <7500>;
maxim,ovp-uvolt = <6500000>;
};
};
};

194
Documentation/devicetree/bindings/mfd/maxim,max77802.yaml Normal file
View File

@ -0,0 +1,194 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/maxim,max77802.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX77802 Power Management IC
maintainers:
- Javier Martinez Canillas <javier@dowhile0.org>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description: |
This is a part of device tree bindings for Maxim MAX77802 Power Management
Integrated Circuit (PMIC).
The Maxim MAX77802 is a Power Management IC which includes voltage and
current regulators (10 high efficiency Buck regulators and 32 Low-DropOut
(LDO)), RTC and clock outputs.
The MAX77802 provides two 32.768khz clock outputs that can be controlled
(gated/ungated) over I2C. The clock IDs are defined as preprocessor macros
in dt-bindings/clock/maxim,max77802.h.
properties:
compatible:
const: maxim,max77802
'#clock-cells':
const: 1
interrupts:
maxItems: 1
reg:
maxItems: 1
regulators:
$ref: /schemas/regulator/maxim,max77802.yaml
description:
List of child nodes that specify the regulators.
inb1-supply:
description: Power supply for buck1
inb2-supply:
description: Power supply for buck2
inb3-supply:
description: Power supply for buck3
inb4-supply:
description: Power supply for buck4
inb5-supply:
description: Power supply for buck5
inb6-supply:
description: Power supply for buck6
inb7-supply:
description: Power supply for buck7
inb8-supply:
description: Power supply for buck8
inb9-supply:
description: Power supply for buck9
inb10-supply:
description: Power supply for buck10
inl1-supply:
description: Power supply for LDO8, LDO15
inl2-supply:
description: Power supply for LDO17, LDO27, LDO30, LDO35
inl3-supply:
description: Power supply for LDO3, LDO5, LDO7, LDO7
inl4-supply:
description: Power supply for LDO10, LDO11, LDO13, LDO14
inl5-supply:
description: Power supply for LDO9, LDO19
inl6-supply:
description: Power supply for LDO4, LDO21, LDO24, LDO33
inl7-supply:
description: Power supply for LDO18, LDO20, LDO28, LDO29
inl9-supply:
description: Power supply for LDO12, LDO23, LDO25, LDO26, LDO32, LDO34
inl10-supply:
description: Power supply for LDO1, LDO2
wakeup-source: true
required:
- compatible
- '#clock-cells'
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/regulator/maxim,max77802.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
pmic@9 {
compatible = "maxim,max77802";
interrupt-parent = <&gpx3>;
interrupts = <1 IRQ_TYPE_NONE>;
pinctrl-names = "default";
pinctrl-0 = <&max77802_irq>, <&pmic_selb>,
<&pmic_dvs_1>, <&pmic_dvs_2>, <&pmic_dvs_3>;
wakeup-source;
reg = <0x9>;
#clock-cells = <1>;
inb1-supply = <&tps65090_dcdc2>;
inb2-supply = <&tps65090_dcdc1>;
inb3-supply = <&tps65090_dcdc2>;
inb4-supply = <&tps65090_dcdc2>;
inb5-supply = <&tps65090_dcdc1>;
inb6-supply = <&tps65090_dcdc2>;
inb7-supply = <&tps65090_dcdc1>;
inb8-supply = <&tps65090_dcdc1>;
inb9-supply = <&tps65090_dcdc1>;
inb10-supply = <&tps65090_dcdc1>;
inl1-supply = <&buck5_reg>;
inl2-supply = <&buck7_reg>;
inl3-supply = <&buck9_reg>;
inl4-supply = <&buck9_reg>;
inl5-supply = <&buck9_reg>;
inl6-supply = <&tps65090_dcdc2>;
inl7-supply = <&buck9_reg>;
inl9-supply = <&tps65090_dcdc2>;
inl10-supply = <&buck7_reg>;
regulators {
BUCK1 {
regulator-name = "vdd_mif";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1300000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
regulator-state-mem {
regulator-off-in-suspend;
};
};
BUCK2 {
regulator-name = "vdd_arm";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1500000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12500>;
regulator-coupled-with = <&buck3_reg>;
regulator-coupled-max-spread = <300000>;
regulator-state-mem {
regulator-off-in-suspend;
};
};
// ...
BUCK10 {
regulator-name = "vdd_1v8";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-boot-on;
regulator-state-mem {
regulator-on-in-suspend;
};
};
LDO1 {
regulator-name = "vdd_1v0";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <MAX77802_OPMODE_NORMAL>;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <MAX77802_OPMODE_LP>;
};
};
// ...
LDO35 {
regulator-name = "ldo_35";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
};
};
};
};

144
Documentation/devicetree/bindings/mfd/maxim,max77843.yaml Normal file
View File

@ -0,0 +1,144 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/maxim,max77843.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX77843 MicroUSB and Companion Power Management IC
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description: |
This is a part of device tree bindings for Maxim MAX77843 MicroUSB
Integrated Circuit (MUIC).
The Maxim MAX77843 is a MicroUSB and Companion Power Management IC which
includes voltage current regulators, charger, fuel-gauge, haptic motor driver
and MicroUSB management IC.
properties:
compatible:
const: maxim,max77843
interrupts:
maxItems: 1
reg:
maxItems: 1
extcon:
$ref: /schemas/extcon/maxim,max77843.yaml
motor-driver:
type: object
properties:
compatible:
const: maxim,max77843-haptic
haptic-supply:
description: Power supply to the haptic motor
pwms:
maxItems: 1
required:
- compatible
- haptic-supply
- pwms
regulators:
$ref: /schemas/regulator/maxim,max77843.yaml
required:
- compatible
- interrupts
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
pmic@66 {
compatible = "maxim,max77843";
interrupt-parent = <&gpa1>;
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
reg = <0x66>;
extcon {
compatible = "maxim,max77843-muic";
connector {
compatible = "samsung,usb-connector-11pin",
"usb-b-connector";
label = "micro-USB";
type = "micro";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
/*
* TODO: The DTS this is based on does not have
* port@0 which is a required property. The ports
* look incomplete and need fixing.
* Add a disabled port just to satisfy dtschema.
*/
reg = <0>;
status = "disabled";
};
port@3 {
reg = <3>;
endpoint {
remote-endpoint = <&mhl_to_musb_con>;
};
};
};
};
ports {
port {
endpoint {
remote-endpoint = <&usb_to_muic>;
};
};
};
};
regulators {
compatible = "maxim,max77843-regulator";
SAFEOUT1 {
regulator-name = "SAFEOUT1";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <4950000>;
};
SAFEOUT2 {
regulator-name = "SAFEOUT2";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <4950000>;
};
CHARGER {
regulator-name = "CHARGER";
regulator-min-microamp = <100000>;
regulator-max-microamp = <3150000>;
};
};
motor-driver {
compatible = "maxim,max77843-haptic";
haptic-supply = <&ldo38_reg>;
pwms = <&pwm 0 33670 0>;
};
};
};

3
Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
View File

@ -47,7 +47,8 @@ properties:
identified by the JEDEC READ ID opcode (0x9F).
reg:
maxItems: 1
minItems: 1
maxItems: 2
spi-max-frequency: true
spi-rx-bus-width: true

37
Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml Normal file
View File

@ -0,0 +1,37 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/perf/marvell-cn10k-ddr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Marvell CN10K DDR performance monitor
maintainers:
- Bharat Bhushan <bbhushan2@marvell.com>
properties:
compatible:
items:
- enum:
- marvell,cn10k-ddr-pmu
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
bus {
#address-cells = <2>;
#size-cells = <2>;
pmu@87e1c0000000 {
compatible = "marvell,cn10k-ddr-pmu";
reg = <0x87e1 0xc0000000 0x0 0x10000>;
};
};

84
Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml Normal file
View File

@ -0,0 +1,84 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/maxim,max14577.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC Charger
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description: |
This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB
Integrated Circuit (MUIC).
See also Documentation/devicetree/bindings/mfd/maxim,max14577.yaml for
additional information and example.
properties:
compatible:
enum:
- maxim,max14577-charger
- maxim,max77836-charger
maxim,constant-uvolt:
description:
Battery Constant Voltage in uV
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 4000000
maximum: 4350000
maxim,eoc-uamp:
description: |
Current in uA for End-Of-Charge mode.
MAX14577: 50000-20000
MAX77836: 5000-100000
$ref: /schemas/types.yaml#/definitions/uint32
maxim,fast-charge-uamp:
description: |
Current in uA for Fast Charge
MAX14577: 90000-950000
MAX77836: 45000-475000
$ref: /schemas/types.yaml#/definitions/uint32
maxim,ovp-uvolt:
description:
OverVoltage Protection Threshold in uV; In an overvoltage condition, INT
asserts and charging stops.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [6000000, 6500000, 7000000, 7500000]
required:
- compatible
- maxim,constant-uvolt
- maxim,eoc-uamp
- maxim,fast-charge-uamp
- maxim,ovp-uvolt
allOf:
- if:
properties:
compatible:
contains:
const: maxim,max14577-charger
then:
properties:
maxim,eoc-uamp:
minimum: 50000
maximum: 200000
maxim,fast-charge-uamp:
minimum: 90000
maximum: 950000
else:
# max77836
properties:
maxim,eoc-uamp:
minimum: 5000
maximum: 100000
maxim,fast-charge-uamp:
minimum: 45000
maximum: 475000
additionalProperties: false

111
Documentation/devicetree/bindings/regulator/max77802.txt
View File

@ -1,111 +0,0 @@
Binding for Maxim MAX77802 regulators
This is a part of device tree bindings of MAX77802 multi-function device.
More information can be found in bindings/mfd/max77802.txt file.
The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout (LDO)
regulators that can be controlled over I2C.
Following properties should be present in main device node of the MFD chip.
Optional properties:
- inb1-supply: The input supply for BUCK1
- inb2-supply: The input supply for BUCK2
- inb3-supply: The input supply for BUCK3
- inb4-supply: The input supply for BUCK4
- inb5-supply: The input supply for BUCK5
- inb6-supply: The input supply for BUCK6
- inb7-supply: The input supply for BUCK7
- inb8-supply: The input supply for BUCK8
- inb9-supply: The input supply for BUCK9
- inb10-supply: The input supply for BUCK10
- inl1-supply: The input supply for LDO8 and LDO15
- inl2-supply: The input supply for LDO17, LDO27, LDO30 and LDO35
- inl3-supply: The input supply for LDO3, LDO5, LDO6 and LDO7
- inl4-supply: The input supply for LDO10, LDO11, LDO13 and LDO14
- inl5-supply: The input supply for LDO9 and LDO19
- inl6-supply: The input supply for LDO4, LDO21, LDO24 and LDO33
- inl7-supply: The input supply for LDO18, LDO20, LDO28 and LDO29
- inl9-supply: The input supply for LDO12, LDO23, LDO25, LDO26, LDO32 and LDO34
- inl10-supply: The input supply for LDO1 and LDO2
Optional nodes:
- regulators : The regulators of max77802 have to be instantiated
under subnode named "regulators" using the following format.
regulator-name {
standard regulator constraints....
};
refer Documentation/devicetree/bindings/regulator/regulator.txt
The regulator node name should be initialized with a string to get matched
with their hardware counterparts as follow. The valid names are:
-LDOn : for LDOs, where n can lie in ranges 1-15, 17-21, 23-30
and 32-35.
example: LDO1, LDO2, LDO35.
-BUCKn : for BUCKs, where n can lie in range 1 to 10.
example: BUCK1, BUCK5, BUCK10.
The max77802 regulator supports two different operating modes: Normal and Low
Power Mode. Some regulators support the modes to be changed at startup or by
the consumers during normal operation while others only support to change the
mode during system suspend. The standard regulator suspend states binding can
be used to configure the regulator operating mode.
The regulators that support the standard "regulator-initial-mode" property,
changing their mode during normal operation are: LDOs 1, 3, 20 and 21.
The possible values for "regulator-initial-mode" and "regulator-mode" are:
1: Normal regulator voltage output mode.
3: Low Power which reduces the quiescent current down to only 1uA
The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h
header and can be included by device tree source files.
The standard "regulator-mode" property can only be used for regulators that
support changing their mode to Low Power Mode during suspend. These regulators
are: BUCKs 2-4 and LDOs 1-35. Also, it only takes effect if the regulator has
been enabled for the given suspend state using "regulator-on-in-suspend" and
has not been disabled for that state using "regulator-off-in-suspend".
Example:
max77802@9 {
compatible = "maxim,max77802";
interrupt-parent = <&wakeup_eint>;
interrupts = <26 0>;
reg = <0x09>;
#address-cells = <1>;
#size-cells = <0>;
inb1-supply = <&parent_reg>;
regulators {
ldo1_reg: LDO1 {
regulator-name = "vdd_1v0";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <MAX77802_OPMODE_LP>;
};
ldo11_reg: LDO11 {
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <1900000>;
regulator-max-microvolt = <1900000>;
regulator-always-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-mode = <MAX77802_OPMODE_LP>;
};
};
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
regulator-min-microvolt = <950000>;
regulator-max-microvolt = <1300000>;
regulator-always-on;
regulator-boot-on;
};
};

78
Documentation/devicetree/bindings/regulator/maxim,max14577.yaml Normal file
View File

@ -0,0 +1,78 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/maxim,max14577.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC regulators
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description: |
This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB
Integrated Circuit (MUIC).
See also Documentation/devicetree/bindings/mfd/maxim,max14577.yaml for
additional information and example.
properties:
compatible:
enum:
- maxim,max14577-regulator
- maxim,max77836-regulator
CHARGER:
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description: |
Current regulator.
properties:
regulator-min-microvolt: false
regulator-max-microvolt: false
SAFEOUT:
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description: |
Safeout LDO regulator (fixed voltage).
properties:
regulator-min-microamp: false
regulator-max-microamp: false
regulator-min-microvolt:
const: 4900000
regulator-max-microvolt:
const: 4900000
patternProperties:
"^LDO[12]$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description: |
Current regulator.
properties:
regulator-min-microamp: false
regulator-max-microamp: false
regulator-min-microvolt:
minimum: 800000
regulator-max-microvolt:
maximum: 3950000
allOf:
- if:
properties:
compatible:
contains:
const: maxim,max14577-regulator
then:
properties:
LDO1: false
LDO2: false
additionalProperties: false

85
Documentation/devicetree/bindings/regulator/maxim,max77802.yaml Normal file
View File

@ -0,0 +1,85 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/maxim,max77802.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX77802 Power Management IC regulators
maintainers:
- Javier Martinez Canillas <javier@dowhile0.org>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description: |
This is a part of device tree bindings for Maxim MAX77802 Power Management
Integrated Circuit (PMIC).
The Maxim MAX77686 provides 10 high-efficiency Buck and 32 Low-DropOut (LDO)
regulators.
See also Documentation/devicetree/bindings/mfd/maxim,max77802.yaml for
additional information and example.
Certain regulators support "regulator-initial-mode" and "regulator-mode".
The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h
and their meaning is::
1 - Normal regulator voltage output mode.
3 - Low Power which reduces the quiescent current down to only 1uA
The standard "regulator-mode" property can only be used for regulators that
support changing their mode to Low Power Mode during suspend. These
regulators are:: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
regulator has been enabled for the given suspend state using
"regulator-on-in-suspend" and has not been disabled for that state using
"regulator-off-in-suspend".
patternProperties:
# LDO1, LDO3, LDO20, LDO21
"^LDO([13]|2[01])$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description:
LDOs supporting the regulator-initial-mode property and changing their
mode during normal operation.
# LDO2, LDO4-15, LDO17-19, LDO23-30, LDO32-35
"^LDO([24-9]|1[0-5789]|2[3-9]|3[02345])$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description:
LDOs supporting the regulator-mode property (changing mode to Low Power
Mode during suspend).
properties:
regulator-initial-mode: false
# buck2-4
"^BUCK[2-4]$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
description:
bucks supporting the regulator-mode property (changing mode to Low Power
Mode during suspend).
properties:
regulator-initial-mode: false
# buck1, buck5-10
"^BUCK([15-9]|10)$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
properties:
regulator-initial-mode: false
patternProperties:
regulator-state-(standby|mem|disk):
type: object
properties:
regulator-mode: false
additionalProperties: false

65
Documentation/devicetree/bindings/regulator/maxim,max77843.yaml Normal file
View File

@ -0,0 +1,65 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/maxim,max77843.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX77843 MicroUSB and Companion Power Management IC regulators
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description: |
This is a part of device tree bindings for Maxim MAX77843 MicroUSB Integrated
Circuit (MUIC).
See also Documentation/devicetree/bindings/mfd/maxim,max77843.yaml for
additional information and example.
properties:
compatible:
const: maxim,max77843-regulator
CHARGER:
type: object
$ref: regulator.yaml#
additionalProperties: false
description: |
Current regulator.
properties:
regulator-name: true
regulator-always-on: true
regulator-boot-on: true
regulator-min-microamp:
minimum: 100000
regulator-max-microamp:
maximum: 3150000
required:
- regulator-name
patternProperties:
"^SAFEOUT[12]$":
type: object
$ref: regulator.yaml#
additionalProperties: false
description: |
Safeout LDO regulator.
properties:
regulator-name: true
regulator-always-on: true
regulator-boot-on: true
regulator-min-microvolt:
minimum: 3300000
regulator-max-microvolt:
maximum: 4950000
required:
- regulator-name
required:
- compatible
additionalProperties: false

5
Documentation/devicetree/bindings/regulator/maxim,max8973.yaml
View File

@ -113,7 +113,7 @@ examples:
};
- |
#include <dt-bindings/gpio/tegra-gpio.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
@ -123,8 +123,7 @@ examples:
regulator@1b {
compatible = "maxim,max77621";
reg = <0x1b>;
interrupt-parent = <&gpio>;
interrupts = <TEGRA_GPIO(Y, 1) IRQ_TYPE_LEVEL_LOW>;
interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
regulator-always-on;
regulator-boot-on;

6
Documentation/devicetree/bindings/regulator/pfuze100.yaml
View File

@ -70,7 +70,11 @@ properties:
$ref: "regulator.yaml#"
type: object
"^(vsnvs|vref|vrefddr|swbst|coin)$":
"^vldo[1-4]$":
$ref: "regulator.yaml#"
type: object
"^(vsnvs|vref|vrefddr|swbst|coin|v33|vccsd)$":
$ref: "regulator.yaml#"
type: object

2
Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
View File

@ -48,6 +48,7 @@ description: |
For PMI8998, bob
For PMR735A, smps1 - smps3, ldo1 - ldo7
For PMX55, smps1 - smps7, ldo1 - ldo16
For PMX65, smps1 - smps8, ldo1 - ldo21
properties:
compatible:
@ -70,6 +71,7 @@ properties:
- qcom,pmm8155au-rpmh-regulators
- qcom,pmr735a-rpmh-regulators
- qcom,pmx55-rpmh-regulators
- qcom,pmx65-rpmh-regulators
qcom,pmic-id:
description: |

141
Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml Normal file
View File

@ -0,0 +1,141 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/richtek,rt5190a-regulator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Richtek RT5190A PMIC Regulator
maintainers:
- ChiYuan Huang <cy_huang@richtek.com>
description: |
The RT5190A integrates 1 channel buck controller, 3 channels high efficiency
synchronous buck converters, 1 LDO, I2C control interface and peripherial
logical control.
It also supports mute AC OFF depop sound and quick setting storage while
input power is removed.
properties:
compatible:
enum:
- richtek,rt5190a
reg:
maxItems: 1
interrupts:
maxItems: 1
vin2-supply:
description: phandle to buck2 input voltage.
vin3-supply:
description: phandle to buck3 input voltage.
vin4-supply:
description: phandle to buck4 input voltage.
vinldo-supply:
description: phandle to ldo input voltage
richtek,mute-enable:
description: |
The mute function uses 'mutein', 'muteout', and 'vdet' pins as the control
signal. When enabled, The normal behavior is to bypass the 'mutein' signal
'muteout'. But if the power source removal is detected from 'vdet',
whatever the 'mutein' signal is, it will pull down the 'muteout' to force
speakers mute. this function is commonly used to prevent the speaker pop
noise during AC power turned off in the modern TV system design.
type: boolean
regulators:
type: object
patternProperties:
"^buck[1-4]$|^ldo$":
type: object
$ref: regulator.yaml#
description: |
regulator description for buck1 and buck4.
properties:
regulator-allowed-modes:
description: |
buck operating mode, only buck1/4 support mode operating.
0: auto mode
1: force pwm mode
items:
enum: [0, 1]
richtek,latchup-enable:
type: boolean
description: |
If specified, undervolt protection mode changes from the default
hiccup to latchup.
unevaluatedProperties: false
additionalProperties: false
required:
- compatible
- reg
- regulators
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/regulator/richtek,rt5190a-regulator.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
pmic@64 {
compatible = "richtek,rt5190a";
reg = <0x64>;
interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>;
vin2-supply = <&rt5190_buck1>;
vin3-supply = <&rt5190_buck1>;
vin4-supply = <&rt5190_buck1>;
regulators {
rt5190_buck1: buck1 {
regulator-name = "rt5190a-buck1";
regulator-min-microvolt = <5090000>;
regulator-max-microvolt = <5090000>;
regulator-allowed-modes = <RT5190A_OPMODE_AUTO RT5190A_OPMODE_FPWM>;
regulator-boot-on;
};
buck2 {
regulator-name = "rt5190a-buck2";
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <1400000>;
regulator-boot-on;
};
buck3 {
regulator-name = "rt5190a-buck3";
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <1400000>;
regulator-boot-on;
};
buck4 {
regulator-name = "rt5190a-buck4";
regulator-min-microvolt = <850000>;
regulator-max-microvolt = <850000>;
regulator-allowed-modes = <RT5190A_OPMODE_AUTO RT5190A_OPMODE_FPWM>;
regulator-boot-on;
};
ldo {
regulator-name = "rt5190a-ldo";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-boot-on;
};
};
};
};

98
Documentation/devicetree/bindings/regulator/ti,tps62360.yaml Normal file
View File

@ -0,0 +1,98 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/ti,tps62360.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments TPS6236x Voltage Regulators
maintainers:
- Laxman Dewangan <ldewangan@nvidia.com>
description: |
The TPS6236x are a family of step down dc-dc converter with
an input voltage range of 2.5V to 5.5V. The devices provide
up to 3A peak load current, and an output voltage range of
0.77V to 1.4V (TPS62360/62) and 0.5V to 1.77V (TPS62361B/63).
Datasheet is available at:
https://www.ti.com/lit/gpn/tps62360
allOf:
- $ref: "regulator.yaml#"
properties:
compatible:
enum:
- ti,tps62360
- ti,tps62361
- ti,tps62362
- ti,tps62363
reg:
maxItems: 1
ti,vsel0-gpio:
description: |
GPIO for controlling VSEL0 line. If this property
is missing, then assume that there is no GPIO for
VSEL0 control.
maxItems: 1
ti,vsel1-gpio:
description: |
GPIO for controlling VSEL1 line. If this property
is missing, then assume that there is no GPIO for
VSEL1 control.
maxItems: 1
ti,enable-vout-discharge:
description: Enable output discharge.
type: boolean
ti,enable-pull-down:
description: Enable pull down.
type: boolean
ti,vsel0-state-high:
description: |
Initial state of VSEL0 input is high. If this property
is missing, then assume the state as low.
type: boolean
ti,vsel1-state-high:
description: |
Initial state of VSEL1 input is high. If this property
is missing, then assume the state as low.
type: boolean
required:
- compatible
- reg
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
regulator@60 {
compatible = "ti,tps62361";
reg = <0x60>;
regulator-name = "tps62361-vout";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <1500000>;
regulator-boot-on;
ti,vsel0-gpio = <&gpio1 16 GPIO_ACTIVE_HIGH>;
ti,vsel1-gpio = <&gpio1 17 GPIO_ACTIVE_HIGH>;
ti,vsel0-state-high;
ti,vsel1-state-high;
ti,enable-pull-down;
ti,enable-vout-discharge;
};
};
...

63
Documentation/devicetree/bindings/regulator/ti,tps62864.yaml Normal file
View File

@ -0,0 +1,63 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/ti,tps62864.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI TPS62864/TPS6286/TPS62868/TPS62869 voltage regulator
maintainers:
- Vincent Whitchurch <vincent.whitchurch@axis.com>
properties:
compatible:
enum:
- ti,tps62864
- ti,tps62866
- ti,tps62868
- ti,tps62869
reg:
maxItems: 1
regulators:
type: object
properties:
"SW":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
additionalProperties: false
required:
- compatible
- reg
- regulators
additionalProperties: false
examples:
- |
#include <dt-bindings/regulator/ti,tps62864.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
regulator@48 {
compatible = "ti,tps62864";
reg = <0x48>;
regulators {
SW {
regulator-name = "+0.85V";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <890000>;
regulator-initial-mode = <TPS62864_MODE_FPWM>;
};
};
};
};
...

44
Documentation/devicetree/bindings/regulator/tps62360-regulator.txt
View File

@ -1,44 +0,0 @@
TPS62360 Voltage regulators
Required properties:
- compatible: Must be one of the following.
"ti,tps62360"
"ti,tps62361",
"ti,tps62362",
"ti,tps62363",
- reg: I2C slave address
Optional properties:
- ti,enable-vout-discharge: Enable output discharge. This is boolean value.
- ti,enable-pull-down: Enable pull down. This is boolean value.
- ti,vsel0-gpio: GPIO for controlling VSEL0 line.
If this property is missing, then assume that there is no GPIO
for vsel0 control.
- ti,vsel1-gpio: Gpio for controlling VSEL1 line.
If this property is missing, then assume that there is no GPIO
for vsel1 control.
- ti,vsel0-state-high: Initial state of vsel0 input is high.
If this property is missing, then assume the state as low (0).
- ti,vsel1-state-high: Initial state of vsel1 input is high.
If this property is missing, then assume the state as low (0).
Any property defined as part of the core regulator binding, defined in
regulator.txt, can also be used.
Example:
abc: tps62360 {
compatible = "ti,tps62361";
reg = <0x60>;
regulator-name = "tps62361-vout";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <1500000>;
regulator-boot-on
ti,vsel0-gpio = <&gpio1 16 0>;
ti,vsel1-gpio = <&gpio1 17 0>;
ti,vsel0-state-high;
ti,vsel1-state-high;
ti,enable-pull-down;
ti,enable-force-pwm;
ti,enable-vout-discharge;
};

2
Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
View File

@ -22,7 +22,7 @@ description: |
[1] Documentation/devicetree/bindings/serial/samsung_uart.yaml
[2] Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
[3] Documentation/devicetree/bindings/spi/spi-samsung.txt
[3] Documentation/devicetree/bindings/spi/samsung,spi.yaml
properties:
$nodename:

107
Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml Normal file
View File

@ -0,0 +1,107 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/mediatek,spi-mt65xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: SPI Bus controller for MediaTek ARM SoCs
maintainers:
- Leilk Liu <leilk.liu@mediatek.com>
allOf:
- $ref: "/schemas/spi/spi-controller.yaml#"
properties:
compatible:
oneOf:
- items:
- enum:
- mediatek,mt7629-spi
- const: mediatek,mt7622-spi
- items:
- enum:
- mediatek,mt8516-spi
- const: mediatek,mt2712-spi
- items:
- enum:
- mediatek,mt6779-spi
- mediatek,mt8186-spi
- mediatek,mt8192-spi
- mediatek,mt8195-spi
- const: mediatek,mt6765-spi
- items:
- enum:
- mediatek,mt7986-spi-ipm
- const: mediatek,spi-ipm
- items:
- enum:
- mediatek,mt2701-spi
- mediatek,mt2712-spi
- mediatek,mt6589-spi
- mediatek,mt6765-spi
- mediatek,mt6893-spi
- mediatek,mt7622-spi
- mediatek,mt8135-spi
- mediatek,mt8173-spi
- mediatek,mt8183-spi
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: clock used for the parent clock
- description: clock used for the muxes clock
- description: clock used for the clock gate
clock-names:
items:
- const: parent-clk
- const: sel-clk
- const: spi-clk
mediatek,pad-select:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 4
items:
enum: [0, 1, 2, 3]
description:
specify which pins group(ck/mi/mo/cs) spi controller used.
This is an array.
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- '#address-cells'
- '#size-cells'
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/mt8173-clk.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
spi@1100a000 {
compatible = "mediatek,mt8173-spi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x1100a000 0x1000>;
interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>;
clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
<&topckgen CLK_TOP_SPI_SEL>,
<&pericfg CLK_PERI_SPI0>;
clock-names = "parent-clk", "sel-clk", "spi-clk";
cs-gpios = <&pio 105 GPIO_ACTIVE_LOW>, <&pio 72 GPIO_ACTIVE_LOW>;
mediatek,pad-select = <1>, <0>;
};

4
Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
View File

@ -30,6 +30,7 @@ properties:
- mediatek,mt7622-nor
- mediatek,mt7623-nor
- mediatek,mt7629-nor
- mediatek,mt8186-nor
- mediatek,mt8192-nor
- mediatek,mt8195-nor
- enum:
@ -49,6 +50,8 @@ properties:
- description: clock used for controller
- description: clock used for nor dma bus. this depends on hardware
design, so this is optional.
- description: clock used for controller axi slave bus.
this depends on hardware design, so it is optional.
clock-names:
minItems: 2
@ -56,6 +59,7 @@ properties:
- const: spi
- const: sf
- const: axi
- const: axi_s
required:
- compatible

58
Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml Normal file
View File

@ -0,0 +1,58 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/mediatek,spi-slave-mt27xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: SPI Slave controller for MediaTek ARM SoCs
maintainers:
- Leilk Liu <leilk.liu@mediatek.com>
allOf:
- $ref: "/schemas/spi/spi-controller.yaml#"
properties:
compatible:
enum:
- mediatek,mt2712-spi-slave
- mediatek,mt8195-spi-slave
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
clock-names:
items:
- const: spi
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/mt2712-clk.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
spi@10013000 {
compatible = "mediatek,mt2712-spi-slave";
reg = <0x10013000 0x100>;
interrupts = <GIC_SPI 283 IRQ_TYPE_LEVEL_LOW>;
clocks = <&infracfg CLK_INFRA_AO_SPI1>;
clock-names = "spi";
assigned-clocks = <&topckgen CLK_TOP_SPISLV_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL1_D2>;
};

52
Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml Normal file
View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/microchip,mpfs-spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip MPFS {Q,}SPI Controller Device Tree Bindings
maintainers:
- Conor Dooley <conor.dooley@microchip.com>
allOf:
- $ref: spi-controller.yaml#
properties:
compatible:
enum:
- microchip,mpfs-spi
- microchip,mpfs-qspi
reg:
maxItems: 1
interrupts:
maxItems: 1
clock-names:
maxItems: 1
clocks:
maxItems: 1
required:
- compatible
- reg
- interrupts
- clocks
unevaluatedProperties: false
examples:
- |
#include "dt-bindings/clock/microchip,mpfs-clock.h"
spi@20108000 {
compatible = "microchip,mpfs-spi";
reg = <0x20108000 0x1000>;
clocks = <&clkcfg CLK_SPI0>;
interrupt-parent = <&plic>;
interrupts = <54>;
spi-max-frequency = <25000000>;
};
...

3
Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml
View File

@ -19,6 +19,7 @@ properties:
- nvidia,tegra210-qspi
- nvidia,tegra186-qspi
- nvidia,tegra194-qspi
- nvidia,tegra234-qspi
reg:
maxItems: 1
@ -106,7 +107,7 @@ examples:
dma-names = "rx", "tx";
flash@0 {
compatible = "spi-nor";
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <104000000>;
spi-tx-bus-width = <2>;

4
Documentation/devicetree/bindings/spi/renesas,rspi.yaml
View File

@ -22,7 +22,8 @@ properties:
- renesas,rspi-r7s72100 # RZ/A1H
- renesas,rspi-r7s9210 # RZ/A2
- renesas,r9a07g044-rspi # RZ/G2{L,LC}
- const: renesas,rspi-rz # RZ/A and RZ/G2{L,LC}
- renesas,r9a07g054-rspi # RZ/V2L
- const: renesas,rspi-rz
- items:
- enum:
@ -124,6 +125,7 @@ allOf:
enum:
- renesas,qspi
- renesas,r9a07g044-rspi
- renesas,r9a07g054-rspi
then:
required:
- resets

33
Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml Normal file
View File

@ -0,0 +1,33 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/samsung,spi-peripheral-props.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Peripheral-specific properties for Samsung S3C/S5P/Exynos SoC SPI controller
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description:
See spi-peripheral-props.yaml for more info.
properties:
controller-data:
type: object
additionalProperties: false
properties:
samsung,spi-feedback-delay:
description: |
The sampling phase shift to be applied on the miso line (to account
for any lag in the miso line). Valid values:
- 0: No phase shift.
- 1: 90 degree phase shift sampling.
- 2: 180 degree phase shift sampling.
- 3: 270 degree phase shift sampling.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 0
additionalProperties: true

188
Documentation/devicetree/bindings/spi/samsung,spi.yaml Normal file
View File

@ -0,0 +1,188 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/samsung,spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S3C/S5P/Exynos SoC SPI controller
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description:
All the SPI controller nodes should be represented in the aliases node using
the following format 'spi{n}' where n is a unique number for the alias.
properties:
compatible:
oneOf:
- enum:
- samsung,s3c2443-spi # for S3C2443, S3C2416 and S3C2450
- samsung,s3c6410-spi
- samsung,s5pv210-spi # for S5PV210 and S5PC110
- samsung,exynos5433-spi
- tesla,fsd-spi
- const: samsung,exynos7-spi
deprecated: true
clocks:
minItems: 2
maxItems: 3
clock-names:
minItems: 2
maxItems: 3
cs-gpios: true
dmas:
minItems: 2
maxItems: 2
dma-names:
items:
- const: tx
- const: rx
interrupts:
maxItems: 1
no-cs-readback:
description:
The CS line is disconnected, therefore the device should not operate
based on CS signalling.
type: boolean
num-cs:
minimum: 1
maximum: 4
default: 1
samsung,spi-src-clk:
description:
If the spi controller includes a internal clock mux to select the clock
source for the spi bus clock, this property can be used to indicate the
clock to be used for driving the spi bus clock. If not specified, the
clock number 0 is used as default.
$ref: /schemas/types.yaml#/definitions/uint32
default: 0
reg:
maxItems: 1
required:
- compatible
- clocks
- clock-names
- dmas
- dma-names
- interrupts
- reg
allOf:
- $ref: spi-controller.yaml#
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-spi
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: spi
- enum:
- spi_busclk0
- spi_busclk1
- spi_busclk2
- spi_busclk3
- const: spi_ioclk
else:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: spi
- enum:
- spi_busclk0
- spi_busclk1
- spi_busclk2
- spi_busclk3
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/exynos5433.h>
#include <dt-bindings/clock/samsung,s2mps11.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/gpio/gpio.h>
spi@14d30000 {
compatible = "samsung,exynos5433-spi";
reg = <0x14d30000 0x100>;
interrupts = <GIC_SPI 433 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&pdma0 11>, <&pdma0 10>;
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
clocks = <&cmu_peric CLK_PCLK_SPI1>,
<&cmu_peric CLK_SCLK_SPI1>,
<&cmu_peric CLK_SCLK_IOCLK_SPI1>;
clock-names = "spi",
"spi_busclk0",
"spi_ioclk";
samsung,spi-src-clk = <0>;
pinctrl-names = "default";
pinctrl-0 = <&spi1_bus>;
num-cs = <1>;
cs-gpios = <&gpd6 3 GPIO_ACTIVE_HIGH>;
audio-codec@0 {
compatible = "wlf,wm5110";
reg = <0x0>;
spi-max-frequency = <20000000>;
interrupt-parent = <&gpa0>;
interrupts = <4 IRQ_TYPE_NONE>;
clocks = <&pmu_system_controller 0>,
<&s2mps13_osc S2MPS11_CLK_BT>;
clock-names = "mclk1", "mclk2";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
wlf,micd-detect-debounce = <300>;
wlf,micd-bias-start-time = <0x1>;
wlf,micd-rate = <0x7>;
wlf,micd-dbtime = <0x2>;
wlf,micd-force-micbias;
wlf,micd-configs = <0x0 1 0>;
wlf,hpdet-channel = <1>;
wlf,gpsw = <0x1>;
wlf,inmode = <2 0 2 0>;
wlf,reset = <&gpc0 7 GPIO_ACTIVE_HIGH>;
wlf,ldoena = <&gpf0 0 GPIO_ACTIVE_HIGH>;
/* core supplies */
AVDD-supply = <&ldo18_reg>;
DBVDD1-supply = <&ldo18_reg>;
CPVDD-supply = <&ldo18_reg>;
DBVDD2-supply = <&ldo18_reg>;
DBVDD3-supply = <&ldo18_reg>;
SPKVDDL-supply = <&ldo18_reg>;
SPKVDDR-supply = <&ldo18_reg>;
controller-data {
samsung,spi-feedback-delay = <0>;
};
};
};

7
Documentation/devicetree/bindings/spi/spi-controller.yaml
View File

@ -139,4 +139,11 @@ examples:
spi-max-frequency = <100000>;
reg = <1>;
};
flash@2 {
compatible = "jedec,spi-nor";
spi-max-frequency = <50000000>;
reg = <2>, <3>;
stacked-memories = /bits/ 64 <0x10000000 0x10000000>;
};
};

68
Documentation/devicetree/bindings/spi/spi-mt65xx.txt
View File

@ -1,68 +0,0 @@
Binding for MTK SPI controller
Required properties:
- compatible: should be one of the following.
- mediatek,mt2701-spi: for mt2701 platforms
- mediatek,mt2712-spi: for mt2712 platforms
- mediatek,mt6589-spi: for mt6589 platforms
- mediatek,mt6765-spi: for mt6765 platforms
- mediatek,mt7622-spi: for mt7622 platforms
- "mediatek,mt7629-spi", "mediatek,mt7622-spi": for mt7629 platforms
- mediatek,mt8135-spi: for mt8135 platforms
- mediatek,mt8173-spi: for mt8173 platforms
- mediatek,mt8183-spi: for mt8183 platforms
- mediatek,mt6893-spi: for mt6893 platforms
- "mediatek,mt8192-spi", "mediatek,mt6765-spi": for mt8192 platforms
- "mediatek,mt8195-spi", "mediatek,mt6765-spi": for mt8195 platforms
- "mediatek,mt8516-spi", "mediatek,mt2712-spi": for mt8516 platforms
- "mediatek,mt6779-spi", "mediatek,mt6765-spi": for mt6779 platforms
- #address-cells: should be 1.
- #size-cells: should be 0.
- reg: Address and length of the register set for the device
- interrupts: Should contain spi interrupt
- clocks: phandles to input clocks.
The first should be one of the following. It's PLL.
- <&clk26m>: specify parent clock 26MHZ.
- <&topckgen CLK_TOP_SYSPLL3_D2>: specify parent clock 109MHZ.
It's the default one.
- <&topckgen CLK_TOP_SYSPLL4_D2>: specify parent clock 78MHZ.
- <&topckgen CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ.
- <&topckgen CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ.
The second should be <&topckgen CLK_TOP_SPI_SEL>. It's clock mux.
The third is <&pericfg CLK_PERI_SPI0>. It's clock gate.
- clock-names: shall be "parent-clk" for the parent clock, "sel-clk" for the
muxes clock, and "spi-clk" for the clock gate.
Optional properties:
-cs-gpios: see spi-bus.txt.
- mediatek,pad-select: specify which pins group(ck/mi/mo/cs) spi
controller used. This is an array, the element value should be 0~3,
only required for MT8173.
0: specify GPIO69,70,71,72 for spi pins.
1: specify GPIO102,103,104,105 for spi pins.
2: specify GPIO128,129,130,131 for spi pins.
3: specify GPIO5,6,7,8 for spi pins.
Example:
- SoC Specific Portion:
spi: spi@1100a000 {
compatible = "mediatek,mt8173-spi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0 0x1100a000 0 0x1000>;
interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>;
clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
<&topckgen CLK_TOP_SPI_SEL>,
<&pericfg CLK_PERI_SPI0>;
clock-names = "parent-clk", "sel-clk", "spi-clk";
cs-gpios = <&pio 105 GPIO_ACTIVE_LOW>, <&pio 72 GPIO_ACTIVE_LOW>;
mediatek,pad-select = <1>, <0>;
};

3
Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml
View File

@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP Flex Serial Peripheral Interface (FSPI)
maintainers:
- Kuldeep Singh <kuldeep.singh@nxp.com>
- Han Xu <han.xu@nxp.com>
- Kuldeep Singh <singh.kuldeep87k@gmail.com>
allOf:
- $ref: "spi-controller.yaml#"

26
Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
View File

@ -83,8 +83,34 @@ properties:
description:
Delay, in microseconds, after a write transfer.
stacked-memories:
description: Several SPI memories can be wired in stacked mode.
This basically means that either a device features several chip
selects, or that different devices must be seen as a single
bigger chip. This basically doubles (or more) the total address
space with only a single additional wire, while still needing
to repeat the commands when crossing a chip boundary. The size of
each chip should be provided as members of the array.
$ref: /schemas/types.yaml#/definitions/uint64-array
minItems: 2
maxItems: 4
parallel-memories:
description: Several SPI memories can be wired in parallel mode.
The devices are physically on a different buses but will always
act synchronously as each data word is spread across the
different memories (eg. even bits are stored in one memory, odd
bits in the other). This basically doubles the address space and
the throughput while greatly complexifying the wiring because as
many busses as devices must be wired. The size of each chip should
be provided as members of the array.
$ref: /schemas/types.yaml#/definitions/uint64-array
minItems: 2
maxItems: 4
# The controller specific properties go here.
allOf:
- $ref: cdns,qspi-nor-peripheral-props.yaml#
- $ref: samsung,spi-peripheral-props.yaml#
additionalProperties: true

4
Documentation/devicetree/bindings/spi/spi-pl022.yaml
View File

@ -38,9 +38,7 @@ properties:
clock-names:
items:
- enum:
- SSPCLK
- sspclk
- const: sspclk
- const: apb_pclk
pl022,autosuspend-delay:

122
Documentation/devicetree/bindings/spi/spi-samsung.txt
View File

@ -1,122 +0,0 @@
* Samsung SPI Controller
The Samsung SPI controller is used to interface with various devices such as flash
and display controllers using the SPI communication interface.
Required SoC Specific Properties:
- compatible: should be one of the following.
- samsung,s3c2443-spi: for s3c2443, s3c2416 and s3c2450 platforms
- samsung,s3c6410-spi: for s3c6410 platforms
- samsung,s5pv210-spi: for s5pv210 and s5pc110 platforms
- samsung,exynos5433-spi: for exynos5433 compatible controllers
- samsung,exynos7-spi: for exynos7 platforms <DEPRECATED>
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu. The interrupt specifier format
depends on the interrupt controller.
- dmas : Two or more DMA channel specifiers following the convention outlined
in bindings/dma/dma.txt
- dma-names: Names for the dma channels. There must be at least one channel
named "tx" for transmit and named "rx" for receive.
- clocks: specifies the clock IDs provided to the SPI controller; they are
required for interacting with the controller itself, for synchronizing the bus
and as I/O clock (the latter is required by exynos5433 and exynos7).
- clock-names: string names of the clocks in the 'clocks' property; for all the
the devices the names must be "spi", "spi_busclkN" (where N is determined by
"samsung,spi-src-clk"), while Exynos5433 should specify a third clock
"spi_ioclk" for the I/O clock.
Required Board Specific Properties:
- #address-cells: should be 1.
- #size-cells: should be 0.
Optional Board Specific Properties:
- samsung,spi-src-clk: If the spi controller includes a internal clock mux to
select the clock source for the spi bus clock, this property can be used to
indicate the clock to be used for driving the spi bus clock. If not specified,
the clock number 0 is used as default.
- num-cs: Specifies the number of chip select lines supported. If
not specified, the default number of chip select lines is set to 1.
- cs-gpios: should specify GPIOs used for chipselects (see spi-bus.txt)
- no-cs-readback: the CS line is disconnected, therefore the device should not
operate based on CS signalling.
SPI Controller specific data in SPI slave nodes:
- The spi slave nodes should provide the following information which is required
by the spi controller.
- samsung,spi-feedback-delay: The sampling phase shift to be applied on the
miso line (to account for any lag in the miso line). The following are the
valid values.
- 0: No phase shift.
- 1: 90 degree phase shift sampling.
- 2: 180 degree phase shift sampling.
- 3: 270 degree phase shift sampling.
Aliases:
- All the SPI controller nodes should be represented in the aliases node using
the following format 'spi{n}' where n is a unique number for the alias.
Example:
- SoC Specific Portion:
spi_0: spi@12d20000 {
compatible = "samsung,exynos4210-spi";
reg = <0x12d20000 0x100>;
interrupts = <0 66 0>;
dmas = <&pdma0 5
&pdma0 4>;
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
};
- Board Specific Portion:
spi_0: spi@12d20000 {
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&spi0_bus>;
cs-gpios = <&gpa2 5 0>;
w25q80bw@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "w25x80";
reg = <0>;
spi-max-frequency = <10000>;
controller-data {
samsung,spi-feedback-delay = <0>;
};
partition@0 {
label = "U-Boot";
reg = <0x0 0x40000>;
read-only;
};
partition@40000 {
label = "Kernel";
reg = <0x40000 0xc0000>;
};
};
};

33
Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt
View File

@ -1,33 +0,0 @@
Binding for MTK SPI Slave controller
Required properties:
- compatible: should be one of the following.
- mediatek,mt2712-spi-slave: for mt2712 platforms
- mediatek,mt8195-spi-slave: for mt8195 platforms
- reg: Address and length of the register set for the device.
- interrupts: Should contain spi interrupt.
- clocks: phandles to input clocks.
It's clock gate, and should be <&infracfg CLK_INFRA_AO_SPI1>.
- clock-names: should be "spi" for the clock gate.
Optional properties:
- assigned-clocks: it's mux clock, should be <&topckgen CLK_TOP_SPISLV_SEL>.
- assigned-clock-parents: parent of mux clock.
It's PLL, and should be one of the following.
- <&topckgen CLK_TOP_UNIVPLL1_D2>: specify parent clock 312MHZ.
It's the default one.
- <&topckgen CLK_TOP_UNIVPLL1_D4>: specify parent clock 156MHZ.
- <&topckgen CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ.
- <&topckgen CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ.
Example:
- SoC Specific Portion:
spis1: spi@10013000 {
compatible = "mediatek,mt2712-spi-slave";
reg = <0 0x10013000 0 0x100>;
interrupts = <GIC_SPI 283 IRQ_TYPE_LEVEL_LOW>;
clocks = <&infracfg CLK_INFRA_AO_SPI1>;
clock-names = "spi";
assigned-clocks = <&topckgen CLK_TOP_SPISLV_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL1_D2>;
};

78
Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml Normal file
View File

@ -0,0 +1,78 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright (C) Sunplus Co., Ltd. 2021
%YAML 1.2
---
$id: http://devicetree.org/schemas/spi/spi-sunplus-sp7021.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sunplus sp7021 SPI controller
allOf:
- $ref: "spi-controller.yaml"
maintainers:
- Li-hao Kuo <lhjeff911@gmail.com>
properties:
compatible:
enum:
- sunplus,sp7021-spi
reg:
items:
- description: the SPI master registers
- description: the SPI slave registers
reg-names:
items:
- const: master
- const: slave
interrupt-names:
items:
- const: dma_w
- const: master_risc
- const: slave_risc
interrupts:
minItems: 3
clocks:
maxItems: 1
resets:
maxItems: 1
required:
- compatible
- reg
- reg-names
- interrupts
- interrupt-names
- clocks
- resets
- pinctrl-names
- pinctrl-0
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
spi@9C002D80 {
compatible = "sunplus,sp7021-spi";
reg = <0x9C002D80 0x80>, <0x9C002E00 0x80>;
reg-names = "master", "slave";
interrupt-parent = <&intc>;
interrupt-names = "dma_w",
"master_risc",
"slave_risc";
interrupts = <144 IRQ_TYPE_LEVEL_HIGH>,
<146 IRQ_TYPE_LEVEL_HIGH>,
<145 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clkc 0x32>;
resets = <&rstc 0x22>;
pinctrl-names = "default";
pinctrl-0 = <&pins_spi0>;
};
...

106
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
View File

@ -1,106 +0,0 @@
* Exynos Thermal Management Unit (TMU)
** Required properties:
- compatible : One of the following:
"samsung,exynos3250-tmu"
"samsung,exynos4412-tmu"
"samsung,exynos4210-tmu"
"samsung,exynos5250-tmu"
"samsung,exynos5260-tmu"
"samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
"samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
Exynos5420 (Must pass triminfo base and triminfo clock)
"samsung,exynos5433-tmu"
"samsung,exynos7-tmu"
- reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
belongs to register set of TMU instance and second set belongs to
registers shared with the TMU instance.
NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
channels 2, 3 and 4
Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a misplaced
register, also provide clock to access that base.
TRIMINFO at 0x1006c000 contains data for TMU channel 3
TRIMINFO at 0x100a0000 contains data for TMU channel 4
TRIMINFO at 0x10068000 contains data for TMU channel 2
- interrupts : Should contain interrupt for thermal system
- clocks : The main clocks for TMU device
-- 1. operational clock for TMU channel
-- 2. optional clock to access the shared registers of TMU channel
-- 3. optional special clock for functional operation
- clock-names : Thermal system clock name
-- "tmu_apbif" operational clock for current TMU channel
-- "tmu_triminfo_apbif" clock to access the shared triminfo register
for current TMU channel
-- "tmu_sclk" clock for functional operation of the current TMU
channel
The Exynos TMU supports generating interrupts when reaching given
temperature thresholds. Number of supported thermal trip points depends
on the SoC (only first trip points defined in DT will be configured):
- most of SoC: 4
- samsung,exynos5433-tmu: 8
- samsung,exynos7-tmu: 8
** Optional properties:
- vtmu-supply: This entry is optional and provides the regulator node supplying
voltage to TMU. If needed this entry can be placed inside
board/platform specific dts file.
Example 1):
tmu@100c0000 {
compatible = "samsung,exynos4412-tmu";
interrupt-parent = <&combiner>;
reg = <0x100C0000 0x100>;
interrupts = <2 4>;
clocks = <&clock 383>;
clock-names = "tmu_apbif";
vtmu-supply = <&tmu_regulator_node>;
#thermal-sensor-cells = <0>;
};
Example 2): (In case of Exynos5420 "with misplaced TRIMINFO register")
tmu_cpu2: tmu@10068000 {
compatible = "samsung,exynos5420-tmu-ext-triminfo";
reg = <0x10068000 0x100>, <0x1006c000 0x4>;
interrupts = <0 184 0>;
clocks = <&clock 318>, <&clock 318>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
#thermal-sensor-cells = <0>;
};
tmu_cpu3: tmu@1006c000 {
compatible = "samsung,exynos5420-tmu-ext-triminfo";
reg = <0x1006c000 0x100>, <0x100a0000 0x4>;
interrupts = <0 185 0>;
clocks = <&clock 318>, <&clock 319>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
#thermal-sensor-cells = <0>;
};
tmu_gpu: tmu@100a0000 {
compatible = "samsung,exynos5420-tmu-ext-triminfo";
reg = <0x100a0000 0x100>, <0x10068000 0x4>;
interrupts = <0 215 0>;
clocks = <&clock 319>, <&clock 318>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
#thermal-sensor-cells = <0>;
};
Note: For multi-instance tmu each instance should have an alias correctly
numbered in "aliases" node.
Example:
aliases {
tmuctrl0 = &tmuctrl_0;
tmuctrl1 = &tmuctrl_1;
tmuctrl2 = &tmuctrl_2;
};

1
Documentation/devicetree/bindings/thermal/qcom-lmh.yaml
View File

@ -19,6 +19,7 @@ properties:
compatible:
enum:
- qcom,sdm845-lmh
- qcom,sm8150-lmh
reg:
items:

1
Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
View File

@ -43,6 +43,7 @@ properties:
- description: v2 of TSENS
items:
- enum:
- qcom,msm8953-tsens
- qcom,msm8996-tsens
- qcom,msm8998-tsens
- qcom,sc7180-tsens

184
Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml Normal file
View File

@ -0,0 +1,184 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/thermal/samsung,exynos-thermal.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos SoC Thermal Management Unit (TMU)
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
description: |
For multi-instance tmu each instance should have an alias correctly numbered
in "aliases" node.
properties:
compatible:
enum:
- samsung,exynos3250-tmu
- samsung,exynos4412-tmu
- samsung,exynos4210-tmu
- samsung,exynos5250-tmu
- samsung,exynos5260-tmu
# For TMU channel 0, 1 on Exynos5420:
- samsung,exynos5420-tmu
# For TMU channels 2, 3 and 4 of Exynos5420:
- samsung,exynos5420-tmu-ext-triminfo
- samsung,exynos5433-tmu
- samsung,exynos7-tmu
clocks:
minItems: 1
maxItems: 3
clock-names:
minItems: 1
maxItems: 3
interrupts:
description: |
The Exynos TMU supports generating interrupts when reaching given
temperature thresholds. Number of supported thermal trip points depends
on the SoC (only first trip points defined in DT will be configured)::
- most of SoC: 4
- samsung,exynos5433-tmu: 8
- samsung,exynos7-tmu: 8
maxItems: 1
reg:
items:
- description: TMU instance registers.
- description: |
Shared TMU registers.
Note:: On Exynos5420, the TRIMINFO register is misplaced for TMU
channels 2, 3 and 4 Use "samsung,exynos5420-tmu-ext-triminfo" in
cases, there is a misplaced register, also provide clock to access
that base.
TRIMINFO at 0x1006c000 contains data for TMU channel 3
TRIMINFO at 0x100a0000 contains data for TMU channel 4
TRIMINFO at 0x10068000 contains data for TMU channel 2
minItems: 1
'#thermal-sensor-cells': true
vtmu-supply:
description: The regulator node supplying voltage to TMU.
required:
- compatible
- clocks
- clock-names
- interrupts
- reg
allOf:
- $ref: /schemas/thermal/thermal-sensor.yaml
- if:
properties:
compatible:
contains:
const: samsung,exynos5420-tmu-ext-triminfo
then:
properties:
clocks:
items:
- description:
Operational clock for TMU channel.
- description:
Optional clock to access the shared registers (e.g. TRIMINFO) of TMU
channel.
clock-names:
items:
- const: tmu_apbif
- const: tmu_triminfo_apbif
reg:
minItems: 2
maxItems: 2
- if:
properties:
compatible:
contains:
enum:
- samsung,exynos5433-tmu
- samsung,exynos7-tmu
then:
properties:
clocks:
items:
- description:
Operational clock for TMU channel.
- description:
Optional special clock for functional operation of TMU channel.
clock-names:
items:
- const: tmu_apbif
- const: tmu_sclk
reg:
minItems: 1
maxItems: 1
- if:
properties:
compatible:
contains:
enum:
- samsung,exynos3250-tmu
- samsung,exynos4412-tmu
- samsung,exynos4210-tmu
- samsung,exynos5250-tmu
- samsung,exynos5260-tmu
- samsung,exynos5420-tmu
then:
properties:
clocks:
minItems: 1
maxItems: 1
reg:
minItems: 1
maxItems: 1
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/exynos4.h>
tmu@100c0000 {
compatible = "samsung,exynos4412-tmu";
reg = <0x100C0000 0x100>;
interrupt-parent = <&combiner>;
interrupts = <2 4>;
#thermal-sensor-cells = <0>;
clocks = <&clock CLK_TMU_APBIF>;
clock-names = "tmu_apbif";
vtmu-supply = <&ldo10_reg>;
};
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
tmu@10068000 {
compatible = "samsung,exynos5420-tmu-ext-triminfo";
reg = <0x10068000 0x100>, <0x1006c000 0x4>;
interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
#thermal-sensor-cells = <0>;
clocks = <&clock 318>, <&clock 318>; /* CLK_TMU */
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
vtmu-supply = <&ldo7_reg>;
};
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
tmu@10060000 {
compatible = "samsung,exynos5433-tmu";
reg = <0x10060000 0x200>;
interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
#thermal-sensor-cells = <0>;
clocks = <&cmu_peris 3>, /* CLK_PCLK_TMU0_APBIF */
<&cmu_peris 35>; /* CLK_SCLK_TMU0 */
clock-names = "tmu_apbif", "tmu_sclk";
vtmu-supply = <&ldo3_reg>;
};

150
Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml Normal file
View File

@ -0,0 +1,150 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: "http://devicetree.org/schemas/timer/nvidia,tegra-timer.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra timer
maintainers:
- Stephen Warren <swarren@nvidia.com>
allOf:
- if:
properties:
compatible:
contains:
const: nvidia,tegra210-timer
then:
properties:
interrupts:
# Either a single combined interrupt or up to 14 individual interrupts
minItems: 1
maxItems: 14
description: >
A list of 14 interrupts; one per each timer channels 0 through 13
- if:
properties:
compatible:
oneOf:
- items:
- enum:
- nvidia,tegra114-timer
- nvidia,tegra124-timer
- nvidia,tegra132-timer
- const: nvidia,tegra30-timer
- items:
- const: nvidia,tegra30-timer
- const: nvidia,tegra20-timer
then:
properties:
interrupts:
# Either a single combined interrupt or up to 6 individual interrupts
minItems: 1
maxItems: 6
description: >
A list of 6 interrupts; one per each of timer channels 1 through 5,
and one for the shared interrupt for the remaining channels.
- if:
properties:
compatible:
const: nvidia,tegra20-timer
then:
properties:
interrupts:
# Either a single combined interrupt or up to 4 individual interrupts
minItems: 1
maxItems: 4
description: |
A list of 4 interrupts; one per timer channel.
properties:
compatible:
oneOf:
- const: nvidia,tegra210-timer
description: >
The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit
timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived
from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock
(TMR10-TMR13). Each TMR can be programmed to generate one-shot, periodic,
or watchdog interrupts.
- items:
- enum:
- nvidia,tegra114-timer
- nvidia,tegra124-timer
- nvidia,tegra132-timer
- const: nvidia,tegra30-timer
- items:
- const: nvidia,tegra30-timer
- const: nvidia,tegra20-timer
description: >
The Tegra30 timer provides ten 29-bit timer channels, a single 32-bit free
running counter, and 5 watchdog modules. The first two channels may also
trigger a legacy watchdog reset.
- const: nvidia,tegra20-timer
description: >
The Tegra20 timer provides four 29-bit timer channels and a single 32-bit free
running counter. The first two channels may also trigger a watchdog reset.
reg:
maxItems: 1
interrupts: true
clocks:
maxItems: 1
clock-names:
items:
- const: timer
required:
- compatible
- reg
- interrupts
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
timer@60005000 {
compatible = "nvidia,tegra30-timer", "nvidia,tegra20-timer";
reg = <0x60005000 0x400>;
interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
<0 1 IRQ_TYPE_LEVEL_HIGH>,
<0 41 IRQ_TYPE_LEVEL_HIGH>,
<0 42 IRQ_TYPE_LEVEL_HIGH>,
<0 121 IRQ_TYPE_LEVEL_HIGH>,
<0 122 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car 214>;
};
- |
#include <dt-bindings/clock/tegra210-car.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
timer@60005000 {
compatible = "nvidia,tegra210-timer";
reg = <0x60005000 0x400>;
interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA210_CLK_TIMER>;
clock-names = "timer";
};

24
Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt
View File

@ -1,24 +0,0 @@
NVIDIA Tegra20 timer
The Tegra20 timer provides four 29-bit timer channels and a single 32-bit free
running counter. The first two channels may also trigger a watchdog reset.
Required properties:
- compatible : should be "nvidia,tegra20-timer".
- reg : Specifies base physical address and size of the registers.
- interrupts : A list of 4 interrupts; one per timer channel.
- clocks : Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
Example:
timer {
compatible = "nvidia,tegra20-timer";
reg = <0x60005000 0x60>;
interrupts = <0 0 0x04
0 1 0x04
0 41 0x04
0 42 0x04>;
clocks = <&tegra_car 132>;
};

36
Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt
View File

@ -1,36 +0,0 @@
NVIDIA Tegra210 timer
The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit
timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived
from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock
(TMR10-TMR13). Each TMR can be programmed to generate one-shot, periodic,
or watchdog interrupts.
Required properties:
- compatible : "nvidia,tegra210-timer".
- reg : Specifies base physical address and size of the registers.
- interrupts : A list of 14 interrupts; one per each timer channels 0 through
13.
- clocks : Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
timer@60005000 {
compatible = "nvidia,tegra210-timer";
reg = <0x0 0x60005000 0x0 0x400>;
interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA210_CLK_TIMER>;
clock-names = "timer";
};

28
Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt
View File

@ -1,28 +0,0 @@
NVIDIA Tegra30 timer
The Tegra30 timer provides ten 29-bit timer channels, a single 32-bit free
running counter, and 5 watchdog modules. The first two channels may also
trigger a legacy watchdog reset.
Required properties:
- compatible : For Tegra30, must contain "nvidia,tegra30-timer". Otherwise,
must contain '"nvidia,<chip>-timer", "nvidia,tegra30-timer"' where
<chip> is tegra124 or tegra132.
- reg : Specifies base physical address and size of the registers.
- interrupts : A list of 6 interrupts; one per each of timer channels 1
through 5, and one for the shared interrupt for the remaining channels.
- clocks : Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
timer {
compatible = "nvidia,tegra30-timer", "nvidia,tegra20-timer";
reg = <0x60005000 0x400>;
interrupts = <0 0 0x04
0 1 0x04
0 41 0x04
0 42 0x04
0 121 0x04
0 122 0x04>;
clocks = <&tegra_car 214>;
};

5
Documentation/devicetree/bindings/trivial-devices.yaml
View File

@ -137,6 +137,8 @@ properties:
- infineon,slb9645tt
# Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor
- infineon,tlv493d-a1b6
# Infineon Multi-phase Digital VR Controller xdpe11280
- infineon,xdpe11280
# Infineon Multi-phase Digital VR Controller xdpe12254
- infineon,xdpe12254
# Infineon Multi-phase Digital VR Controller xdpe12284
@ -337,6 +339,7 @@ properties:
# Thermometer with SPI interface
- ti,tmp121
- ti,tmp122
- ti,tmp125
# Digital Temperature Sensor
- ti,tmp275
# TI DC-DC converter on PMBus
@ -354,6 +357,8 @@ properties:
- ti,tps544c25
# Winbond/Nuvoton H/W Monitor
- winbond,w83793
# Vicor Corporation Digital Supervisor
- vicor,pli1209bc
# i2c trusted platform module (TPM)
- winbond,wpct301

2
Documentation/devicetree/bindings/vendor-prefixes.yaml
View File

@ -1298,6 +1298,8 @@ patternProperties:
description: Vertexcom Technologies, Inc.
"^via,.*":
description: VIA Technologies, Inc.
"^vicor,.*":
description: Vicor Corporation
"^videostrong,.*":
description: Videostrong Technology Co., Ltd.
"^virtio,.*":

21
Documentation/driver-api/gpio/board.rst
View File

@ -71,14 +71,14 @@ with the help of _DSD (Device Specific Data), introduced in ACPI 5.1::
Device (FOO) {
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, ..., IoRestrictionOutputOnly,
"\\_SB.GPI0") {15} // red
GpioIo (Exclusive, ..., IoRestrictionOutputOnly,
"\\_SB.GPI0") {16} // green
GpioIo (Exclusive, ..., IoRestrictionOutputOnly,
"\\_SB.GPI0") {17} // blue
GpioIo (Exclusive, ..., IoRestrictionOutputOnly,
"\\_SB.GPI0") {1} // power
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPI0", 0, ResourceConsumer) { 15 } // red
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPI0", 0, ResourceConsumer) { 16 } // green
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPI0", 0, ResourceConsumer) { 17 } // blue
GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPI0", 0, ResourceConsumer) { 1 } // power
})
Name (_DSD, Package () {
@ -92,10 +92,7 @@ with the help of _DSD (Device Specific Data), introduced in ACPI 5.1::
^FOO, 2, 0, 1,
}
},
Package () {
"power-gpios",
Package () {^FOO, 3, 0, 0},
},
Package () { "power-gpios", Package () { ^FOO, 3, 0, 0 } },
}
})
}

2
Documentation/driver-api/mtd/index.rst
View File

@ -7,6 +7,6 @@ Memory Technology Device (MTD)
.. toctree::
:maxdepth: 1
intel-spi
spi-intel
nand_ecc
spi-nor

8
Documentation/driver-api/mtd/intel-spi.rst → Documentation/driver-api/mtd/spi-intel.rst
View File

@ -1,5 +1,5 @@
==============================
Upgrading BIOS using intel-spi
Upgrading BIOS using spi-intel
==============================
Many Intel CPUs like Baytrail and Braswell include SPI serial flash host
@ -11,12 +11,12 @@ avoid accidental (or on purpose) overwrite of the content.
Not all manufacturers protect the SPI serial flash, mainly because it
allows upgrading the BIOS image directly from an OS.
The intel-spi driver makes it possible to read and write the SPI serial
The spi-intel driver makes it possible to read and write the SPI serial
flash, if certain protection bits are not set and locked. If it finds
any of them set, the whole MTD device is made read-only to prevent
partial overwrites. By default the driver exposes SPI serial flash
contents as read-only but it can be changed from kernel command line,
passing "intel-spi.writeable=1".
passing "spi_intel.writeable=1".
Please keep in mind that overwriting the BIOS image on SPI serial flash
might render the machine unbootable and requires special equipment like
@ -32,7 +32,7 @@ Linux.
serial flash. Distros like Debian and Fedora have this prepackaged with
name "mtd-utils".
3) Add "intel-spi.writeable=1" to the kernel command line and reboot
3) Add "spi_intel.writeable=1" to the kernel command line and reboot
the board (you can also reload the driver passing "writeable=1" as
module parameter to modprobe).

2
Documentation/driver-api/serial/driver.rst
View File

@ -311,7 +311,7 @@ hardware.
This call must not sleep
set_ldisc(port,termios)
Notifier for discipline change. See Documentation/driver-api/serial/tty.rst.
Notifier for discipline change. See Documentation/tty/tty_ldisc.rst.
Locking: caller holds tty_port->mutex

1
Documentation/driver-api/thermal/index.rst
View File

@ -17,3 +17,4 @@ Thermal
intel_powerclamp
nouveau_thermal
x86_pkg_temperature_thermal
intel_dptf

272
Documentation/driver-api/thermal/intel_dptf.rst Normal file
View File

@ -0,0 +1,272 @@
.. SPDX-License-Identifier: GPL-2.0
===============================================================
Intel(R) Dynamic Platform and Thermal Framework Sysfs Interface
===============================================================
:Copyright: |copy| 2022 Intel Corporation
:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Introduction
------------
Intel(R) Dynamic Platform and Thermal Framework (DPTF) is a platform
level hardware/software solution for power and thermal management.
As a container for multiple power/thermal technologies, DPTF provides
a coordinated approach for different policies to effect the hardware
state of a system.
Since it is a platform level framework, this has several components.
Some parts of the technology is implemented in the firmware and uses
ACPI and PCI devices to expose various features for monitoring and
control. Linux has a set of kernel drivers exposing hardware interface
to user space. This allows user space thermal solutions like
"Linux Thermal Daemon" to read platform specific thermal and power
tables to deliver adequate performance while keeping the system under
thermal limits.
DPTF ACPI Drivers interface
----------------------------
:file:`/sys/bus/platform/devices/<N>/uuids`, where <N>
=INT3400|INTC1040|INTC1041|INTC10A0
``available_uuids`` (RO)
A set of UUIDs strings presenting available policies
which should be notified to the firmware when the
user space can support those policies.
UUID strings:
"42A441D6-AE6A-462b-A84B-4A8CE79027D3" : Passive 1
"3A95C389-E4B8-4629-A526-C52C88626BAE" : Active
"97C68AE7-15FA-499c-B8C9-5DA81D606E0A" : Critical
"63BE270F-1C11-48FD-A6F7-3AF253FF3E2D" : Adaptive performance
"5349962F-71E6-431D-9AE8-0A635B710AEE" : Emergency call
"9E04115A-AE87-4D1C-9500-0F3E340BFE75" : Passive 2
"F5A35014-C209-46A4-993A-EB56DE7530A1" : Power Boss
"6ED722A7-9240-48A5-B479-31EEF723D7CF" : Virtual Sensor
"16CAF1B7-DD38-40ED-B1C1-1B8A1913D531" : Cooling mode
"BE84BABF-C4D4-403D-B495-3128FD44dAC1" : HDC
``current_uuid`` (RW)
User space can write strings from available UUIDs, one at a
time.
:file:`/sys/bus/platform/devices/<N>/`, where <N>
=INT3400|INTC1040|INTC1041|INTC10A0
``imok`` (WO)
User space daemon write 1 to respond to firmware event
for sending keep alive notification. User space receives
THERMAL_EVENT_KEEP_ALIVE kobject uevent notification when
firmware calls for user space to respond with imok ACPI
method.
``odvp*`` (RO)
Firmware thermal status variable values. Thermal tables
calls for different processing based on these variable
values.
``data_vault`` (RO)
Binary thermal table. Refer to
https:/github.com/intel/thermal_daemon for decoding
thermal table.
ACPI Thermal Relationship table interface
------------------------------------------
:file:`/dev/acpi_thermal_rel`
This device provides IOCTL interface to read standard ACPI
thermal relationship tables via ACPI methods _TRT and _ART.
These IOCTLs are defined in
drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.h
IOCTLs:
ACPI_THERMAL_GET_TRT_LEN: Get length of TRT table
ACPI_THERMAL_GET_ART_LEN: Get length of ART table
ACPI_THERMAL_GET_TRT_COUNT: Number of records in TRT table
ACPI_THERMAL_GET_ART_COUNT: Number of records in ART table
ACPI_THERMAL_GET_TRT: Read binary TRT table, length to read is
provided via argument to ioctl().
ACPI_THERMAL_GET_ART: Read binary ART table, length to read is
provided via argument to ioctl().
DPTF ACPI Sensor drivers
-------------------------
DPTF Sensor drivers are presented as standard thermal sysfs thermal_zone.
DPTF ACPI Cooling drivers
--------------------------
DPTF cooling drivers are presented as standard thermal sysfs cooling_device.
DPTF Processor thermal PCI Driver interface
--------------------------------------------
:file:`/sys/bus/pci/devices/0000\:00\:04.0/power_limits/`
Refer to Documentation/power/powercap/powercap.rst for powercap
ABI.
``power_limit_0_max_uw`` (RO)
Maximum powercap sysfs constraint_0_power_limit_uw for Intel RAPL
``power_limit_0_step_uw`` (RO)
Power limit increment/decrements for Intel RAPL constraint 0 power limit
``power_limit_0_min_uw`` (RO)
Minimum powercap sysfs constraint_0_power_limit_uw for Intel RAPL
``power_limit_0_tmin_us`` (RO)
Minimum powercap sysfs constraint_0_time_window_us for Intel RAPL
``power_limit_0_tmax_us`` (RO)
Maximum powercap sysfs constraint_0_time_window_us for Intel RAPL
``power_limit_1_max_uw`` (RO)
Maximum powercap sysfs constraint_1_power_limit_uw for Intel RAPL
``power_limit_1_step_uw`` (RO)
Power limit increment/decrements for Intel RAPL constraint 1 power limit
``power_limit_1_min_uw`` (RO)
Minimum powercap sysfs constraint_1_power_limit_uw for Intel RAPL
``power_limit_1_tmin_us`` (RO)
Minimum powercap sysfs constraint_1_time_window_us for Intel RAPL
``power_limit_1_tmax_us`` (RO)
Maximum powercap sysfs constraint_1_time_window_us for Intel RAPL
:file:`/sys/bus/pci/devices/0000\:00\:04.0/`
``tcc_offset_degree_celsius`` (RW)
TCC offset from the critical temperature where hardware will throttle
CPU.
:file:`/sys/bus/pci/devices/0000\:00\:04.0/workload_request`
``workload_available_types`` (RO)
Available workload types. User space can specify one of the workload type
it is currently executing via workload_type. For example: idle, bursty,
sustained etc.
``workload_type`` (RW)
User space can specify any one of the available workload type using
this interface.
DPTF Processor thermal RFIM interface
--------------------------------------------
RFIM interface allows adjustment of FIVR (Fully Integrated Voltage Regulator)
and DDR (Double Data Rate)frequencies to avoid RF interference with WiFi and 5G.
Switching voltage regulators (VR) generate radiated EMI or RFI at the
fundamental frequency and its harmonics. Some harmonics may interfere
with very sensitive wireless receivers such as Wi-Fi and cellular that
are integrated into host systems like notebook PCs. One of mitigation
methods is requesting SOC integrated VR (IVR) switching frequency to a
small % and shift away the switching noise harmonic interference from
radio channels. OEM or ODMs can use the driver to control SOC IVR
operation within the range where it does not impact IVR performance.
DRAM devices of DDR IO interface and their power plane can generate EMI
at the data rates. Similar to IVR control mechanism, Intel offers a
mechanism by which DDR data rates can be changed if several conditions
are met: there is strong RFI interference because of DDR; CPU power
management has no other restriction in changing DDR data rates;
PC ODMs enable this feature (real time DDR RFI Mitigation referred to as
DDR-RFIM) for Wi-Fi from BIOS.
FIVR attributes
:file:`/sys/bus/pci/devices/0000\:00\:04.0/fivr/`
``vco_ref_code_lo`` (RW)
The VCO reference code is an 11-bit field and controls the FIVR
switching frequency. This is the 3-bit LSB field.
``vco_ref_code_hi`` (RW)
The VCO reference code is an 11-bit field and controls the FIVR
switching frequency. This is the 8-bit MSB field.
``spread_spectrum_pct`` (RW)
Set the FIVR spread spectrum clocking percentage
``spread_spectrum_clk_enable`` (RW)
Enable/disable of the FIVR spread spectrum clocking feature
``rfi_vco_ref_code`` (RW)
This field is a read only status register which reflects the
current FIVR switching frequency
``fivr_fffc_rev`` (RW)
This field indicated the revision of the FIVR HW.
DVFS attributes
:file:`/sys/bus/pci/devices/0000\:00\:04.0/dvfs/`
``rfi_restriction_run_busy`` (RW)
Request the restriction of specific DDR data rate and set this
value 1. Self reset to 0 after operation.
``rfi_restriction_err_code`` (RW)
0 :Request is accepted, 1:Feature disabled,
2: the request restricts more points than it is allowed
``rfi_restriction_data_rate_Delta`` (RW)
Restricted DDR data rate for RFI protection: Lower Limit
``rfi_restriction_data_rate_Base`` (RW)
Restricted DDR data rate for RFI protection: Upper Limit
``ddr_data_rate_point_0`` (RO)
DDR data rate selection 1st point
``ddr_data_rate_point_1`` (RO)
DDR data rate selection 2nd point
``ddr_data_rate_point_2`` (RO)
DDR data rate selection 3rd point
``ddr_data_rate_point_3`` (RO)
DDR data rate selection 4th point
``rfi_disable (RW)``
Disable DDR rate change feature
DPTF Power supply and Battery Interface
----------------------------------------
Refer to Documentation/ABI/testing/sysfs-platform-dptf
DPTF Fan Control
----------------------------------------
Refer to Documentation/admin-guide/acpi/fan_performance_states.rst

Some files were not shown because too many files have changed in this diff Show More